Next steps on Blaze and the view layer

[faceyspacey]

Given only one option, which I think was the main point here, I would pick modules over something else every day of the week.

Yea, i figured that’s what you were actually responding to. …given only one option, I’d pick the same as you: standardized imports/modules.

and if:

[jumping] through crazy hoops in Meteor to do custom namespacing

is unnecessarily increasing complexity to too high a point, I’d also say drop it.

But, if somehow we can reconcile the “cognitive dissonance” between being the “one best” way vs. added complexity from modules, via a strategy, we should. If you get a chance, let @benjamn know my proposed strategy that we statically detect which files use modules, and if they don’t auto-import them. Not sure if he read my comment on his thread. He seems to be busy with higher priority fundamentals. You can probably better find an appropriate time to bring it up to him. …The other main idea there is: if you remove the autoimport package, Meteor generates your main.js file to contain all the initial boilerplate setup so automatic importing of core packages is reconciled with manual importing–that’s as opposed to unnecessarily mixing both paradigms so that application code is manually imported while core packages are automatically imported. If we can get Meteor code to look like a standard NPM app, e.g. the first thing you see in the entry file is express configuration, it will go a long way to changing the perception of Meteor.

Here was my article with all my proposals on the Meteor 1.3 module system:

Meteor 1.3 Wishlist for ES2015 Module Support + NPM Interface

[awatson1978]

I don’t know a thing about intimidating terms like non-optional module systems, react, flux, redux reducers, action creators, component stores, provider context, relay… will I need to know these things at some point soon or be sidelined to Meteor 1.1.0.3 or 1.2? Will I need several courses on this tech in order to use Meteor in the future?

And more to the point… should you need to know these terms?

Now don’t get me wrong… I’ve long argued for functional programming, and regularly use D3 and Nightwatch method chains that would make most novice programmer’s heads explode. I’m not a React hater. And I’ll probably be migrating like 80 packages to React eventually.

BUT. Do the physicians I work with need to know this stuff? Do the UI/UX designers? The database admins? The biostatisticians and clinical analysts?

And this is where the React hype is getting in the way of people’s businesses. It’s all well and good that there are improvements on the way to improve the rendering layer. But look at the relationship between docs.meteor.com and the sample apps (Leaderboard, Todos, Parties). And then look at what the React API brings to the table (not much).

I have the same conversations with the database geeks who get too focused on the data warehouses, and the clinicians who don’t understand the tech, and so forth.

[aadams]

… look at the relationship between docs.meteor.com and the sample apps (Leaderboard, Todos, Parties).

What’s the significance of the relationship between the docs and samples? What, it’s extremely easy to get these applications to 0 to complete? I’m looking over the Todo application now, and the code and markup is easy to follow and just make sense…

… And then look at what the React API brings to the table (not much).

This is what I’ve been scratching my head over, especially after reading the React feedback from devs that are actually using it…

It’s also the reason I went back to Schmidt’s video from earlier this month and wrote a post trying to make sense from a strategic perspective – because from a technical perspective the move to React wasn’t adding up to me. Going back over the video didn’t help much, but I decided to post my findings anyhow.

[niallobrien]

So is Blaze 2.0 going ahead?

[chompomonim]

So, what is status with ‘Blaze2’? I can’t find any branch on github…

[aadams]

Blaze to React wrapper (for package creators)

Geoff’s post may have left the impression that there’s going to be a standalone project like “Blaze 2” that wraps React as the underlying implementation - however my honest expectation is that after the view layer transition, package authors should consider React as the baseline, where the template layer, if ever built, will be more like an optional mixin or addon to React. We don’t want to reinvent a system that is neither Blaze nor React.

I think the above means no Blaze 2.0 and no Blaze overlay despite what Schmidt, the CEO of MDG, states in this opening thread.

Blaze to React wrapper (for package creators)

We just had another round of internal discussion this past week, and I will post something explaining it in more details Monday.

As far as I know, MDG never ended up posting an official thread explaining the rational.

This is all I could find further down the thread linked to above, all unofficial:

Blaze to React wrapper (for package creators)

It is true that we don’t want to commit to a 100% Blaze-to-React compilation project, and you already understand why (if we had infinite resources we would definitely do it, but…).

… and I think it would be great for all current Blaze users if it works out. But I’d like to focus on what value we are trying to provide here: in the long run, it’s better for everyone to be leveraging raw React for its ecosystem.

So @evanyou thinks it would be great for Meteor Developers if someone builds Blaze 2 (in this case @faceyspacey), but MDG isn’t going to.

And to what value he’s talking about above? I think the following provides a hint:

[quote=“evanyou, post:7, topic:14757”]
In short, I think our strategy will be align with React [and FB] community’s best practice, but provide opinionated (but compatible) configuration/components/guidance as part of the framework.
[/quote] [Emphasis mine]

To me this signals MDG’s medium-to-long term goal is to transform Meteor, from what it is today, into the sticky-interconnectivity for the FB stack.

Blaze to React wrapper (for package creators)

I’ll be honest that I don’t know what role Tracker is going to play in that world - fully reactive render functions is pretty much the opposite of what React promotes: contain your data source, make dumb and predictable components.

And the above to me signals the beginning of the end for Tracker as we know it.

Also, I think the world he’s talking about above is a Facebook, functional programming style, world.

This is not just a small technical change to React on the front end. The shift to React signals a tectonic change to everything we know that is Meteor. We should be thinking in terms of what won’t completely change, instead of what will change.

I think after the transition Meteor will be almost unrecognizable from its current form circa early 2016.

[niallobrien]

It would be nice if MDG chimed in here…

[wsjwong]

I really hope that I could go on to use MVC Blaze instead of React component in the future.

[niallobrien]

Agreed. Fact is that building apps with React is slower than using Blaze.

[aviseidmann2015]

Looking Great! I like it

[niallobrien]

I think people forget that React isn’t the only alternative…

[Ben]

True, weird that it’s so quiet from them. Most commented thread on the whole forum, and only a handfull of (contradictary) statements here and there… sigh.

[vonwao]

@eleroy

So what do i tell my designers: learn JSX or you’re fired? This is what you’re talking about so casually.

No, but…

If your designers aren’t smart enough to figure out JSX in 8 hours, you should fire them anyways!

[vonwao]

@aadams:

I don’t know a thing about intimidating terms like non-optional module systems, react, flux, redux reducers, action creators, component stores, provider context, relay… will I need to know these things at some point soon or be sidelined to Meteor 1.1.0.3 or 1.2? Will I need several courses on this tech in order to use Meteor in the future?

Wrong. You don’t need to know redux to use React and Meteor. You just need to add getMeteorData() to your react component and you’re done. It’s quite beautiful and simple.

Sure, I also heard “Tracker is going away”, BUT that is just long term ideal, the fact is that Meteor reactivity works just fine alongside React, I proved it for myself.

@awatson1978 I get your concern about learning curve, but the fact is, if your UI/UX designers aren’t smart enough to figure out JSX in about a day, hire new ones.

Or help someone to add some more sugar on top of JSX, like https://github.com/timbrandin/blaze-react, help solve the problem to help stupid people understand JSX.

[casperandersen]

if someone would bother, it also wouldn’t be impossible with meteor and or babel+webpack to write a .html support file for each relevant component, and have it slurped and transpiled and included as the render section at compile/bundle time.

Same for helpers, events and hooks if need be. However, they should really want it. Take Redux, Relay, etc into account as well, although they can also discard it and abstract freedom and power away from the developer to gain a certain syntax and development style.

But a word of the wise is not to over-react right now, there is a shake down in place, and people will have Eureka moments, designs, patterns and approached will appear and be refined, knowledge will diffuse, and soon those who were against will be protecting the new status quo.

To each their own.

[vonwao]

if someone would bother, it also wouldn’t be impossible with meteor and or babel+webpack to write a .html support file for each relevant component, and have it slurped and transpiled and included as the render section at compile/bundle time.

Right.

I just see a lot of FUD about React and Meteor’s new chosen direction being thrown around on this thread, and it’s pissing me off. There’s no good reason to be afraid of React, or that Meteor will fall apart because MDG decided not to continue developing Blaze. This kind of dialogue actually is pointless and hurts the community.

[vjau]

This is not FUD.
Blaze is dead.
Tracker will die.
Pub/Sub will probably die.
MDG doesn’t develop a JS framework anymore but a distribution of various (and changing) JS technologies + a hosting solution.

[vonwao]

MDG doesn’t develop a JS framework anymore

And we all know that’s a good thing because frameworks are evil, right?

I think blaze will be around for years to come and people will keep using it small projects, prototyping, etc. Same for Tracker.

The FUD I’m talking about is that React will somehow infect the Meteor stack, that suddenly everyone will have learn flux/redux and designers will stop working because they can’t learn JSX.

Either MDG or someone else will develop something that’s more user friendly than flux/redux. And given the high demand for .html templates I have faith that’s coming soon too.

If pub/sub will die, it will have to be replaced by something better, because I know MDG won’t go to its clients and say “we’re going to go backwards and take a away features you already had”. I don’t know how it will play out, but @arunoda has already implemented GraphQL on top of meteor collections, and I believe you can still use liverquery/minimongo alongside GraphQL, it’s not necessarily one one or the other. But I’m sure MDG will wrap it all up into a nicer package, if they decide to go this route.

I wrote elsewhere, but it’s relevant:

React is a framework for professional developers. Blaze is great fun way for amateurs and designers who don’t want to spend about 8 hours learning some basic JS concepts.

If you pay attention, you will notice that the way professionals build something is different from the way amateurs build something. If you hire a contractor to build a kitchen for you, they will use different tools and methods than the do-it-yourself person who goes to IKEA to buy ready-made furniture.

People who have been building web apps and UIs for a long time have come to realize that the old, “easy” way of writing code, using JQuery and other code like Tracker (magical but unpredictable reactivity), doesn’t work that well in the long run, and it doesn’t scale for complex UIs.

MDG has said they don’t want to reinvent the wheel (“When we took a look at what [Blaze 2 and components] would look like, it looked a lot like React.”) The syntax may be unpalatable to some, but then again, syntax can easily be fixed.

[arunoda]

I don’t know how it will play out, but @arunoda has already implemented GraphQL on top of meteor collections

This is quite wrong. It’s on top of Meteor collections.

[bradzo]

Thanks for bringing the mobile aspect up. My day job has seen us just put a mobile app (iOS/Android) into production.

The very reason we chose Meteor was that our native app iOS version was miles behind the Android version, so we decided to give Meteor a go. We had more done in less time and was able to get it run on iOS and Android with no dramas.

So I’ve been reading this thread with great concern as to how the company I work for needs to do to maintain this app if / when we need to go the React route. Will we still be able to build for iOS / Android?

I guess I’ll have to start a demo app and see.

Once again, thanks for bringing the topic of mobile into view.