To answer Evan’s questions: Spacebars are simple and intuitive, and its dead easy to work with them, especially with Tracker-based stuff and the easy helper’s syntax. With JSX, I think the points against it you drew out in your Vue comparisons are spot on ("[it] ends up looking more like a piece of program (which in fact it is) rather than a visual representation of the interface"). With Blaze 2, I think what many of us hope to gain is incremental loading and SSR.
I think a 100% foolproof way to go would be to start using React now. The “Blaze 2” thing is mostly for people who don’t want to deal with the details of React and its JSX syntax, but if it works for you then I’d say that’s the way to go.
I really think Meteor is all about the front-end experience. The build tool and the back-end kind of disappear. I find myself building front-ends first and then thinking back on how I want to wire the data to them. And with autopublish functionality, that just gets reinforced. If you guys need any feedback along the way, I’ll be the harshest critic
+1 for @serkandurusoy, and its not even HTML but “XML-like Syntax”
Some of us written apps in Blaze and they are pretty good with that. They wanna use cool features like SSR and so on without re-writing their templates.
Some of us like to use html templates. For an example, I had a chat with @sacha and one of the main reason he(Telescope) can’t jump into React is the lack of theming support in JSX. (Basically, he want to allow people with good HTML/CSS skills to theme Telescope rather asking them to learn JSX and React)
Some of us want more power to spacebars. That’s where BlazeComponents camp exists for.
Others are just afraid of JSX at first(like me) and after they get familiarized with JSX, stick with it.
I am not sure a client that has spent over $30k on building an app with Blaze feels like shifting to react is 100% ‘foolproof’ for their business. Trusting MDG and building with Blaze in the first place felt like the right move as an early adopter. Honestly, this is kind of a crappy move imo, @gschmidt. How many packages in Atmosphere rely on Blaze? Can we just flag all those as outdated when this new Blaze 2 comes out with a complete lack of backward compatibility?
I really appreciate MDG opening up about it’s plans, but it just feels very short-sighted for the community and like a lot of projects may be left in a lurch and will find it easier to just leave the Meteor ecosystem all together. I certainly have put my reputation on the line every day by selling Meteor and this feels like I bet wrong.
+1 to blaze templates on top of react, like the Sideburns project. Templating allows traditional separation of responsibility between html/css and javascript coding. Also lack of if/else driving me crazy!
If we’re ditching Blaze 1 and Evan You is on the project, can we not just use Vue.js instead altogether? I’ve had great success with Vue, Vue-Router, Vue-Meteor-Data, Webpack and Meteor and it’s much easier to learn compared to React.
This is absolutely the right direction and decision. MDG simply doesn’t have the resources to maintain the entire UX experience with raw libraries for everything. Take what makes Meteor magical (focus on dev ux) which includes reactivity and use the best tools out there to accommodate that. Meteor had to invent Blaze + Packages because it wasn’t available when Meteor started (in a good shape). Now there’s things to rely on without needing to focus it as a core asset (React + Webpack). Integrating those tools tightly into Meteor and shaping it so it’s extremely easy to use is a huge win.
Great decision, do it. So stoked.
We have a massive app, and I’m looking forward to rewriting the views in Blaze 2.0 It will be faster, and more composable. Winning. We have over 350 template files.
First of all I really appreciate the fact that MDG are asking the community about their views.
With that said, I think Meteor developers have been very patient and understanding of breaking changes to Meteor as it is growing and being developed and one of the reasons they have been so understanding was the speed the simplicity of blaze and the speed it let people code(which I hope will not change).
I think the big fear shared by most Meteor developers is a feeling of lack of stability.
Today React is big, but what will be big tomorrow? Is MDG going to decide to move to the next “big thing” the second it comes out causing 1000s of lines of legacy code to be obsolete? These are all questions that need to be answered. Meteor was built on the premises that I can run the same code in both the server and back end with little to no separation(depending on security considerations).
With the introduction of react is MDG moving away from this principal and if so what is going to be the main driver for me to use Meteor over things like the MEAN stack.
In all honestly, right now my big fear is what will happen to all of our legacy code and how easy it is to upgrade it. The next obvious question is should we be coding in react or blaze if we were to start a new project today.
Other than that all we can really ask for is lots of updates on the way and to write some really good tutorials on how to upgrade our legacy code.
Hi Geoff; Hi Evan,
Thank you for weighing in on this topic. I just wrote a page of text replying to Evan’s questions; and as I was sorting through my thoughts, I came to a conclusion similar to Josh Owen’s recent post… this is fundamentally about backwards compatibility and a migration and maintenance issue.
The question shouldn’t be ones of ‘what do we like/dislike about Spacebars/JSX’. That’s really missing the point. The questions should be:
What are the migration and refactor paths from Blaze to Blaze 2?
What utilities do we use to move to Blaze 2 (i.e. and therefore to React)?
What upgrade utilities were missed during the Meteor 1.2 release?
What packages/utilities can be created to coherently integrate or migrate apps from Blaze to React?
Is Blaze 2 going to be API compatible with Blaze 1?
If not, what happened to the '1.0 release` and long-term stable APIs that were talked about pre-0.9?
The reason that many of us are clamoring about Sideburns/Blaze-React as a workable solution, is that it offers a super clear migration path for all the existing Blaze applications in production. The refactor path is basically this: add the timbrandin:blaze-react package; replace .html file extensions with .html.jsx file extensions; et voila; your app is running on React. That’s what existing Blaze users need to get all of our projects migrated over to React.
Seriously, don’t change the existing API if possible. Not right now. The API isn’t perfect, but that doesn’t matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it’s feature compatible. It’s a classic refactor. It’s not as fun and glamorous as producing new functionality or stomping out bugs; but it’s the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.
Best,
Abigail
ps. Serkan concisely summarized my previous page of text with his simple breakdown… it’s all about the HTML. As fancy as JSX is, it’s simply not HTML.
pps. I vote for Inferno as the name of the project. Spark > Blaze > Inferno.
ppps. MDG is doing a great job of managing the front of the change curve; but as a startup hasn’t had to deal with managing the back of the change curve.
So, basically, you just officially said, that all apps with Blaze will need to be rewritten to Blaze 2, which will come no one knows when. All packages, using Blaze, need to be rewritten too. I don’t even try to think, what Atmosphere will soon look like. This reminds me the sad Angular story.
Seriously, don’t change the existing API if possible. Not right now. The API isn’t perfect, but that doesn’t matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it’s feature compatible. It’s a classic refactor. It’s not as fun and glamorous as producing new functionality or stomping out bugs; but it’s the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.
Meteor moved in 1.2 to provide more optional packages allowing us to tailor our projects. I got the impression there that you were trying to be a less opinionated framework.
If you’re building Blaze ontop of React then you force us to use React so blaze basically becomes React. There’s no point using Blaze as you’ll presumably lose something with whatever is placed ontop of React. API/Implementation wise.
As other users have said they don’t want to use React. They want to use Vue/Polymer/Raw HTML/Backbone/Angular/Web Components/Whatever 2016 brings.
Whatever you do, don’t force us into React through lack of other available options.
It’s kind of a concerning topic. Please be careful.
I think a lot of people on this thread weren’t around when the Spark to Blaze migration happened, but as a package maintainer it was not fun. And as an app builder, we spent a ton of time waiting or helping upgrade a bunch of packages for 0.8 release. It took us 2 days to convert 1 small project, back then, once all the package issues were straightened out.
I’m not saying let’s stop forward progress, but let’s make sure we aren’t tossing out a bunch of work a ton of people have built because the ‘UI is hard to debug and maintain’. If we go down the path of adopting Webpack but then it becomes hard to debug and maintain, will we toss that out later?
100% agree and I’m in the same boat, I feel this might be a big problem with my clients. @gschmidt I also think this is the second time MDG is losing sight with the community the first time was with Galaxy which was back tracked into lower plans and now this at the same time would be really nice if we can get routing and project structure in core. Front end is working really great with 3 amazing options.
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.
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?).
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.
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.
I’ve had great success with Vue, Vue-Router, Vue-Meteor-Data, Webpack and Meteor and it’s much easier to learn compared to React.