MDG had no choice to but address this situation, and in so doing they knew they would open themselves up to criticism. I’ve seen a few excuses for the policy change, but all seem contrived.
MDG will not publicly state the reason they are abandoning Blaze, but it’s obvious. MDG is a business with investors, they have a fiduciary duty make a profit. Their publicly stated revenue source is Galaxy. In order to expand the Galaxy user base they must make Meteor appeal to as many potential Galaxy users as possible. What better way to do this than to adopt the most popular JS front end frameworks of the day?
Expect more of the same. Expect more front end replacements as new popular frameworks come online. Expect data storage replacements too. Meteor will do a 180, and instead of being an opinionated framework, it will become a un-opinionated framework – with the goal of appealing to as many as possible – which of course MDG hopes will broaden Galaxy’s user base.
Be thankful really. MDG is going to accommodate us with a Blaze overlay in the mid-term. It could have be worse everyone. They could have said ‘No’ to any transitional bridge to React.
Say goodbye to the Meteor of old, this is just the beginning.
I don’t think MDG really knows what they’re gonna do. I think they’re backlogged and they still haven’t even started this. They were under pressure by us due to the last Blaze thread, and knew they had to say something. So the CEO gave his best guess on what the way forward look like. I’d say their decision here is still likely very much in the air. Hopefully–given all the tools will exist to make Blaze 1 render with React–they will rethink their supposed “decision.”
With what I’m working on you will be able to continue to use Blaze, exactly as is, with no extra work–either on its own or alongside newer React-based components. For the newer React-based components (maybe lets call it Meteor.Component) we mixin in all the tracker-based features, etc, to make it operate in a very Meteor-like manner. I’m already like 40% of the way toward making all this possible. I have done preliminary tests on what feels like 100% of what I needed to know to know it would be possible to render Blaze 1.
So we get this done, then push Meteor to make it a first class aspect of their upgrade strategy.
Every business has to spend effort marketing. Nothing is more powerful than word of mouth. Nothing. Community and customer turnover are also bad things for a business. MDG knows this. Consider it–Meteor’s investors invested in GitHub. Sure you can get a paid GitHub account, yet I bet most people use the service and pay nothing. They know what they’re doing and abandoning the community is the last thing they’d do.
So far everyone has been in good hands. Let’s see how they respond to the community on this. Personally, I want deep SQL/Postgres integration!
totally agree. React + Module/Webpack work are the key ingredients to making sure Meteor keeps up with the rest of the Javascript world (in addition to getting our tooling to the tightest point its ever been). We gotta rejoin the main branch so to speak and look like what everyone else is building, and offer what they are capable of. That way we aren’t scaring everyone away by giving them “lockin-itis”. Modules/webpack will do a lot more to further that vision.
No one said they had any intention of abandoning the community, on the contrary they want to expand the community.
My point was, what better way to do this than to open up their framework to other, more popular technologies… with the goal of expanding Galaxy.
I’m one of the ones greatly affected by this as a startup-owner who bet my company on Meteor and Blaze. I can’t afford to replace Blaze with React, as my codebase is too large and is in production at this point.
I just hope somehow MDG will create an upgrade path that won’t cause me and others in my situation too much rework.
I’m a designer / front-end dev that spends a lot of free-time working on template first platforms. Came from python/django, express/swig-spacebars-nunjucks, then meteor which I’ve rolled two sites on.
React might solve some scoping issues, but the templating is an abomination. Of course injecting HTML into javascript functions gives more control, but you don’t need React to do that. JSX breaks standards up and down and is a modern day callback to ngApp bloat and div spam. It’s clearly a temporary solution to an ongoing debate which can be solved many ways when not considering standards. Today I can render a HTML template in the browser without any post-processing and see if the markup holds up. Looking at these JSX return examples how not to cringe at what MDG is backing? React is going to change by the time Blazeferno rolls around and instead of being at the mercy of your own templating platform (which is neglected 120x) you’ll have no choice but to bow to whatever changes faceborg makes.
Meteor has been a fun caveat in discussing node platforms with my designer/engineer colleagues and friends regarding side projects. Seeing the writing on the wall since the 1.2 decoupling and strong @sashko bias on the meteor-guide, this seemed likely. I have no problem rolling a site on express/mongo/whatever. Removing a clean and separate html/js templating language in favor of a a corporation’s “open source” jsx format is beyond a deal breaker.
Well, I’ve not read the Wall of Opinion in its entirety (though I did take a good stab at it), I do feel that Blaze was a big part of what made Meteor feel so great for rapid development. Personally I’ve seen my use of Meteor change and recently implemented it only for the oplog-tailing and DDP to be integrated in an existing Angular project. I had already moved past making the mistake of using it as a surrogate for other monolith-makers like RoR and whatnot and tried to exploit what it worked well for (on my projects anyhow): reactive UI, free near-real-time data sync, a braindeadeasy system for adding functionality via packages. The real work of the systems was then done by micro services that actually transit, transform and store data.
This recent shift towards React/Angular and away from Blaze is a little disheartening to me only because of how much I enjoy the handlebars syntax and how easy it was to do simple things quickly. Learning React is in the cards for me, however like many here it does feel like a departure from that romantic ideal that you can wave you hand over the keyboard and have a collaborative near-real-time app come into life needing only some styling.
I’ve been working on Meteor since mid 2014, so I don’t know how things were managed in the past.
I’m just respectfully saying that abandoning the proprietary view tier of this platform when you are at release 1.2.1 can cause people tons of problems. That said I don’t see any other choice other than moving on.
My next question is what should I do for the future. You cannot work on a customer project and when you release it tell him that what you’ve done is gonna be obsolete in 6 months.
Stability is the key here, don’t you think so?
That said, next week I’m gonna teach to a class of 20 developers in Italy how much Meteor is beautiful and why they should adopt it as their next development platform.
Fantastic of course. And at the same time I wonder why especially the most advanced technicians ignore return on investment arguments.
It is maybe because these advanced programmers create every line of code themselves. However the majority is more like “Google cut and paste”- and “reuse a package”-programmers. Now, when we Google, it happens more often than not, that we think we found some solution for a problem we have, only to see it is not usable as it is using a different religion (Blaze/React/Angular/Coffee/Iron/Flow).
I read your other post and thank you for it. That work seems to bring it together again as it should. As a large corp however, we dont feel secure until we know that the top management of the core shows it understands as ell that keeping one solid ecosystem is still more important than jumping around. No matter how many problems the jumping solves…
But again, you bridge two worlds and that is even one of the reasons why we incline to still use Meteor as per our original decision in July: Blaze was good enough. The split-eco system is not. The future still blurred…
@faceyspacey: I respect your hard work, and I am glad that you are doing it. But nevertheless, it still makes a huge difference if such an endeavour is being done by a single community developer, or if it is backed and driven by the company maintaining the core product.
Maybe we’re lucky and MDG will pick-up your work. Maybe we’re not. Or they’re developing their own solution, which might then be incompatible to yours. It’s this uncertainty and the ecosystem split that makes me worry. I want to focus on getting “my work done”, not “bet” on the future directions MDG might probably take. And it is also a matter of building up “trust” in the platform.
Yes, we’re living in a fast-paced technology world, especially in the JS ecosystem. But throwing away a core part of the technology stack when the platform has just reached 1.2 does not seem very reasonable to me.
I personally think it is not unlikely that even if there will be a kind of “Blaze bridge” (yours or MDG’s), this might end up as a “side-chain”, whereas the “cool things” will only be available on the “main track” (i.e. React). Also, because the concepts of React are so different from Blaze’s. So, at least for me, React seems to be “the way to go” from now on.
That is correct.
MDG team is probably looking at the community best interests, but from their point of view – which is not exactly the same of users and companies which are betting their future on Meteor. People like me who spent the last 20 years or so working and fighting on customer’s project, paid by the hour, know that. It doesn’t mean you should design a platform evolution path with no innovation on the initial roadmap, but you should be very careful not to left your customers behind or, even worst, lose them foreever. Meteor can definitely be an enterprise level platform, but it should be closer to the enterprise needs and pretty often good enough is better than perfect.
So the solution in this case is to keep Blaze and make it better during the years. Then create a new project to provide a better integration for React framework into Meteor’s reactive template architecture.
Two different packages for two different customers of Meteor’s software.
So many bridges, packages to implement Blaze in React, other weird stuff…
The time you spent on your messages / bridges / packages will be probably enough to read React docs and rebuild your apps with it so that you can finally stop worrying and start enjoying this great view layer and the opportunities it gives to you.
The goal is to render ur old blaze 1 code with react and allow you to code in the new react based components along side it. Ie the the whole enchilada.
MDG made their announcement without doing their homework and have likely not even started work on this. Evan has no commits in this area and told me in the Sideburns forum he’s still busy with other stuff first. We can change their decision by showing them the way.
To the Meteor Community and MDG and @gschmidt in particular:
@gschmidt, thank you for the feedback. This couldn’t have come soon enough for some.
Since Blaze is already tightly integrated with Meteor/Tracker, what is wrong with the Meteor Community forking Blaze today and continuing its development by the community? Then all we would need is a commitment from MDG to make sure the hooks Blaze has into Meteor/Tracker stay as they are today on the community fork? Can’t this work for both the Meteor Community and MDG?
I for one do not wish to use React, even under a Blaze overlay, for reasons clearly explained in prior posts – not the least of which is compatibility with JQuery and the separation of concerns issues.
Wait… isn’t that the very same Durandal guy who told his entire community “screw Durandal, let’s all join Angular 2” and then after few months told them “screw Angular 2, let’s do our own new framework Aurelia”?
Is not the same thing happening here on this topic, deprecating Blaze because it does not hold it’s own due to changes on the web?
As I recall his original intention was for a unification of Durandal community and Angular community as to embrace the changes more concurrently because of the similar vision when they started to collaborate.
But it looks to me that someone did not hold up to the initiall aggrement. Not sure.
But, also a fact, Angular 2 had many rewrites, is far more in development and it is still not at beta.
Aurelia has in shorter time hit beta, and is more intuitive to use (just my opinion, check for yourselves).
Folks have been doing production apps months before it hit beta 1.0.1, because of the underlaying structure.
Why he left Angular 2 for Aurelia is all over the web.
This also needs to be checked, but Durandal was not “company guaranteed” and Aurelia is.
Aurelia Gitter channel has over 2460 members and over 178.0K messages, making Aurelia the second with most communication feedback ever on gitter, and just in a year. To me, that indicates that 2k people have a sense does Aurelia has trust issues or not, even with the so called transgression of leaving his Durandal community.
@msavin mentioned the crowdfunding issue. Checked it and crow funding was at December 2013, just at the inception of Aurelia and now, not sure if it was before he joined the Angular team or not.
My 2 cents.
Just a dev looking for something stable , standardbased and modern, no matter is it from team A or team B or something “random”.
Just to quickly say: you really shouldn’t call Blaze2 “Inferno”. It’s already the name of another known JS library that does very similar things: https://github.com/trueadm/inferno. In regards to moving forward with React, I think it’s a massive “given”. React has very much redefined front-end development SPAs. Without question, it’s been the biggest revolution in terms of frontend JS design patterns for years.
Also in terms of performance, Aurelia has been shown to be pretty awful in terms of some of the benchmarks out there. My own company also did a spike with Aurelia and found it do be quite a bit slower than Polymer 1.2. This was a big problem as we’re building mobile applications and the difference was very much noticeable on Android (iOS was fine) funny that).
Kudos for pointing it out, @dandv, I like it very much, though prices are rather steep, but in a context of said app and its potential market, it doesn’t really matter
