Next steps on Blaze and the view layer

[mbrookes]

@aadams - MeteorChef has a pretty comprehensive write-up of converting the metoerchef base app to React:

https://themeteorchef.com/recipes/getting-started-with-react/#tmc-converting-existing-templates-to-react-components

[Stan]

meteor-recommended sounds like a great ‘guiding’ light for the community. Especially keeping people new to the platform on the same page. I +10 this.

[aadams]

@mbrookes thanks for that.

I haven’t read it yet, but if it goes into how to convert from the bottom up – not the top down – (component by component, I’m talking only a portion of a Blaze 1 template small), similar to how it’s done in this video from @fvg above, then I look forward to reading it.

[zone]

Quite upset that I wasted money purchasing outdated Meteor books like Discover Meteor, Meteor in Action, Testing Meteor, EventedMind video tutorials…They all mention Blaze, Iron Router, and god-knows-what other obsolete recommendations.

Looks like I’ll be sticking with the far more stable and customizable Express framework and just moving my DB to RethinkDB, and from Handlebars to React.

I guess Meteor is great for Node.js/JS beginners though, compared to a serious realtime stack like this: http://blog.workshape.io/the-3ree-stack-react-redux-rethinkdb-express-js/

[mbrookes]

Until Blaze 2 arrives, if you only want to convert part of a template, this may help: https://react-in-meteor.readthedocs.org/en/latest/react-template-helper/

There’s also this project, but it’s WIP, so not complete yet:

timbrandin/blaze-react

[dandv]

@rohanray

Do I still like Java today? My reply would be yes absolutely

Java is a very verbose language, compared to ES2015.

As an exercise, try creating a simple photo sharing app in the Java web framework of your choice, then compare how many lines of code that will take, vs. 50 - 250 in JavaScript:

Demo app: Instagram clone with Maps & extra features in < 300 lines of code

I’m happy to announce an open-sourced demo Meteor app for sharing picture and text notes, and plot them on Google Maps: Instagram clone [image] Features in addition of what you’d expect from Meteor (OAuth etc.): cross-platform picture taking real-time plotting on Google Maps shake to undo Material Design REST API with restivus toast notifications The code is educational, and the commit history takes you through adding each feature gradually. It should be a great learning tool for those m…

Code is written once, but read many times, especially in teams. Readability is a huge win. Java is far less readable than ES2015, both in its intrinsic syntax and in its APIs.

[rohanray]

@dandv Yes, you might be right in comparing number of lines of code. Unfortunately, that was not the point in context of the whole article which I had written out of which you picked one statement.

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.

Within the span of two years, Meteor would have undergone 4 or 5 major revisions deprecating the incumbent tools and frameworks used in Meteor. So probably, I would have to write 250 lines of code every six months and test it to keep my “photo sharing app” running and supported by current Meteor version.

This was my only concern that I tried to portray in my article. Nothing else!

I have moved to using Meteor for precisely the reason mentioned by you and if I go away from Meteor, it might be because of the reason I mentioned.

[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.