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
I think he emphasized on backwards compatibility in his post at Why is the Meteor.install(1.3) api better than webpack in meteor?
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?
Cheers!
Ugh… I think I put it on the wrong thread. My bad… too many threads too many tabs 
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?
Will you expand on this more?
I am thinking in the context of webpack + react + babel.
For maybe about half a year or so(?)… it has been possible using webpack+react+babel to have hot module replacement in development mode in build systems using these technologies. HMR seems better than the current hot push reload in meteor, because it doesn’t reload the browser and it takes much less time for an update cycle in dev mode. Cases reducing from 45 seconds to 1.5 seconds is not unheard of. I understand this is possible thanks to babel and react, not webpack, but webpacks build system has made it easily available. Meteor using babel + react should also be able to do this without webpack, not sure this is possible with meteor + babel + blaze.
Code Splitting or Incremental Loading as referred to in meteor forums, and which could also be referred to as Conditional Loading (if user has permissions, or event, or route etc is triggered, or agent, or device matches…) allows us to only send the features we relevant, accessible or subscribed to by a user, keep the initial client thin which in larger saas applications is really nice, is using chunks, which webpack relatively makes easily available, compared to not possible at all with meteor without webpack or other facilitator(?)
In addition it should be worth mentioning SSR supporting proper SEO, is possible with React but not blaze.
My point being, these are killer features and innovation that could have happened in meteor or in another project in the wider javascript Node eco system. They happened elsewhere, and because Meteor previously had chosen a very opinionated bottle neck strategy which unless Meteor can always replicate, implement, enhance and extend in real time the innovation outside the Meteor community, would eventually leave us in the dust technologically. If that was the case, then Meteor wouldn’t be for javascript what Geoff Schmidt wanted it positioned, next to .net and java, but it would be a sidetracked sub par implementation where developers could only dream of code splitting, hmr “updates by injection”, ssr or at best have it half a year after the competition. And that would be a concern and a fear of lock-in which would be a hinderance to adoption, or should be.
However, with 1.3, modules, npm, it looks better. It is still to be seen, but it is good that it is being addressed.
And this also helps to address the other issue about skill set conditioning, which happens when developers are isolated from the general innovation, which is not just a matter of employability but also a matter of sourcing and recruiting new team members and developers with relevant skills, rather than a relatively more lengthy onboarding and training period.
It is possible to architect larger apps with blaze too, so I do not always agree with people saying blaze is a no go because of that. when people spend proper time and have experience to do proper structuring it can do a decent job. The bi-directional uni-directional difference between blaze and react does cause raise some interesting challenges, and we see mixins, composition approaches etc… a dominant pattern is yet to emerge, it is also interesting to see what comes out from the blaze react project with trackerreact etc…
my immediate (who knows what we want when we get this) wish list includes
- React and other NPM modules that should not requires no special meteor integration should be installed from npm, not atmosphere, and should integrate seamlessly with webpack when also added, which is still needed for HMR, Code Splitting, and other special loaders of interest. This also helps to ensure that we won’t fall behind with outdated versions of React not compatible with other packages we use from NPM etc.
Then we have HMR (in development at least), CODESPLITTING, SSR( for SEO), and better component design choices, things we have waited for years, and we can begin refining the stack. Promising times for Meteor land, despite the tremors. People who does not wish to invest in migation from Blaze can continue, but without the new tech innovation, and those who can invest can reap the benefits of innovation and get if not more, then at least Code Splitting, Incremental(Conditional?) Loading already now.
The application of @aadams is probably bigger than anything you’ve ever seen in the Meteor constellation, with more than 100 screens, and a lot of complexity.
Moreover, I’m sure that it’s much more than just “being lazy to spend $300K on porting it to React”; Let’s say that MDG didn’t try to kill Blaze, and that @aadams doesn’t have his company and application but is starting them today, I’m sure that he would prefer Blaze for its other advantages over React.
I get it mate. I’d like to have code splitting with webpack for example. I like change for the better, especially when it doesn’t too compromise something we’ve worked so hard for.
But then again, all the great things you spoke about, all the great changes and innovations Meteor is preparing for … is not what some of us bought into.
It was the promise of tightly integration set of smarty chosen technologies (one per level of the stack) that work great together, allowed developers to ramp up quickly, and help us solve business/technical problems fast.
Maybe we were all a just a little naive for believing in that world, believing that that utopia could last somehow.
Now ostensibly MDG wants to throw that away in favor of a more open framework, where developers can plug and play different tech at each level of the stack. This can’t be as seamless as what we had in the past. It seems to me the tight integration we’re use to is almost impossible to achieve with the open approach.
If React/Angular2 makes a breaking change with its interoperability with Meteor, then Meteor will need to adjust. If [INSERT TECH AT EACH LEVEL OF THE STACK HERE] makes a breaking change with its interoperability with Meteor, then Meteor will need to adjust to keep up. But I’ll give it to them, this approach might be easier than building the tech at each stack level. This approach requires less innovation from MDG, maybe less expensive, requires less thinking, and is maybe less risky.
All the developers that took a chance on Meteor, invested our time and resources into learning Blaze and the special way Meteor interacted with Tracker and Blaze, the techniques of Meteor as a full stack development solution, that’s time wasted.
With React comes changes to Meteor to adjust to the React way of development. It will be a almost complete development technique change for us. No more Blaze, tentatively no more Tracker. And this is just the start. Next it will be GraphQL and all that will bring along with it.
I’m ready for the great new innovations going on outside the Meteor solution platform. I’m ready to have code-splitting capabilities.
I hope in the end this transition makes our lives easier. I hope we will still be able to build apps lightning fast. And I hope Meteor continues to be as accessible to new comers as it was yesterday.
I hope MDG thinks it shares some responsibility for this transition with the Meteor community, and I hope we get the transition support we need from MDG. I hope for those on Blaze the transition is as seamless as possible. And I hope MDG listens to everyone in the Meteor community.
It’s too bad MDG seems to be focused so narrowly on Galaxy nothing has come from their camp in a couple of years now. It’s too bad that MDG seems no longer willing to take any chances on new tech of their own. Instead they are turning Meteor into a FB integration platform, and in so doing removing chances for innovation, ownership, accountability, and responsibility from the MDG. But I suppose Meteor was a means to an end anyhow, a cloud platform named Galaxy.
I would go to React fully with these conditions (at least for me):
- import statements will work in JSX based on ES2015 specs as well (I would be an import/export freak and doing away with almost all global variables)
- Be able to have full reactivity in React (I think the mixin has already have this)
- FlowRouter and Meteor can do server side rendering of JSX components.
Some optional add-ons:
- GraphQL reactivity (that would be a big plus )
As for Blaze being killed… I remembered in https://github.com/meteor/meteor/blob/release-1.3/packages/modules/README.md#modular-application-structure it says there that:
that means, not all JS files will be evaluated and there would be one entry point to evaluate all JS files (if I understood it right).
And from the example at https://github.com/meteor/meteor/blob/release-1.3/packages/modules/README.md#modular-package-structure it is not clear how ES2015 can help in also loading/importing html Blaze template files. I mean, you can now create a build order using imports inside the client.js file and make it as an entry point with api.mainModule("client.js", "client") line… but it leaves the question: “should we still use api.addFiles” to evaluate and define the html files? If so, then you would now have two files to define the build order of your blaze templates: the client.js file (for all the JS files that you need to import), and the package.js files (for all the HTML files you need to define as the template)
If it is in JSX though, you will just need to put (I guess) it in the client.js file, use api.mainModule("client.js", "client") to make it as your starting point, and then import all the jsx files from there… The build order and import is easier…
As a plus, you can create npm packages with JSX and do away with Atmosphere packages for those components…
MDG didn’t build React, but they DID BUILD Blaze. They built Blaze, integrated it with Meteor, and we had to learn it in order to develop with Meteor. It was inseparable from Meteor. Therefore they took ownership and responsibility for it. Now it’s MDG’s responsibility I believe to ween us off of it as smoothly and seamlessly as possible.
I’m calling for MDG to creating a upgrade path from Blaze 1 to React in support of the Meteor development community: Documentation, videos, presentations, best practices, forum answers (a special category for this), any tools that might make it easier, and general support.
Maybe we shouldn’t call Blaze deprecated. I’m using it in some places and still think it rocks. Its not perfect - sure - but neither is Angular 1, and I believe Angular 1 is also similarly abandoned.
Blaze can be a good, fast MVP solution. It only needs a bit of love to become a lot better. Mainly - incremental loading on the front-end, which is almost here with Meteor 1.3. Otherwise:
- its fast,
- the reactive updates perform well
- SSR is not a vital feature for applications
The main problem I and other’s have had with Blaze is that you have to push down a huge app on the first load. I think if that were solved, Blaze would have many good use cases.
ok, could you just please stop and let us run our meteor app without breaking changes for at least a year or two? I mean, i could barely apologies on behalf of you guys to my boss that the upgrade to 0.8 was painful as fuck, it took 2 weeks of not delivering ANY business value, and now THIS?! no, srsly no! This is more than just swapping out a lousy template engine with another lousy template engine, this is about having 2 kids at home that need food, and a mortgage to pay, where the hell do you guys think that corporate wants to pay me without delivering value to the customer?! They will consider Meteor (and thus, me) a liability instead of a asset.
You guys should really focus on trust here, cause having a yearly breaking change is not acceptable. Look a Django for its depreciation path, where you slowly evolve to a new version of something, instead of breaking the app leaving us, the soldiers at the front, before the managerial firing squad. Just leave it alone for a couple of years, and focus on and focus on your 900+ tickets on github, or the 99 open pull requests, instead of breaking stuff, again.
Sorry for being so salty, but this wil be the final straw for the meteor project at the company i work if this happens.
Can’t we all just go build cool stuff?
If you like Blaze, awesome; use that. It works today and will still work next year. You like Angular, great. You like React instead, great. Just pick one and build something people enjoy.
I’m positive everyone could have learned X framework with the amount of time spent in this thread.
React helps my large apps from crumbling and aligns with the functional methodology (which I enjoy) so I’ll pick that one. You should pick the one that makes you most productive/happy.
My proposal for how MDG should handle this whole situation:
- Keep Blaze around as an introductory, “training wheels” solution for smaller apps and quick prototypes. Don’t deprecate it, but make it clear what its downsides are (no code splitting, no SSR, etc.).
- Spend as little time as possible on it. Don’t introduce any major new features, maybe just try to get low-hanging fruits.
- Transfer control to the community. This can be a gradual process, leading to some kind of Blaze working group that’s independent from MDG.
- Recommend React as the “real” front-end solution for any serious production app.
- Do not waste time on a Blaze-React bridge or migration path. It’ll take up resource, and nobody will be happy with it since Blaze people just want to keep using Blaze, and React people are already using React.