Interesting facts. So the mass backing and numbers are the key denominator in the trends, no matter the qualitative property. Fair enough
1 Like
Well, we can’t deny the power of economics. It’s even present in marriage. And that doesn’t mean I like it. 
3 Likes
I like the LTS idea, this is definitely what businesses need 
One of the great things of React is that HTML and JS are combined for each component. Trying to separate them again via templates makes no sense to me.
1 Like
I’ve noticed there are some very smart people in this thread. I hope we can channel some of their energy here:
4 Likes
@thomasyajl36 @miro @waldgeist @avalanche1 @Babak @shcherbin @none @Markusxmr @babrahams @massimosgrelli @waldgeist
I’m not sure why everyone in this thread isn’t seeing that something is being done about all these Blaze-related problems right now. You guys just blurting things out without reading what everyone else is writing? Whats the point in that.
…I’m working on making this transition 100% seamless, and it’s looking very good. I’m currently working my way backwards by making React feel more Blaze-like, and then back to completing Sideburns to render Blaze 1.
Here’s the thread you guys should be following:
And the package you should be trying today with React:
you can try the demo app with 3 commands:
git clone https://github.com/ultimatejs/tracker-react-todos-example.git
cd tracker-react-todos-example
meteor```
8 Likes
I guess I’d be less inclined to “blurt things out” if your efforts were officially supported / going to be adopted by the MDG. (Although I see @sashko did like your post!)
2 Likes
yea, well this is how you do it. MDG is very conservative. We gotta show them exactly what we want here. They have integrated plenty of community things into core. Hell, they hired the guy who made the phonegap stuff.
4 Likes
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.
4 Likes
And they hired the Angular guy too!
Ultra mega props to you for your work. I’m elbow deep in stuff right at the moment. I can appreciate all the effort and passion.
I believe your work, and all the Webpack effort too, is the future for Meteor, and in a much bigger way than anything before.
B.
1 Like
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.
2 Likes
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!
1 Like
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.
1 Like
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.
3 Likes
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.
12 Likes
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.
4 Likes
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.
3 Likes
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…
9 Likes
@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.
10 Likes
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.
4 Likes