Actually, between a React frontend and a Meteor backend, we’d be far more likely to keep the Meteor backend and ditch React for webcomponents. Because that fits our industry and usecases way better.
Quoted for truth.
I’ve been thinking that what’s needed is a good diagram explaining transpiling and refactor flows from higher-abstracted languages to increasingly pure javascript. There’s definitely a way to bridge these two paradigms, but it needs to be framed as not being an either-or decision, and the refactor/migration paths need to be documented. And that probably means official support for jsx-templates (aka Sideburns).
Word. Count me as another person in the web components camp. The JSX in React is reminiscent of XHTML in IE6. For those of us who have been in this game for awhile, it smells of monopolistic embrace-and-extend. Maybe things will pan out in React’s favor; maybe not. I’d like to wait for it all to get baked a bit more before making a decision. In the meantime, our Blaze code is well structured, and we’re hedging our bets with a preference towards webcomponents.
Personally, I think it’s possible to thread the eye of the needle, and get webcomponents that are built using the Spacebars API, which runs on top of React, by way of a Sideburns replacement to Blaze (maybe call it Inferno?)
Exactly! Most of my clients don’t care what exact technologies we use. The difference between Blaze and React is trivial compared to the difference between Javascript and C++ or Java or PHP. We rely on Meteor to make some/many of those decisions for us. So, we’ll go along with whatever they decide. But we do need to know that there is a stable base for us to build on.
Yup. It’s going to be interesting to see how the React community responds to the bubble ending, and we find out how many people were on the bandwagon simply for the new language specs, or were in it for everything else.
I wanted to say sorry for using rude language against my brother’s wife. Anybody who felt offended by that and flagged it, I’m sorry. I’ve edited my previous comment about her.
What! We got whole families of Meteor devs in here? Wow! Also your brother’s wife sounds cool. Your brother more so for having such a wife I wish I were to find a girlfriend to whom I could say “I’ll sigterm you!”
I doubt sigterm would be enough in her case. No, she’s not only not a developer, but she stopped me from teaching her sons basics of programming, so they don’t become nerds. But it’s an off topic, so I’ll end it here.
I think that React is amazing. I actually never used Blaze even not the previsou template engine handlebars. When i found React, i already knew about Meteor (Meteor was that time somewhere in very early times) and i said my self that these two will be great tools of the future development. Now it looks it is going to happen and it is good for everyone. SUPPORT REACT AS MUCH AS POSSIBLE.
You present it as if you have to choose between: opinionated & stable and unopinioted & unstable. This is like asking people if they want to choose between good health or money. But it’s a false choice, since I don’t think they are mutually exclusive.
Angular has more people working only on a frontend framework than meteor has on frontend, backend, communications, tooling, database, … together. There’s just no way to keep Blaze up to par.
The only thing this is bad for is tutorials and packages that are not universally applicable anymore. It’d be hard writing a book for meteor nowadays. It’d get even harder if they include SQL support instead of only Mongo, but I still think that has to happen in order to secure the future of Meteor.
Btw, React people might be a vocal minority, but this entire forum might only contain a minority of Meteor users and give a very skewed view. Look at this thread: it is narrowed down to react vs blaze. Now React might be the new hype in Silicon Valley, but I’ve asked around to my contacts in IT recruitment companies here in Europe, and they have 0 requests for React developers. Most enterprises are still training their Java/.Net developers into Angular developers. Now these kind of companies are interesting for Meteor’s financials (and therefore for any Meteor user) and it’s much easier to convince them to use Meteor if it supports Angular.
I personally now have just decided to move to React. In many important aspects it’s just better than Blaze I think. MDG has created a nice migration path for Blaze to React in Meteor 1.2, so there is no problem in moving to React step by step. You can just convert templates as needed bottom up the template hierarchy to React and you can also have both at the same time while you migrate.
In my opinion MDG should recommend React as UI component part and put their efforts into other parts of the Meteor platform. Because for apps that eventually get large you would have wanted to start with React anyways and by recommending React to start with, less developers will need to convert to React later when there app got big and their view layer got messy before they realize. This could potentially save a lot of resources.
Should we also recommend people to use GraphQL and Relay instead of Meteor on the backend, so that people don’t have a problem later with switching, when GraphQL becomes the new hype?
2015 may be the React year. 2016 may as well be Angular 2 year. Who knows about 2017. Switching recommendations every year won’t lead anywhere.
Almost every one i know loves react right now… But what if Angular 2.0 comes out?
What if there’s a webcomponent engine that just loads a webcomponent and be a reactive reusable component that can act like a layout and also a component as well? And it also supports double and one way binding? Very light weight too… Would that be more superior than react, blaze or angular in the future?
For me, react is what node js when ruby on rails what the thing, ruby on rails when PHP was the thing, and php when .net was the thing…
MDG might be in the crossroads right now… And i guess it is a good move for now to accommodate react and angular. It is a bad move that they are not updating blaze to be more reactive and “scopish”… But if they can create a better component based rendering system that is very light weight, not entirely dependent on jquery, and easy to debug, test and code with… Plus the ability to render webcomponents and not clash with {{ }} [[]] then i am all ears
I don’t think front-ends and back-ends are really comparable in that aspect. Backends have seen more evolutions than revolutions and you have a much longer lifecycle (you can probably still run your PHP4 apps for another 10 years). In the meantime, the languages adjust to each other (PHP even tries to look like any other language in the world). But in the frontend jQuery is still jQuery. Backbone is still backbone, … and change always comes more as a revolution in the form of a new library. Why? I guess because we’ve been abusing an unfit platform into doing something it was not meant to do. That’s why it takes a lot of iterations to discover what works well and to evolve the platform.
It’d be foolish to think that we’re at the endpoint. It’s our fate as web developers to keep adapting to new stuff. Maybe sometimes we’re following the hype to fast, but still, we’ve seen the evolution: all jquery widgets → backbone → Angular/Knockout → React/Angular2 and I think nobody who’s gone through the process ever wanted to go back to a previous stage. IMO, we’ve gone from a platform I hated for developing frontends to a platform I prefer to any desktop/native mobile front-end technology I’ve ever used.
So yes, in 2 years there will be a new favorite library, and we’ll probably be better of using that one.
And hey, in the meantime companies pay for people like us to upgrade their old app, so that’s positive ;).
Problem is, some of us are either people who will have to rewrite their own stuff or who will have to pay for that. People who are not hired to work on others people webapps, but who develop their own ones.
An honest answer to the question “what’s exactly going to happen with Blaze from now on” is the least they could expect.
I am currently quite pleased with what Blaze can do. It most certainly one of the things that initially drew me to Meteor. I personally don’t want a templating engine as verbose and sophisticated as say, Angular. Since there are larger projects where that level of sophistication is relevant, of course Angular and React should be supported by Meteor-- for those who opt in. I wouldn’t mind enhancements to Blaze, but I would be opposed to an outright deprecation.
This, which in theory is part of the complaints within the community interaction thread. The community has to interpret what MDG is doing independently of what MDG says. Look at the Trello roadmap is this still valid? I don’t think so… Move routing into core is still marked as Future. New, object-oriented API for UI components is still in Future??? With the guide coming down the pipeline how about the meteor manual?
Right now MDG is in the driver’s seat for Blaze but for all intents and purposes have taken their hands off the wheel. @mitar is all like I’ll drive this thing, but MDG effectively says this is our bus so no you won’t. So no one is driving the bus, and the community in the back is all concerned, and then @sashko calms everyone down by explaining why the bus we’re on isn’t as nice as other busses so they don’t really want to drive it any more, and it is probably wise to try to jump onto one of those other busses.
So IMO drive the bus or get off the bus and let someone else in the community drive it. I’m sure @mitar would be gracious enough to accept pull requests from MDG.
But it’s an off topic, so I’ll end it here. 