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)
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.
I’m all for ES2015+modules.
1 Like
Thanks for pointing this out. It hasn’t even been a month since this:
What a complete fiasco this has turned out to be.
3 Likes
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.
2 Likes
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
1 Like
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.
3 Likes
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.
1 Like
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.
4 Likes
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.
1 Like
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!
1 Like
Ugh… I think I put it on the wrong thread. My bad… too many threads too many tabs 
2 Likes
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. 
1 Like
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.
2 Likes
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.
2 Likes
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.
1 Like
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.
3 Likes
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…
1 Like
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.
4 Likes