I completely agree with you. There are thousands of packages which are equally important like the core. It’s unfair to make this community packages deprecated. MDG should think wisely about the backward compatibility. And I think porting overhead is too costly. My personal opinion is that we should embrace the new technology keeping in mind with the backward compatibility as there are quite a few production apps.
5 Likes
I was just getting into package maintenance; but still had to deal with upgrading a dozen apps. Some got taken care of right away; but others took upwards of 6 months to finally upgrade. If there’s not an easy migration path, apps won’t get upgraded, and will just sit as abandonware.
Although, to MDG’s credit, I remember there being clear messages in the console logs that the rendered() and created() helpers were being deprecated for onRendered() and onCreated(), and various other messages that guided people through syntax changes. That was the best part of the 0.8 upgrade, as I recall. (or was it the 0.9 upgrade?).
1 Like
Love this.
Agree with @joshowens and @awatson1978 that focus should be on upgrade path. Inferno as a drop-in replacement for Blaze would be mind-blowing. If that’s impossible, a minimal upgrade path for people who want to port existing templates to Inferno, and allow Blaze and Inferno to coexist somehow like you’ve done with Blaze/React in 1.2.
Really excited about this thread and overjoyed to see @evanyou putting his considerable talents into it. Blaze is a sensitive topic and you’ll never be able to satisfy everybody, but you’ll make a whole lot of people happy when you deliver.
5 Likes
Spot on as far as I’m concerned. Having meteor packages with React compatible views will be awesome. The React community itself is also enormous and for meteor devs to be able to leverage their components out of the box should outweigh the annoyance of upgrading current packages in the long run.
Also I haven’t heard of any developer with long term experience of React who would worry about it’s maintainability since it’s predictability and maintainability are it’s key features and design goals. Having used Embers and Meteors view layers a lot React seemed weird to me at first but now after almost a year of using it I would neither want not dare to use any other thing for big scale, high fidelity UI stuff.
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
thisinstead of Template.instance or Template.parentData to get access to the instance. - event handlers that also use
thisand 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
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
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
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
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
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 
11 Likes
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
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
@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
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
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
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
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=""andstyle={color: 'red', widht: "100px"}, why not to use old goodclass=""andstyle="color: red; width: 100px;"?
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
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
Unfortunately I fill that you’ll not able to avoid that
3 Likes
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