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.
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.
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?
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.
Can you explain this more? Also, how does this related to Blaze vs React if at all?
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.
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
I don’t understand how someone can say their point is a fact, when in “fact” their point is clearly opinion. I have a large application, and Blaze has been superb. Moving data around has not been a problem. I have plenty of view layer components and use them on almost every form.
It seems you could be misinformed or are misleading.
How big is the project? Could you describe it? And of course don’t get my words so literally, by ‘fact’ I mean many complains from developers with which I spoke and also my own experiences thats all.
Nothing suggested that React will be the only thing you can use with Meteor in the future. Of course you can continue using Blaze 1. I’m not sure where you got the impression that we are forcing React on everyone.
In my opinion, dropping Blaze 1 bug work, future development, and support in the form of opinionated documentation and examples is “forcing” us to accept MDG’s “choice” of a default view (in this case React, but even Angular is now supported) if we are to continue using MDG’s opinionated integration framework (aka Meteor) over the long haul. And I for one have no choice but to use the Meteor framework due to my circumstances.
He explained the part why Meteor will use ECMAScript2015’s import and export capabilities and how it will be implemented in Meteor and not just use CommonJS or any other things here: http://benjamn.github.io/empirenode-2015/#/38
Thanks for the links mate, I’ll read them for sure. Sorry mate, but did you mean to post webpack and import/export modules (excited about these by the way, especially webpack) references on this thread?
I thought so mate. If you want to post that to the other thread and delete it here, I would back you up by deleting my response to yours and reposting on the other thread too.
Ah… Now I get it… You were asking on expanding on Ben Newman’s talk on webpack/commonjs. I was reacting to @casperandersen’s thoughts on webpack and if meteor will be able to surpass innovation in webpack or will they embrace webpack.
I’m really excited with where this is going… you can now use NPM modules in Meteor without Atmosphere package wrappers… but I can’t really switch to React as of now given that Meteor 1.3 hasn’t fixed the transpiling import statements in jsx files from the react jsx package.
But the problem here also is… with the advent of import statements in Meteor 1.3, Blaze will sort of be killed in the process because there’s no clear way on how to “import” html files. I mean, if later on we will be using NPM modules, Meteor packages might be obsolete in the process… but I still need a form of control for the file loading mechanism, especially html files if we are still going to use Blaze, without being constrained on the folder structure.
Do you think this will be corrected with 1.3 goes live? What are the conditions (going with webpack for example) in which you will not be able to go with React in 1.3?
I don’t think that it will just disapear any soon 
