This is a great discussion. Thanks everyone for their POV. The future of Blaze is something i’ve been eager to learn more about for a while now. My startup is one that hasn’t adopted React. We value finalising our MVP over changing technology. So we are sitting on the fence, waiting to see what the MDG has planned for the future 
3 Likes
I think the package system stats are better indicators then a poll.
1 Like
Do you even hear yourself? The polls now, jesus, really?
Use Blaze, without React you would not even bother to start this topics and will wait for small fixes in Blaze. Blaze is working well for most of the people, if you like it - use it.
The Blaze Components. Sure, learn another huge package docs, instead of React docs, refactor your app and use it till @mitar will drop support. Did the Iron Router story teach you anything?
By starting using React now, you will be safe for the future. You can even change the Meteor backend later with something else. The huge apps like Facebook, Instagram, Airbnb, etc are using React, you really believe it will die in a year? All this companies are using it because of hype?
Sure! Tell us more about it! Or maybe another topic?
4 Likes
Why I moved to Meteor 3 years ago? Because it was damn easy and simple to create SPA with very few lines of code. And at least half of the community people I see during meeting are here for that promise.
What I see since one year? Some people push Meteor out of this tagline, no session (global is bad), no blaze (no component is bad), no mongodb (nosql is bad), no ironrouter (reactivity everywhere is bad), insecure/autopublish (because you know why) and so on.
Meteor was made to easily create app, now Meteor wants to be the best companion for making big clean apps.
So people looking for the first message are more and more disapointed by the new Meteor release.
I sometime need to develop fast and ugly prototype/mvp and I want to be able to do it with Meteor quickly and easily. Sometimes I need to develop strong, robust and extensible app, and I also want to be able to do it with Meteor.
And Meteor should be crystal clear about that and explain what to do/use in which case and strongly develop features for both solutions:
- you want to do a mvp/small app? -> session, iron router, blaze, insecure, autopublish
- you want to do a big/solid app? -> flow router, react, …
Please MDG, support those 2 cases, do blaze2 for entrepreneur who need to build quickly app and support react for the developer working on big apps.
10 Likes
and how many of these React installs was just to write JS with ES6 as .jsx …
5 Likes
While I do see your points of wanting to clearly split things up this doesn’t really help people figure out what to choose. I think the whole promise of quickly prototyping with Blaze is obsolete by now. Yes, it is true you can grab Meteor, read some docs tutorials and build a prototype over the weekend. However, there are a few problems with that:
- This is targetted towards people wanting to build prototypes - startups. Here’s the sad reality: 99% of all startups that do their fancy prototypes at a hackathon or startup event will abandon their project just weeks or days after those kinds of events.
- You can learn Blaze, React, Polymer, Angular (granted, it’s a bit complicated imo) in a weekend like Blaze. But in my opinion your code and productivity is going to be far better with any other option than Blaze in most cases.
- Since it is so easy to pick up those frameworks I don’t see any point in going for Blaze anymore, especially for the 1% of startups that actually continue with their shiny prototype they’ve built. Let’s face it, if you’ve built something with Blaze and you want to grow your app, you’re in trouble. Especially because it’s hard to figure out best practices how to keep your code clean. Coding with blaze is a mindfuck once you go beyond a few components. Keeping things organized is just so difficult. People will say there are packages here and there to make things easier. That’s true but is this really how a opinionated framework should be like? Out of the box your solution is shitty and packages are supposed to ducktape everything together?
Another point I want to make though is rather the decision they’re making to go for the hyped framework React right now. I get why they are doing this but I think it’s a big, big, big mistake. Don’t get me wrong, React works, there are great concepts in there but there are things I really dislike. I’ve said this at a talk I gave a week ago about Polymer/webcomponents: React ultimately is bad for the web. There’s so many frameworks. Here we are, all discussing about why our beloved framework/feature X (Blaze) should continue to be maintained and why we shouldn’t go for framework Y (React), etc.
So what I said during the talk is this: “The web is the framework”.
Stop investing so much in frameworks that will go away. Finally begin to embrace the web, make the web your framework. If MDG would invest more in webcomponents we would be rid of the framework war in a few years from now. That’s why I’m glad they’re implementing Angular which is using webcomponents in 2.0. But React/Facebook on the other hand is just clearly trying to kill the web instead of improving it for obvious reasons. It’s a solution for short term to have something that works right now, that’s supposed to get everyone away from the browser in the long term.
About the web being the framework: I’ve never watched this video completely because I realized it summed up pretty much what I was thinking already but it’s a good watch why we should stop investing so much in frameworks. It is really ironic when you watch talks like “Javascript: State of the Union” and then you see the MDG push for a framework that is trying to remove web technologies from the developer experience.
If we would embrace webcomponents, in 2 years from now frameworks would be nearly dead, or rather they’d be reduced to the things that really make them unique. Meteor and MDG could focus on what makes Meteor unique, not worry about doing different implementations for different frameworks. We’d have true framework interopability. We wouldn’t have to cry about Blaze being obsolete or not maintained. We wouldn’t cry about not wanting to learn React. We wouldn’t cry about React probably being replaced in 5 years from now. We’d just write our components in the framework called the web, webcomponents, a component system that would work in every framework and everyone would be happy.
I wish we would stop joining framework camps and just embrace, push and write webcomponents, drop them in any platform or framework and be done with it already.
4 Likes
I’m joining the battle a little late but I wanted to contribute. I’m a bit torn on this issue, because on one hand I’m very tied to Blaze through Telescope and Discover Meteor, but on the other hand I can see that React has more momentum, a bigger community, and smart people (like @arunoda) swearing by it.
So part of me wish I could jump in my Delorean, time-travel a couple years back and tell the core team to just use React from the start…
But since we’re here now, I think a couple things are clear:
- It would require a lot of effort from MDG to bring Blaze to React’s level in terms of community, momentum, features, etc. Although I personally would be happy to help the effort however I can, I can understand why it wouldn’t be a good strategic choice.
- The community is understandably unhappy about the lack of support for Blaze. I personally spent hundred of hours writing Blaze code and it sucks to think that this code might soon be obsolete.
So this brings us to what I think is the least worst option: continue to provide limited support for Blaze while working out a way to smoothly transition into React.
So I quite like the idea of using Blaze as a “front-end” for React, maybe using something like Sideburns. Keep the simplicity of Blaze, but with the robustness of React behind the scenes. This way we get the best of both worlds!
But I do think MDG needs to be part of that process, and not leave it up to the community. As this thread illustrates, we badly need someone to lead the way…
20 Likes
Template systems are for websites. Components are for apps, what is meteor going to be for?
I totally agree. That’s why I’m using Blaze Components.
Dido! A component system on top of Blaze covers the whole ground whereas React alone is very unfamiliar to UI designers whom I consult with for the barebones UI of my apps.
But again, I think the essence of this thread is not Blaze vs React. I can decide later on if I can live with whatever choices I am left with, but for that to happen, I need to know that I have choices and whatever I choose now is going to be supported, maintained and improved upon for at least a couple of years. So this is all about MDG saying, “hey we heard you and we are going to go at least with X and Y for at least N years and both X and Y will see improvements along the lines of such and such”
So I guess this all relates to that other thread about MDG’s transparency and involvement with the community.
6 Likes
Meteor was made to easily create app, now Meteor wants to be the best companion for making big clean apps.
A very similar thing happened few years ago with the Play Framework. It was a damn easy Java framework to create full featured apps, apis and sites and all of a sudden they decided to go with full on Scala to be the best to create those apps. Prior to that move its adoption was massive and right after that move it has fallen down the cracks to become one of the many JVM based development frameworks, definitely quite good in many areas, but definitely not among the top contenders for ease of adoption.
Anyway, there are lots of stories like that. What’s important is to hear from the narrator - MDG - some teasers and spoilers so that we have an idea if we want to keep up an on with the story.
3 Likes
You did however prove something… Something at the very core of the MDG’s decisions.
Your comedy poll had a sum total of 164 votes. Meteor wants to tap into the React and Angular crowd. If they succeed, your poll will clock in at 1640 votes… or 16,400 votes. MDG have investors who don’t see any value in spending hundreds of thousands of dollars a year trying keep Blaze up with the myriad of competing templating engines.
The low skilled people in lumberjack costumes can still be consulted with. The photoshop documents they produce are built upon layers, which often directly equate to an isolated React component.
I keep seeing this argument repeated. I’m not sure why. Nobody should care about radically less code but radically less worthless boilerplate.
Marketing bullet points in order of appearance.
- Isomorphic development.
- Mobile and Web
- Reactive rendering
- Metrics
- Easy deployment
- Automatic upgrades
- Radically Less Code
- Optimistic UI
- Full stack solution
Back in the 90’s 4GL’s were the rage and on the cover of every magazine. No longer would companies need to pay big bucks for RPG/III and COBOL programmers. Managers could now write applications using expressive language.
The only 4GL used anymore is SQL. Ironically, people consider it hard.
Internet importance is about a valid argument as an internet poll.
He’s just some guy who has over 1000 less twitter followers than I do. That’s after losing half of my twitter followers being that my last tweet was sent in 2012 when I got bored with it and forgot my password. True story.
Well, React itself is no miracle.
It is encapsulated, but same can be said about template level reactive variables for example.
I think what is making React so popular is enforcing these things while in Blaze they are presented as still in work best practices - but not part of MDG tutorial or so.
For me it is no problem to make dumb templates and use that template level vars and data flow to pass it to child templates, as described in https://www.discovermeteor.com/blog/meteor-components-template-controller-pattern/
I dont need React’s - re-render all for every change approach - especially the MDG mixin implementation which is impossible to controll by user.
Blaze is nicely tracking what has changed and touch only related templates - at least it looked that way for me (iron-router school kinda shown people how to approach reactive variables and limit their re-runs 
).
If it is touching something more, than I would probably try Blaze+, but for now all is working for me.
1 nice template level controller, with few autoruns waiting for subscriptions and when related subs are ready rendering dumb templates. While passing them data and controll functions from helpers. That way you can keep STATE in 1 place and pass data and functions to dumb child components.
Now with “#each item in array” you can access all template level data without parent touching hacks, what more we need ?
Yes React is nice for native Android and iOS stuff, but I dont see anything limiting us as long as we dont need native feel animations on all platforms.
If you want to learn React, you need to also learn some kind of Flux or Redux etc. when you really wanna work with Meteor, as with basic re-render all approach you will hit wall kinda fast. So than Redux, immutable and even in React world there is 100x implementations. And show me article explaining exact patterns how you need to pass Immutable to child components so you can track if component should re-render. When I last time checked you need to pass props and immutable version of them too - so keep both structures at the same time etc.
So short version - React is not 1 weekend lesson if you want to learn it on usable level with the right practices. Nor is Blaze. But both have pros and cons. And both can be used in component reusable way.
6 Likes
Why are you not using PHP then? Would you recommend someone who’s getting into developing web apps to use PHP? Just because something is “alive” doesn’t mean it is the way forward.
For every thing there’s a proper tool and for a lot of websites PHP or Rails will still be a better solution than Meteor. Or do you suggest people shouldn’t make simple websites anymore and only develop webapps?
Also, you are completely missing the point i am trying to argue here. I never said blaze is going to “die”. Nor should it. My argument is against the OP, that Blaze just shouldn’t be the focus of MDG
Well, there are few other people talking in this thread, some of them have different point than you, I simply addressed them too.
Still, if Meteor stops working on front-end solution and just tell people to use React, Angular or whatever, it’s not what I call a full stack framework anymore. So we would need that to be clarified. What exactly Meteor is going to be from now on?
2 Likes
I think Blaze is an awesome templating language for doing simple apps. I think it’s also important to remember what the landscape was like when it was created. Backbone and Ember templates were the contenders in the wild west of clientside JS apps.
However Blaze doesn’t steer you into the pit of success. The communities obsession with code golf leads us to bad patterns like making database calls in event handlers and not separating view logic from business logic.
Handling state is it’s achilles heel and if you’ve never felt the pain you’re either a great engineer or haven’t used Blaze long enough (by iterating and changing the app over time).
IMHO, if anything MDG does a disservice by providing example apps with the most terse code and 1 file (if client/server) apps. Frameworks like Laravel, Rails, and Phoenix all have great example apps that won’t crumble with numerous iterations.
React is not a panacea… some frameworks like Om and Elm are better IMHO but React has a great community focused on building maintainable quality apps and mostly has great modules.
Don’t get me wrong… if I needed a prototype or hackaton app using Blaze and a myriad of coupled, un-maintained Meteor packages can build an app very very fast. Faster than React or any other framework.
Still, maintaining software is the hard part… creating it is a small fraction of the effort
12 Likes
There has already been a Blaze debugger way before Meteor Toys pretty much put it into its toy kit. It’s babrahams:temple. Use it with constellation:console and it’s awesome.
4 Likes
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.
7 Likes
Have been evaluating various front-ends for the past few months and gotta say, I’m really liking:
- Polymer web-components style
- React server-side rendering
- React native
- Blaze API
so, this idea & name sounds really damn cool 
For now though I’m liking the simplicity of Blaze API too much to maybe switch completely so will likely use Blaze || sideburns.
+1 Official statement on the state of Blaze would be great.
7 Likes
The complementarity of React and Web Components
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.
3 Likes
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!”
1 Like
SIGTERM, as in terminate?! I dunno if that relationship would go any further after that. 
2 Likes