You’re iterating on your own supposedly-only-solutions-based-on-presumptions, and why they’re not valid. You refuse to consider others’ points and label them fallacious if they’re not in alignment with yours.
I’ve only replied directly to you twice before this. Are you mistaking me for someone else? You’re probably treating everyone not aligning with you as a single opponent to defeat in an argument. Most of us are not here to score debating points. Not me for sure.
Someone as good as you in identifying fallacies should have been able to see them in his own arguments. Alas! Wonder how anybody’s comments would help you if you adopt such an approach. Hope you find your answers and solutions somehow. Cheers.
How do we explain this to those who bet their future (and their money) to us? That they will have to pay again to update their platform to the latest version in 6 months (more work hour to upgrade).
Ok before we talk about payment, how will they respond to this kind of situation? They are (most likely) business entities who deals more with RoIs than keeping up with platform updates security or efficiency. They wouldn’t care if meteor is whatever compared to php or c++ or should they upgrade or not, but if security upgrades are necessary (with hours of work entails) who pays for our work hour then? I can immediately imagine the look on their face…
EDIT: OK, nobody says blaze is going to be deprecated, but my dread has already there. Now I’m not sure if Meteor is ready for long-term projects. Maybe Meteor is not meant for long-term enterprise projects? Thoughts?
I think most of us just need a confirmation from the MDG, that all projects are written using Blaze, will be fully operational, for example, 3 years. During this time, even a very large project can be completely rewritten in the React.
And after all someone tell me how and where to use observers in React?
If that’s the case they really don’t take the forum any seriously and we should draw some conclusions from that. If the willingness to communicate is not there it’s very hard to get it fixed.
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.
