Next steps on Blaze and the view layer

core
41

Hi Geoff et al,

I’m Tim the author of the package Sideburns/Blaze React. I just want to reflect the reason why I created the package from the beginning. Basically I want to replace Drupal with Meteor some day, using only some packages to get the same features or maybe a set of packages (i.e. SpaceDrop, Universe or Orion). I want to do this because I’m so tired of the way we build CMSs today which I do every day, and they’re ages old now.

But to get there I first realized that in a CMS one has to render and load really quickly, because a regular user to a CMS is different from an app user in that they’re looking for information rather then a function, and doesn’t want to wait for anything to load, they want to access the acclaimed information kept in the page, and nothing more than that.

And to really get to this I realized one needs to render Blaze on the server and maybe incrementally load all its templates. So I started looking for solutions, first by actually rendering blaze on the server together with fast render and a custom package replacing spiderable. At that time I realized how tightly Blaze/spacebars was coupled with the client and to have all templates and code render anywhere I really had many fights to overcome.

Then one day @arunoda created a hacked together sample application, showing us how one could use react and a custom flow router to get fast page loads and server side rendering, it did all the things I needed. And I loved this approach, but I never really have come to love how jsx is written and I always have trouble getting an overview of the actual html output, I don’t even dare to show our designers jsx and that’s when I got the idea of parsing actual blaze templates, because blaze is awesome with the templates.

So starting on that idea, one had to create a plugin that parsed html, js or jsx files, but these extensions was claimed by meteor core packages already so I had to create my own extension which I never really liked. But thankfully with the release of 1.2, it was possible to overcome, except for js files which doesn’t even allow for me to read what’s in them to parse event maps which needs to be added before the transpiling is done.

Some quick things one could really gain with a new template system, and here’s what we should do:

  • templates that can be overriden only by re-implementing them as is.
  • helpers that use this instead of Template.instance or Template.parentData to get access to the instance.
  • event handlers that also use this and now takes the context as first argument and the event as last argument.
  • both events and helpers can also be overridden if re-implemented as is.
  • and let’s stop using the global scope for anything and implement import and export using modules/packages for each file or folder or whatever.

I really like the idea of incrementally loading parts of your app, so let’s get add modules and webpack into core, and have people get used to the fact that they have to include something if they want to use it or override it.

Feel free to fork/use the regex I’ve written in blaze-react, I believe using regex is way faster than any other methods of parsing templates!

And as a final note, I love that you finally have messaged your thoughts to us in the community, I was starting to dislike the whole project due to the lack of personality in your public posts and missing information of your actual stand in these critical maters. And I don’t think the current format of public emails is very well done, compared to when you wrote all of them yourself from a more personal point of view, I miss that, and especially the – in the end. Anyhow, I do love what you’re doing! And I think @joshowens does so as well!

Cheers,
// Tim

39 Likes
42

The fact that “UI (built with Blaze) becomes hard to debug and maintain” is a cause of the API design; if we leave the API exactly the same and just swap the underlying implementation, then we simply cannot make any improvement on the dev experience / maintainability front.

Of course, we will try anything we can to provide a clear migration path for the new solution. Sideburns has already shown that it’s possible to translate Blaze/Spacebars Templates into React Components, so there is a good correspondence between the concepts here, and it’s even possible to make the migration process progressive. It may very well be easier than you think!

Another thing I want to make clear is that the decision of going with React is not made lightly. The hypothesis of “will MDG switch to something else if React is no longer hot” simply doesn’t hold because we did not pick React due to its “hotness”; we picked React because we’ve found it to provide an API that is designed to be more scalable, a much more active ecosystem with many great components/libraries, and a solid, dedicated team at Facebook maintaining it. If anything, Facebook itself runs on React. It’s not going away any time soon when a 300 billion market cap company’s business depends on it.

22 Likes
43

Excited to see this decision being made!

What do you like about Spacebars’ syntax?

Personally, I always liked how quickly and easy it is to split parts of HTML into templates. The ease of connecting small pieces of logic (like #ifs or #eachs) with the data model felt quick, easy and light-weight.

What do you not like about Spacebars’ syntax?

The sub-expressions syntax was very lacking for a long time. Having to create a helper for any trivial or complicated operation felt unnecessary. Also data context was a very confusing concept. Often times templates relied too much on what data context should look like and the templates became less reusable as the shape of the data was defined in how template is using the data context.

What do you like about JSX?

The expressiveness of JS for logic that is more complicated than if/each. Being able to assign variables, iterate over objects, use helper functions from other JS libraries w/o special integration.

What do you not like about JSX?

It is easy to abuse the expressiveness of JS and make the render function look less like a template and more like a JS function with some constants in XML.

19 Likes
44

What is the point of reinventing something, based on React? Why just don’t use React and add easy npm support, so that we will be able to use React packages and also create new ones and share with the world outside Meteor?

8 Likes
45

We are not re-inventing anything. It’s more like an thin interop layer to ease the migration/learning curve to React. It’s going to be optional, you can of course go with raw React if you want. In terms of easy npm and module support - that’s exactly what we are going to do! (@benjamn is on it)

14 Likes
46

Oh no… Your are just trying to kill what Meteor was originally. I know that React is a great tool but please don’t make so radical steps. What I don’t like about React is defining a template in JS code. Sorry but template is a template. Blaze templates provide nice layer of abstraction. Another thing. Using JS code in a template? Ok sometimes it may be handy but one more time template is a template. I would like to see some example of how it would look like. Can you provide any?

Of course Blaze is not perfect and it needs improvements, maybe radical but not as radical :smile:

11 Likes
47

What I don’t like about React is defining a template in JS code. Sorry but template is a template.

A big concept of React is that you’re not building templates. you’re building components. I don’t get why everyone lists a con of React as “HTML in JS”, I don’t see a difference between {{#each}} and using a plain old JS map() to achieve the same result except that it’s using the language we all know already without any special syntax. JS and HTML for components (or templates) go hand in hand, so to me it seems logical to stop trying to consider them separate beasts when they’re so tightly coupled and just work with them together in the same file. Just my 2 cents

16 Likes
48

I just want to make sure it’s not lost in what will probably be a long thread that it’s a Very Good Thing© that MDG developers and leadership are getting more active in the community, particularly the forum. @sashko has blazed a path I hope to see many others follow.

15 Likes
49

@gschmidt
I’m ok with using Angular and even React, I need to learn React.

What I’m looking for, today, in the Meteor ecosystem is stability. Today we’ve a ton of packages that get broken very easily. If we decide to drop we’ve to rethink a lot about the Meteor development experience.

The migration will be slow but it’s possible imo. The right question is: Is the community ready to re-learn stuff for the n-th time? I’m in the process of migrating from iron-router to flow-router and it takes time for such a small change. I love learning new stuff but until I use it production that another long story. Migrating production projects because of React or Angular? Nope

Dropping Blaze makes me wonder if I should even continue with Meteor. So many learning resources and atmosphere packages wasted. If I’m going to use Angular or React maybe… I could simply create a REST API and it makes my life easier. As a Meteor application grows, you need to know a lot to make things work with Meteor. It actually makes my life easier to bring new node developers.

Oh, how about real time updates? Most apps only need a small number of real time components. Simply create a meteor server with a few methods or write your node app, not that hard.

I think we’ve more important problems to solve. So far, personally, I don’t have complains regarding Blaze. Just for the sake of not getting out of topic, I’ll save my thoughts about what could be improved when you start another thread regarding a specific topic or general feedback.

14 Likes
50

If you keep it super simple and logic-less, the syntax is very easy for non-devs/junior devs to pick up. It looks a lot like HTML. This is great!

However, it falls apart quickly when trying to do much more than inserting variables (logicless templating).

Loops and if/else, and other constructs feel like they’re stuck on with bubble gum and duct-tape. They’re just trying to use the existing mustache syntax to add on features.

What do you like about JSX?
What do you not like about JSX?

The bad: JSX has a really bad first impression. I hated it when I first saw it. It looked so weird. And then once Blaze became un-maintainable then React started looking more attractive.

The good: It’s easy easy to reason about when you only have to worry about props coming in (data) or the components own isolated state. No magic.

React brings in a culture for a functional paradigm, modular code, and re-usability. This alone is a plus.

8 Likes
51

Saying template is a template please don’t change it is like saying phone is a phone please dont make it a computer. Template is very last century. We are no longer rendering just pages, we are building APPS. Meteor is a APP platform to build web APPs, not web pages.

The rendered app should be a function of state. View = f(state). And blaze is absolutely painful at doing so.

2 Likes
52

I think a big part of Geoff’s proposal was exactly about fixing that point by introducing a template layer on top of React.

8 Likes
53

I would say, that to have existing API for existing project would be ok, but I think we will be able to automatically use original React API for .js part and ‘blaze2’ template together.

Main points of what I don’t like in React’s render():

  • JSX don’t have if and for, so we’re ending in core such us:
  render () {
      let button;
      if (this.state.isOk) {
          button = <button onClick={this.onclickHandler}>Click Me</button>
      } else {
         button = <button disabled>...</button>
      }
     return (
        <div>
           <h1>Click to vote</h1>
           {button}
        </div>
     )
  }
  • Putting html into js code for small components is ok, but for layouts and stuff it’s really not.
  • If we’re moving html from .jsx into template, why to use that ugly className="" and style={color: 'red', widht: "100px"}, why not to use old good class="" and style="color: red; width: 100px;"?
54

While I agree heavily with @joshowens re: how this impacts selling Meteor as a platform to clients/others, the move to a React-based solution is neat/makes sense (at least, as it’s been explained).

However, if this is the path forward, the one thing that MDG hasn’t done in the past but would need to do extensively with this release is remove the element of surprise. If there will be a future expectation to port apps/packages to Blaze 2 or React outright, the timeline for when and how that will happen needs to be well communicated.

A surprise release—e.g. nobody really knew when 1.2 would drop—with a major switch like that could permanently damage the credibility of MDG/Meteor as a whole.

8 Likes
55

One more think is cool about blaze is that we can have templates without any .js code.

<template name="hello">
  <h1>Hello</h1>
  {{> world}}
</template>
<template name="world">
  <h2>world</h2>
  <p>Super simple!</p>
</template>

In React for su small ‘components’ I would need to write quite a bit js code.

Additionally I would need to change original html (made by designer) and wrap ‘world’ template into additional

. What’s more, sometimes in rendered html we will see additional here and there.
Unfortunately I fill that you’ll not able to avoid that :confused:
3 Likes
56

Whatever will happen… plz make it happen quick. In the sense of ripping of the band-aid. If from this announcement on it will take e.g. 6 months for some magic next step to happen, then (guessing here) a lot of great stuff will come to a complete stop because of uncertainty.

8 Likes
57

I agree with you, utilizing other technology to gain some wins seems smart to me. My worry again comes from living through Spark -> Blaze and the crud left over on atmosphere afterwards. @dandv did an awesome job to try and wrangle in outdated and unsupported packages during that time.

I guess it just feels weird to me that 1.2 came out in September with added front-end options and here we are talking in mid-November about removing Blaze, which was our only official option up until 1.5 months ago.

Fully agreed. Meteor has done a notoriously bad job at communicating this kind of stuff… My hope would be that we get more of these types of announcements and updates as progress moves forward.

16 Likes
58

I’d like to just make two points. Keep in mind that we’ve been waiting for “Blaze 2” for a long time (I remember being excited about this talk from Devshop 3 in April 2013: https://www.youtube.com/watch?v=MUW8kxpze0Y).

On needing to rewrite apps in “Inferno”

We were always going to need to rewrite our apps in Blaze 2, whatever it looked like. It’s of course hard to know how the backwards compatibility story looks in two different (currently hypothetical) worlds, but there was going to have to be changes to the semantics of Blaze templates (which would mean big rewrites) no matter what, IMO.

On React being the “next big thing”, to be replaced next year

It surprises me when people assume that the reason we are doing this is because we are chasing the next big thing. The list of things that need doing yesterday at Meteor is so long, as we all know, that the idea that we would work on a major project just because it is “cool” is preposterous.

We are using React because it just looks so much like the way we all imagine Blaze 2 might be. We’re doing it to save time, not the opposite.

19 Likes
59

I think you misunderstood people when people are saying the the next big thing.

There will always be new and better libraries/frameworks for development the problem is that as @joshowens pointed out blaze was the only officially supported view layer until 1.5 months ago and up until now there has been very little communication from MDG as to what is going to happen with Blaze. Now we are being told, forget Blaze, learn React(or that is how it is coming across). Now I think most of us will accept this if we believe it will help Meteor succeed(which by now we have an interest in happening)

The real issue is that as developers and companies with production apps(or are working on production apps) we do need to see stability in the framework.

It can’t be that every year we are going to be required to do massive rewrites in order to continue using the Meteor framework. Meteor only moved to Blaze in March of last year and now after less than 2 years they are abandoning it… That is not reassuring.

I honestly believe this move is probably for the better, but, we really need communication from MDG as to how this move is going to happen and what we should do now to prepare for it(as in should our new projects be in React).

I guess really what I am trying to say is I just want MDG to pick a view layer framework and stick with it :smile:

8 Likes
60

Overall I think this is a very positive move, but I have to admit this is a good objection. If upgrading from Blaze 1 to Blaze 2 is going to require work anyway, then it makes sense to use React from now on, since we know that at least will always work.

So we’re de facto pushing people towards React, which then makes me question why we need Blaze 2 at all…?

So for me the whole point is to make it very easy to migrate from Blaze 1 to Blaze 2, to the degree where it will still make sense to use Blaze 1 up to Blaze 2’s eventual launch. As long as we keep that in mind I’m very excited for the future!

11 Likes