We are in the process of starting a complete new app. The suggestion we got from the experts now is: learn with Blaze (tutorials, books available) but at the same time develop on React (future ) !!. “The problems you will encounter like incompatible packages like i18n, … wait them out until you have enough expertise to fix yourself or that the volunteer creating it might have time to fix.” Maybe during his Christmas break ??
Ahh… we are a corporate trying to make money and serve clients for years to come and this does not give confidence, really. It would be nice if we all understood that. But maybe you are right, maybe the best options is either forking or accepting Meteor turned to dust upon impact… But not appealing, that is for sure. Please, the reason so many people did not yet turn their back on Meteor is that it is (still) a great platform we really, really like(d?).
I think @sashko et al answered the question (here or elsewhere, don’t remember) why the current guide uses Blaze. I hope when Blaze2 is released and/or they improve React integration, the guide will be updated accordingly.
As far as the suggestion on what to use for new apps is concerned, it was a generic one from what I understood. Did you get the same suggestion when you provided more details like the project kickoff and delivery times, packages you’re basing it on, etc?
If you are heavily invested in, or reliant on, Blaze and its packages, I think it should be safe to use it for the new app. The sense I got from MDG’s communication is that there would be a migration path from Blaze1 to Blaze2. If you’re basing a business decision on it, reach out to MDG, through this forum (I’d suggest a new thread) or phone or whatever gets you a definite response!
Package/Plugin compatibility is definitely an important consideration whenever there is a major change in a framework with an ecosystem. But it would be unfair to hold MDG responsible for compatibility of packages they don’t maintain. They have articulated their reasons for the move. Now we (including MDG) gotta figure out how to do so with minimal impact! Simply opposing the move altogether is not constructive. We could take examples from other open source projects who face similar situations. This is what we did for Grails: https://github.com/grails/grails-core/wiki/Grails-3-Priority-Upgrade-Plugins (Btw, one of my business apps built with Grails is still on Grails 2 and with new features getting added regularly. I didn’t have to upgrade it to Grails 3 just because it was released.)
Of course and you are so right here. Actually, I am for one willing to fully go with React and bite the bullet, even happily. My objection is not React at all, it is the patterns we see here.
The point of objection is that MDG leaves so many things dangling that it becomes a pattern and instigates ecosystem splits: announcing both React AND Agnular as “1st class citizens” ??? Just as we know Iron, we need to go for Flow?? Now i18n is shaky, what to do? Cordova/Mobile? Why all the Coffee pollution if they also consider Typescript? … and so on.
Anything that is not Meteor’s USP, let’s take one and stick to it, even if not always the latest greates. All the other very welcome but 2nd class citizens, can live happily as community.
What I am asking for is more opinions and official consistency from the leaders, not less.
But isn’t the reason given for this move (Blaze2 = templating layer over React) precisely to help fix some of the issues you pointed out?
I agree in principle that we don’t want an ecosystem split the way you described. But let’s not confuse it with a perfectly valid approach of supporting multiple options where it makes sense. I got to Meteor because I found it to be a good backend for my React app (that was a few months ago). Now I’m considering Ionic + Meteor for a mobile app. So I for one am glad that Meteor wants to take this approach for the view layer.
I do agree with the principle of what you’re suggesting. But the answer to that is not as straightforward as we all would like it to be. So, like you, I hope MDG leadership reaches out more often, and whenever that happens, I also hope the entire community keeps the discussion within context and constructive.
Indeed and I agree mostly for sure. I am also pondering over Ionic…
I still feel we need a reference platform. One that we can all test and develop against. That still leaves room for supporting multiple options, but at least we have an agreed full stack to start from.
@fvg, nice, thanks for this. This is just what some in the Meteor community have been warning about – this same discussion all over again before we know it: start the video at 10:55
This is one reason why we should keep the view layer in-house, so we can choose to what features to add and when to add it — on our time, when and what it makes the most sense to us, the Meteor community.
Not when Facebook or someone else tells us something is better or cooler or it’s time for change just to excite developers with new tech.
I’m not thinking of BlazeNext built on React or the flavor of the day, but our own home grown, native solution!
To calm, I’m not suggesting BlazeNext should be the only option, just the PRIMARY, SUPPORTED, and BUG FREE option!
MDG is a business after all, take the pulse of the Meteor community as to if they’d be will to pay for a all native BlazeNext.
I’ll repeat here what I’ve been talking about in some other threads, and I’m giving a short Devshop talk tonight in San Francisco (http://devshop.meteor.com/) about this as well:
Meteor the framework/platform needs to become more flexible
The Meteor guide will be as opinionated as possible
I think this hits the best of both worlds - React and Angular can both work great with Meteor, and you should be able to use any other view technology you want - Vue, Blaze, Mithril, Handlebars, whatever. However in specific versions of the Meteor guide we will recommend exactly one thing as the main option of the day.
This means that the guide can change its recommendations when necessary to stay up to date with the best practices, but your app will still work fine even if you’re not on the newest hotness since the core will be flexible. This answers basically all of the points above:
The first router recommendation we’ve ever made is to go with Flow Router, but it should be possible to use any router you please.
tap:i18n is great for Blaze, we just need to work with them to make it more flexible, aligned with the philosophy above. I wouldn’t say it’s exactly “shaky”.
Cordova/mobile is being actively worked on. Meteor 1.3 is going to include a huge amount of improvements for hot code push, the cordova wrapper, WkWebView, Crosswalk, and more. We’re also writing a guide article about how to use all this stuff correctly. On the other hand if you want to write a native mobile app there are a ton of options - simple:rest, meteor-ios, etc.
CoffeeScript has never been used in any core Meteor packages, code samples, tutorials, or example apps. A lot of people in the community like it and that’s great, but there has always been an official Meteor style guide on the wiki, and it’s clear that we’re totally on the JavaScript boat. The first version of the guide is going all in on ES2015, with a standard linter configuration, built-in transpilation rules in Meteor core, updates to the example apps, and more. TypeScript will likely be the preferred way to go for Angular 2.0, but there isn’t anything we can do about that.
If there’s an opinion you want us to take in the Meteor guide and we’re not doing it, let me know and I’ll add it.
Excellent, @sashko ! I would think that this is what we need :))) As MDG you are leading the platform choices, if you like it or not
I can imagine you would have, beside “meteor-core”, something like a “meteor-recommended” pack following the doc you are writing. This pack then bundles all mainstream packages you feel demonstrate Meteor in its best shape and form.
The “meteor-recommended” would give developers an uniform deployment & testing setup, will guide newbies in, help the tutorial writers and keep Stackflow focused.
You are silencing me on the whole blazing react storm and I hope a lot more smiles to come
@sashko Is there any possible way the Meteor community can get a deep dive youtube video on Rewriting Blaze 1 into React components similar (but more indepth) to the one @fvgposted above?
I want to try my hand (if it’s possible, correct me on this) at taking a peace of out of one of my templates, say a list, and converting into React. I don’t want to replace the Blaze 1 template, helpers, events – just isolate a list in the template and convert it to React. Maybe even have some form of communication between the React (list) component and the Blaze 1 (template).
Also, can we get a HowTo or something close to it as well?
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.
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.
