Where I think Meteor is doing wrong with Blaze

awatson1978 · October 24, 2015, 11:05pm

Sometimes it’s not about initiative. Sometimes it’s about markets and existing contracts. MDG spent two years developing and promoting a framework that supports coffeescript, less, SCSS, stylus, jade, and other transpiled languages. Some of us have business pipelines that involve these languages, whether we want to use React or not. Teams and company policies that have agreed on higher-level abstracted languages; where not every team member is a React expert.

But these are considerations from, you know… established IT houses and enterprises. Folks with funding, and career professionals. Folks who are dealing with real-world constraints beyond individual developer preference.

Obviously not.

Agreed. And for those of us who got onto the Meteor bandwagon in 0.4 and 0.5 days, we came for the full-stack integration, not the UI layer. And for those of us who came to Meteor for the integration, we’ve had to deal with two years of breaking upgrades, and promises that we’d have a stable version after 1.0. Some of us are all for these new developments with React and ES2015. We simply don’t want them in our production apps… yet.

So now that v1.1 and v1.2 are out, where is the follow-through on the assurances made pre-0.9? We were told ‘just wait till 1.0 and the new dependency management system; with it, we’ll be able to revision packages, and you can go into production by pegging stable releases.’ So, okay. Here we are with 1.2. These latest changes are too much for some of our existing apps. Where is the stability that was promised with the 1.0 milestone? How do we get off the bleeding-edge bandwagon? Where is the stable release that was promised pre-1.0? Is MDG going to provide it? Or do we have to create it ourselves? If they’re overburdened, and we have to do it ourselves, are we going to be undermined by changes to the package management infrastructure?

Agreed. Hence the question about the Sideburns bridge. It’s the bridge that connects Blaze and React, and is the single best upgrade option for existing Blaze apps. We want React… but only after Sideburns is fully baked (and integrated with BlazeComponents). Until then, some of us would like to respectfully defer this upgrade, and wait until things are more fully baked. Which is why we’re asking about stable releases and release tracks.

Dan · October 25, 2015, 1:28am

I’ve been a little disappointed with the Meteor news and updates since 1.0. Meteor’s tagline on github is “an ultra-simple environment for building modern web applications”. Does supporting every templating language under the sun fit into that? Does Cordova fit into that? Maybe it does but shouldn’t things that are missing or not complete come first? Where is server side rendering? Rate limiting was just released but all the news was about ES5 and React. Rate limiting and server side rendering are required features where as ES5/Cordova are nice to haves. Keep Meteor opinionated and simple with well-made complete features, don’t try to cater to every developer in the world.

aganapa · October 25, 2015, 2:41am

What is the guarantee that we will not be having a similar discussion about the “future of React” 2 or 3 years down the road? What happened to iron router? There is always going to be “yet another framework” and what is the typical life span of those frameworks/packages. For any business of enterprise to bet on a new technology, there has to be some kind of ‘trust’ or assurance that the tech stack will survive the test of times and be around long enough to build a business around it. No wonder both Java & .NET are still going strong even after couple of decades of existence. What @mitar and few others here are talking about is the ‘trust’ and long term commitment behind a technology so that one can bet their farm on it, and I agree with them 100%.

Very interesting and important topic.

BTW… I just joined this forum few minutes ago and this this my very first post. Apologies if I missed to follow any forum rules or etiquette.

sikanx · October 25, 2015, 3:01am

One of the biggest meteor production app is rewriting their frontend in react

Not talking about Airbnb, Codeacademy, Imgur, Netflix, Periscope, Instagram, Twitter-fabric, Uber all have been using production for over a year.

You really think all these huge startup/companies will re-write an entire frontend in a different framework if they are not sure about the “future” ? You really believe this is all just hype?

Meteor wants to be “The JavaScript App Platform” that rules it all. You really think blaze is gonna cut it?

Template systems are for websites. Components are for apps, what is meteor going to be for? Highly reactive and realtime apps or websites? If the answer is apps then the react is the perfect answer here.

Now i dont agree MDG should ditch blaze or anything, it should be maintained. But compare to the work they should be doing to improve DDP, database integration, it should definitely NOT putting a load of resource for it.

It reminded me of when apple used developed their own processors for all their macs, until they realize they can never have enough man power to catch up with intel because they are dedicated to improve processors. So they adopted intel processors in their macs.

It is very much the same situation here, react is leaps ahead of everything else and there is a huge dedicated community and a lot of resources being put into it.

Even if facebook went under it will still be open sourced and actively maintained. It is framework agnostic so you can use any backend for it.

On the other hand, blaze is tied to meteor only. You are actually risking way more here in the future if meteor go under. You are left with nothing have to literally rewrite your app from start.

brajt · October 25, 2015, 3:39am

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.

You really think all these huge startup/companies will re-write an entire frontend in a different framework if they are not sure about the “future” ? You really believe this is all just hype?

Well, they don’t have to believe it’s the only possible way that everyone should follow, like it is with plenty of React apostles I see around the web. So far I haven’t seen anybody from Uber writing “all people should drop their frontend framework of choice because React is the new pink”. It makes me sad to see it written here on forums.

React community reminds me of Ruby for Rails enthusiasts, who were screaming for years that Ruby will be the end of PHP. Guess what? PHP is still there and isn’t going anywhere.

sikanx · October 25, 2015, 4:18am

React community reminds me of Ruby for Rails enthusiasts, who were screaming for years that Ruby will be the end of PHP. Guess what? PHP is still there and isn’t going anywhere.

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.

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 because react is literally superior to blaze on everything if you need to build reactive modern day app that requires a lot of effort in managing states and components.

dcworldwide · October 25, 2015, 4:18am

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

dcworldwide · October 25, 2015, 4:50am

I think the package system stats are better indicators then a poll.

shcherbin · October 25, 2015, 5:02am

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?

acemtp · October 25, 2015, 8:59am

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.

shock · October 25, 2015, 9:23am

and how many of these React installs was just to write JS with ES6 as .jsx …

AndreasGalster · October 25, 2015, 9:57am

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.

sacha · October 25, 2015, 10:23am

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…

serkandurusoy · October 25, 2015, 12:51pm

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.

serkandurusoy · October 25, 2015, 12:58pm

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.

jacobin · October 25, 2015, 2:41pm

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.

Why Meteor

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.

shock · October 25, 2015, 3:27pm

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.

brajt · October 25, 2015, 5:42pm

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?

SkinnyGeek1010 · October 25, 2015, 6:23pm

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

lai · October 25, 2015, 7:34pm

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.