Next steps on Blaze and the view layer

[aadams]

@rohanray, great point, well said.

[ero]

I think the changes and flux (pun intended) we see in Meteor now reflects the JS ecosystem as a whole. A year ago I actually believed Angular would be the new JQuery. Then came React. I thought Browserify was nice, now everyone’s telling me to use Webpack. And are you still using Bower? That’s stupid, you should have gone back to npm by now.

On the one hand, it takes a lot of resources to be on top of what’s happening in JS-land and to combine the different packages and technologies. On the other hand, the changes we see usually mean progress (i.e. Angular -> React). I do think we will see more of a convergence on technologies in the JS ecosystem over time, but as it is now all the chaos also imply progress. So bring it on.

[dandv]

@rohanray, let me address your only concern specifically:

@rohanray

Within the span of two years, Meteor would have undergone 4 or 5 major revisions deprecating the incumbent tools and frameworks used in Meteor.

While Meteor has undergone some major revisions in its first three years, the rate of change is slowing, as the framework matures. Note how all the core seven principles have remained the same, along with the technology behind them (DDP, (mini)Mongo etc.). It’s a little unfair to compare a 3 year old framework with a 20 year old language:

@rohanray

To iterate again, the point is let’s say I wrote the “simple photo sharing app” in Java which consists of 2000 lines of code. Will the same code run after 2 years? Yes. Will the same code be supported after 2 years? Yes.

On the contrary, it took 250 lines of code to write the same app in Meteor. Will the same code run after 2 years? No. Will the same code be supported after 2 years? No.

A more accurate comparison would assume you wrote 2000 lines of Node.JS and vanilla client-side JS. Those will probably run just fine after two years.

But if you want to bring your Java web app up to speed with 2015, you’d use Java 8 with its new features like lambda expressions, and you’d use higher level networking libraries to make an ordinary REST request instead of 30+ lines of code and 6 intermediary objects.

[jacobin]

But if you want to bring your Java web app up to speed with 2015, you’d use Java 8 with its new features like lambda expressions, and you’d use higher level networking libraries to make an ordinary REST request instead of 30+ lines of code and 6 intermediary objects.

If he were to do this the project size would shrink considerably. Java 8 is far more terse. It would be worth the effort.

[aadams]

While Meteor has undergone some major revisions in its first three years, the rate of change is slowing, as the framework matures.

Hi @dandv, I know you’ve been around a while now and I respect and listen to your opinions. But to me it seems Meteor is on the cusp of a huge transformation, not just in tech it becomes opinionated on (React over Blaze 1 is just the start), but also Meteor’s philosophy. In the next couple years, we will see the most sweeping changes yet – for better or worse.

[brajt]

What are the parts of the Blaze 1 experience that we need to keep, and what do we need to change?

@gschmidt, let me first thank you for all the effort, I do like the overall idea of Blaze2. But what I am worried is:

You ask what Blaze 1 mean for us. For me it means:

1. I can add Coffee and write way less code.
2. I can add Jade and write way less markup.
3. I can add manuel:viewmodel and write even less. At this moment, that’s my favorite Blaze related package on the Atmosphere.

Together, that’s a lot of a difference. I want to be able to do the same thing with Blaze 2.

[laosb]

Uh, It’s a little late for me to see this post.
As for me, I think React is the good choice, though I’m not quite satisfied with JSX.
The real problem is, lots of existing applications and packages need to migrate. It’s quite painful.
Blaze 2 should be fully compatible with Blaze 1, especially in syntax.

[aadams]

I agree with @brajt and @laosb on this, if we can keep Blaze 1 compatibility I think many would be ecstatic.

Also, I think React has some good ideas, but I think it is widely understood by MDG and Facebook that JSX is a problem.

[mz103]

The problem with backwards compatibility is performance (app size for features you might not use, speed, etc).

If they gave us an option of choosing Blaze 1 vs. React when creating a project, I think that would be the best solution.

But they’re kind of just forcing it on us.

[aadams]

@mz103

But they’re kind of just forcing it on us

In all this mess, this point is what doesn’t make sense to me. Why not have two or more tracks?

→ BlazeNext

→ React

→ Angular2

→ Whatever else comes along better than React

Why are we betting the farm (so to speak) on React by gutting Blaze? Why not continue with BlazeNext slowly or open it up to the community for PRs?

If MDG wants to be opinionated on React, that’s fine, but don’t take away (non-React) BlazeNext path from the Meteor community @gschmidt. If you don’t want to throw any hours at it, then open it up to the community, allow PRs, let it grow organically.

NO ONE from MDG will explain their reasoning behind this move – and I think this is wrong-headed.

It seems at the moment MDG is taking Meteor in the direction of a Facebook stack integration platform (along with webpack of course).

[casperandersen]

React, Webpack, NPM is now offering solutions to several missing features that we were waiting for Meteor to have.

Especially

• Conditional Loading <- which webpack solves with at least partly code splitting
• Components and higher reusability <- which react solves
• True Live Updates <- which babel and transforms solves with hot module replacement

Furthermore

• the general Node eco system has been abstracted away, rather than naturally integrated which leaves developers in a situation where they can see the other race car constructors/developers overtaking them in the fast lane, and their skill development being narrowed in.

So…

It is possible to get the things we longed for now with webpack, react, and friends, and MDG couldn’t see themselves keeping pace with their own innovation standing alone.

with Meteor 1.3 and ES2015+ modules steps are taking in the right direction, the npm eco system is being embraced with better access.

and React

• will Meteor 1.3+ make away with the need for using special react meteor packages and other bad choices like that?
• will it let us use react from npm?

and Webpack

• will meteor be able to surpass innovation in webpack and other projects that come along?
• or will they embrace webpack which still as of meteor 1.3 is needed to have code splitting and hot module replacement which are the killer features that there were no solution in sight for with blaze, and thus killed blaze.

[tjmonsi]

and React

will Meteor 1.3+ make away with the need for using special react meteor packages and other bad choices like that?
will it let us use react from npm?

and Webpack

will meteor be able to surpass innovation in webpack and other projects that come along?
or will they embrace webpack which still as of meteor 1.3 is needed to have code splitting and hot module replacement which are the killer features that there were no solution in sight for with blaze, and thus killed blaze.

I think for React, with the advent of Meteor 1.3, we can use react from npm… Might try it now
as for webpack, I think the ES2015+ import/export based on CommonJS which will be used in Meteor 1.3 is better and easier to use I guess… there has been a talk by Ben Newman at Empire Node 2015 on that…

[vjau]

I think MDG won’t develop “blaze 2”, and it’s their call to do so.
However i think they should continue to support Blaze 1, which means fixing bug (no new features).
Rewriting our blaze apps in React is just too costly.

[aadams]

I think MDG won’t develop “blaze 2”

You think @gschmidt’s wasn’t being genuine when, in his starting thread, he outline why and how they plan to build a Blaze 2?

i think they should continue to support Blaze 1, which means fixing bug (no new features).

I agree with this all the way.

Rewriting our blaze apps in React is just too costly

I’m trying to learn more about React and the like, but in the end, I don’t know how I’ll make the time to convert everything over to React, its just so much code – over a hundred screens written in Blaze with a good portion using Autoform.

[aadams]

@tjmonsi

…Ben Newman at Empire Node 2015 on that

Will you expand on this more?

[manuel]

Everything I’ve read sugested a blaze like template system that compiles to react was in the works… until now: Blaze to React wrapper (for package creators)

[aadams]

Conditional Loading <- which webpack solves with at least partly code splitting

I agree with this, I’ve needed conditional loading or code splitting for a while now. My Meteor application is getting so large now, the initial loading is taking longer. There’s no reason for the client to have everything when they only need a portion. Also, some features will only be active for one or two clients.

I welcome webpack, but does this have anything to do with Blaze or React? And if so how so?

Components and higher reusability <- which react solves

This is not a real problem with Blaze 1 in my opinion. I think components are overrated (not useless). Besides I’ve been able to build components within Blaze without React. Also, I like that Blaze is more flexible with data.

True Live Updates <- which babel and transforms solves with hot module replacement

Can you explain this more? Also, how does this related to Blaze vs React if at all?

the general Node eco system has been abstracted away, rather than naturally integrated which leaves developers in a situation where they can see the other race car constructors/developers overtaking them in the fast lane, and their skill development being narrowed in

To me this is a hollow argument. Why do I care how fast others are going? I don’t care about other’s skills or how employable they are. I’m not looking for employment. I’m looking to build a stable longer term company on a technology I can trust will be around more than a few months. I’m looking for tech that works well together. I’m looking for tech that can help me solve my business problems fast. Meteor was that for me and many others for what seems to be a glorious 6 to 8 months. Now the wheels seem to be falling off.

ES2015+ modules

I’m all for ES2015+modules.

[aadams]

Everything I’ve read sugested a blaze like template system that compiles to react was in the works… until now: Blaze to React wrapper (for package creators)

Thanks for pointing this out. It hasn’t even been a month since this:

So what we’re planning to do is to build templating on top of React, and to encourage Blaze users to upgrade to it (or, for those that prefer it, to plain React JSX). We think that this is the best possible “Blaze 2".

What a complete fiasco this has turned out to be.

[Ben]

True, everybody who loves Meteor will spank me silly, but the last couple of weeks it feels like the ball is being dropped hard… shame.

[juliancwirko]

Blaze is here to stay, if you want to use it just use it I don’t think that it will just disapear any soon But the technology stack is evolving. React and related tools are not here because of the hype, but because they are solving many problems. Working with Blaze in a really big projects is just a pain and this is a fact Just try it Blaze is great if you need to start a simple app very fast or you just need to show something in the MVP phase. But I think real apps based on Blaze are probably just a bunch of useful ‘hacks’ - well played hacks, but still hacks. After all this is just a JavaScript, you can do magic on this field. If you want, just do it. But why if you have an access to bunch of very good tools like React and many others? And still, Meteor is not just a front end. Blaze is just one of a simple tools in it. Just embrace the JS ecosystem, learn new things, work in some big projects - this is the best way to learn and understand things. Also I really hope that Blaze 1 will stay with Meteor. I like it and I use it but I will also use React. Honestly I don’t need Blaze 2