@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.
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/
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:
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:
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.
@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.
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.
@rohanray, let me address your only concern specifically:
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:
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.
If he were to do this the project size would shrink considerably. Java 8 is far more terse. It would be worth the effort.
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.
@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:
Together, that’s a lot of a difference. I want to be able to do the same thing with Blaze 2.
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.
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.
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.
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).
React, Webpack, NPM is now offering solutions to several missing features that we were waiting for Meteor to have.
Especially
Furthermore
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
and Webpack
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…
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.
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 agree with this all the way.
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.
Will you expand on this more?