Where I think Meteor is doing wrong with Blaze

core
62

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

  1. Isomorphic development.
  2. Mobile and Web
  3. Reactive rendering
  4. Metrics
  5. Easy deployment
  6. Automatic upgrades
  7. Radically Less Code
  8. Optimistic UI
  9. 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.

63

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 :smiley: ).

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
64

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
65

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
66

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
67

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
68

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 :smile:

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
69

The complementarity of React and Web Components

70

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
71

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 :smile: I wish I were to find a girlfriend to whom I could say “I’ll sigterm you!” :smile:

1 Like
72

SIGTERM, as in terminate?! I dunno if that relationship would go any further after that. :wink:

2 Likes
73

Well it is a relationship, no? Some days you want to sigterm, on others you encapsulate :wink:

2 Likes
74

I doubt sigterm would be enough in her case. :wink: 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. :stuck_out_tongue: But it’s an off topic, so I’ll end it here. :slight_smile:

Sorry once again.

1 Like
75

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.

1 Like
76

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.

77

For this kind of stuff you might be interested in the private package server I’ve been working on: https://github.com/sebakerckhof/stratosphere

1 Like
78

For this kind of stuff you might be interested in the private package server I’ve been working on: https://github.com/sebakerckhof/stratosphere

Whoa! This deserves its own thread, don’t you think? It sounds really exciting!

3 Likes
79

I understand that people are invested in Blaze, but here’s a reality check:
https://www.meteor.com/people
and
https://angular.io/about/

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.

8 Likes
80

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.

4 Likes
81

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.

9 Likes