Those who are already using the React.js, so do not need a Meteor.
The charm of a Meteor that I did not need anything except its documentation. Now I’ll have more to follow all the changes in the React.js, and then in the Meteor.
Meteor looks holistic today. And it will be so that a Meteor will be a small part of React.js webpack, etc. Where is the Meteor?!
2 Likes
Meteor is a framework, it can be just a collection of wonderful libraries. The docs may have all chapters (models, validation, templates, routing, etc) and simply use libraries, used by the whole js community, under the hood.
Webpack can be used as a build tool, React as a view layer, Flow Router as a router, Simple Schema as schema definition, etc.
Meteor can just glue this parts nicely and add additional parts (like mini-mongo, tracker, etc), describing all of this in the docs. This is the best way to evolve today, you can easily switch parts with something else (use Angular/Blaze instead of React for example).
Reinventing all of this parts is slow and MDG has no time and resources for this. That is why we have one DB, outdated view layer, no modules, no incremental loading, restricted build tool, etc. So many “no” just because of reinventing and closed nature.
5 Likes
Personally, I love the sound of this change. Almost everything that was said hit the nail on the head.
I don’t see the point of the MDG maintaining their own unique view-layer when there are so many great, mass-adopted ones already available. If them switching to a “React with extras” approach means they can spend more time making Meteor fantastic and less time worrying about the view-layer, then I’m all for it.
2 Likes
+1 for above post
I think what will be great about this and WebPack/modules is that we won’t have to think much about any of it. And as mentioned, React fits well into Meteor.
I would probably suggest against marketing the React side of it, just kind of leave it there for the pro’s to know about it and push the Meteor way of writing front-ends. Facebook has a lot of ambitious engineers that may want to build a complete platform, and they could become a competitor to Meteor. And as we see in other threads, people are already talking on the lines of “well, I already use React on the front-end, so maybe I’ll swap the back-end for X.” But I think that as long as MDG continues to maintain the platform and Meteor has good deployment options, it will have a big market because it’s very simple and developer friendly.
9 Likes
I believe that by opening Meteor up to other native rendering possibilities (React and Angular) the overall platform has already started to decline in a way that may not have been fully considered.
One of the great things about Meteor is the fantastic range of 3rd part packages available for it. However, maintaining a package that works well across Blaze/React/Angular is very hard and time consuming (I eventually had to rip out the React support from the Avatar package due to a number of technical problems, and I haven’t had time to sort it out yet).
The result is that Atmosphere is already split. Most packages only support Blaze. Some support React. Few support both at once. Where it was once simple and magical to just add a package, it’s now already becoming more difficult. Out of interest I just tried to estimate the work load required to move an in-progress project to React and discovered that I need at least 15 packages that don’t yet have React support.
Since there’s no longer one common native rendering interface I expect package maintenance to drop considerably. Today there are already a number of dead packages (even from ‘big’ players), and this is only going to get worse if they are harder to write or only apply to a fraction of the community.
If Blaze 2 isn’t backwards compatible with Blaze 1 then the situation will be worse again, with a 4 way split across the packages. Or perhaps some packages will stop being updated for Blaze 1, this leaving existing products out on a limb.
As a related point we can also see a similar problem caused by Routers. Routing is an essential feature but it isn’t yet part of the core. As a result we now have two major 3rd party routers, and that’s causing havoc on Atmosphere when trying to find compatible packages. It would be time well spent to put the problem to bed quickly and make routing part of the core so as to stabilise Atmosphere, rather than making a fundamental change (an incompatible Blaze 2) that will split it yet further.
I’m all for improving Blaze, but please consider the full effects of incompatibility and more importantly the effect that it will have on what is arguable Meteor’s strongest asset - the Atmosphere packages. Meteor without great 3rd party packages is a significantly less worthwhile development environment IMHO.
32 Likes
It is better to call React target Blaze another name such as Inferno. Community may organize its own resources to define and develop Blaze in the future and save the investment of community members. MDG has its own agenda. It is hard to have the agreement between MDG and Community in the new Blaze today. So it is good for everybody to fork Blaze in two branches. Both parties can support each other.
I’d rather see @manuel’s Viewmodel integrated into Blaze! Sprinkle a little SSR and there you have it = client and server components out of the box!
10 Likes
Absolutely. Add ViewModel 2 + SSR to core and I’d be a very happy bunny.
6 Likes
Meteor had a great start, but we feel it is loosing its momentum and elegance.
We feel that Meteor is trying to please everyone. Blaze is good enough for many… so why do you insist in confusing us with React, Angular 1,2 and so on?? We spend more time on pulling our hair out to choose Iron or Flow router than on actual coding these days. Help!! Coffeescript or JS? Help!! Why do you spoil Stackoverflow with all these incompatible answers??? We work with Blaze but really feel we are left out with all the hot-shots jumping in every direction…
To regain momentum we would suggest to stay clear and focussed. Make a core choice, framework, router, testing, even icons or styling lib and please… stick to it . Try to become the most easy, fastest choice. The hot shots will not be left behind as they will have easy ways to override the core choice.
The fact that the CEO is so technically advanced worries us a bit. The typical choice of techies is “More more more…” instead of better, faster, easier, safer, more secure. It is a dead end street as you are killing mass-uptake. Sadly as the promise is huge… We love Meteor !!! Dont spoil it please 
23 Likes
I think it’s important to decide what Meteor is.
Is it an ecosystem that removes the friction of making realtime single page apps?
or
Is it an ecosystem where you just assemble legos and one that surrounds you in a cocoon so that you don’t have to look outside into the ‘real world’ of the JavaScript community and perhaps take a weekend to learn something new?
Personally I signed up for less friction to get jobs done. We have Scratch for the latter use case.
- In 2012 we had underscore templates and handlebars. Blaze (Spark) was a better choice then.
- In 2012 updating the DOM was tricky with Backbone/jQuery, Blaze was so much easier.
Now React is just as simple or more simple than Blaze.
However, nearing 2016, we have better options than Blaze. Let’s leverage what exists and make other parts of the stack have less friction. If you want to keep Blaze, great. I get that. One of my apps is staying at Blaze 1.0 too.
***Other parts of the stack need less friction***
- In 2012 we had script tags and Ant/Jake/Grunt, Meteor’s build system was magical then.
Currently it’s sluggish and untenable compared to webpack - In 2012 getting tests to run outside of a Jasmine HTML runner with script tags was hard.
Currently Tinytest and Velocity are subpar and not productive. Far away from Rspec - In 2012 it was hard to get the data you want from a server
Currently subcriptions (and publ) are clunky compared to other options
If you want a stable ecosysem I hear .NET is great. JavaScript is just now growing up and is going to have growing pains.
12 Likes
Ok I’ve got convinced after watching this movie and after thinking about it for a while. It will be able to define a template in the *.jsx file and your component logic in the *.js file then I’m for such approach
Surely choosing React as the “defacto-standard” view layer, is staying clear and focused; focused on making the underlying technologies better, rather than trying to write something that compete’s against the likes of React and Angular, which have the might of Facebook and Google respectively behind them. Why not let them stay focused on making a great view-layer and MDG focused on everything else?
I personally believe that this is why we are seeing the rise of Phoenix, it’s simple, powerful and it does the backend stuff incredibly well, ie. it’s focused on delivering a solid backend. View-layer, it doesn’t care.
3 Likes
thats what people told in 2014 about angular…
8 Likes
But then killing backward compatibility and 90% of the Ecosystem? Who’s time are you saving? Only yours or the existing clients ?
6 Likes
It’s not going to kill 90% of Atmosphere.
If you’re using React today you can use any Blaze package in your app with a simple adapter to render the Blaze template in a React syntax.
Likewise you can take a Blaze 1 app today and render any React components in your Blaze 1 templates.
Swap ‘React’ above with ‘Blaze 2’ and you’ll see that MDGs Blaze 2 facade over React will work out just fine. You’ll just have a slightly different syntax to import Blaze 1 templates.
5 Likes
7 Likes
I would like to start by borrowing some words from “Dan Dascalescu”
“The MEAN stack is just MongoDB, Express, Angular and Node.js bundled together, but there’s nothing seamless about it. You have to do all the wiring-up yourself between MongoDB and Node.js, between Express and Angular, create REST endpoints and consume them etc. - all this just to get a basic web app going”
Check: Comparing Meteor.js and the MEAN stack
http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_stack
Having several view layers, several routers and maybe several database options will result in a package mess that is very hard to maintain. Why not keep things clean and simple? Minimizing the options also means minimizing the frustration and the efforts needed to glue things together! It is okay for a full-stack-framework to be strong opinionated about choosing the technologies that become part of the stack as long as everything plays well together.
Take Mongo & MiniMongo for example… Imagine adding Rethink & MiniRethink, Postgre & MiniPostgre… You are polluting the API and causing a big mess! Either offer a unified ORM layer with adapters for the most popular databases like what Sails did (http://sailsjs.org/features#?database) or stick to Mongo as long as it continues to work well for most cases.
The same applies to Blaze, why don’t you try to improve the Blaze design and maybe borrow some design patterns from React & Angular so that it competes with them? IMO a radically fast changing framework can’t offer a good developer experience.
4 Likes
It’s really hard to address every question in this thread, so I’ll just put down a generic Q&A (opinions are personal, but based on my impression from internal discussions at MDG):
Why are you reinventing the wheel again?
We are not “reinventing” anything. It could be misleading to label this new project as “Blaze 2”, or giving it the name “Inferno” - what we are hoping to build is a thin, optional layer on top of React, with full interoperability with all the components and libraries in the React ecosystem. The primary goal of this project is to lower the barrier of adopting and migrating to React.
Old Blaze code will continue to work, and it should be totally possible for both solutions to co-exist in the same project. My hope is that a user should be able to incrementally migrate an app to the new solution without committing to a complete rewrite.
Why React? Why not something else?
We believe React is currently the strongest view layer solution in the JavaScript ecosystem. The advantages of using React include:
- Robust component model
- Easier to reason about state
- Huge ecosystem of reusable components, libraries, tooling and learning resources.
- Has robust and actively maintained routing solutions, e.g. react-router, flow-router.
- Plays well with modules, Webpack, SSR, incremental loading etc.
- Maintained by dedicated team at Facebook, and used in production by many serious businesses.
- Opens up the possibility of leveraging ReactNative
- React core is focused on the view layer and does not impose too much architectural decisions on the user, therefore making it a better fit for integration than more opinionated frameworks like Angular.
My personal opinion is that focusing on how “fast and easy to get started” is somewhat shortsighted when picking a view layer. Our end goal is to enable Meteor users to build large applications that are scalable and maintainable, and we’ve found that:
- Blaze in its current form doesn’t serve that goal well, and it will not improve if we maintain 100% backwards compatibility.
- React checks a lot of boxes in terms of what we want to see in a “better Blaze”;
- The amount of effort and resources required to maintain a competing solution with feature parity and the same level of mindshare is huge (think ~20 full time engineers) and may not be the best strategy for MDG.
- But there are things we want to keep in Blaze. React can be hard to jump into. Hence this “template for React” project.
Note that it would require non-trivial refactoring effort even if you are migrating to a Blaze-based solution, as long as it demands a different API (e.g. Blaze Components or ViewModel). We think it’s better off in the long run if that effort be spent on migrating to a React-based solution instead.
What we are asking for is the community’s trust that MDG is making this decision by placing the users’ long-term interest first.
But I hate JSX!
The exact purpose of this “template on React” project is so that you will not be forced to use JSX when using React. It also doesn’t prevent you from dropping down to JSX if it ever becomes necessary.
You should leave Blaze alone and solve other problems first.
This is the first step we are taking in terms of re-aligning Meteor with the bigger JavaScript ecosystem. We are well aware of the other possible improvements such as better NPM integration, ES6 modules, easier way to leverage external build tools such as Webpack… etc. @benjamn is already working on that front.
As mentioned above, this view layer project is intentionally limited in scope so that we have bandwidth to tackle other problems at the same time.
I don’t trust Facebook.
The problematic patent clause has been removed, and that, in my opinion, in fact shows that Facebook is well-intentioned and committed to its open source efforts. I also don’t think the impression with developing for its app platform has strong correlation with the quality of its open source projects. It’s more reasonable to judge after you’ve actually tried the technology in question.
This will hurt Meteor’s package ecosystem.
A unified view layer does have its benefits. However, I’d argue that by adopting React you in fact get to leverage a much more active ecosystem in terms of view layer components. Easier NPM integration will also help out in this aspect.
I admit that if you are relying on packages that are tightly-coupled to Blaze, it would indeed be a painful process. That is why I hope we can come up with an incremental migration strategy that doesn’t force you to fix everything at once.
33 Likes
This will be a good development provided that clear migration guidelines are published. I have a lot riding on blaze at the moment and wouldn’t like to blindly tinker with such a large move. Time to write a transpiler?? Blaze2react ??!
And Angular would still be one of the two officially supported view-layers… Your point being?
Keep in mind you can use whatever the hell view layer you like as it currently stands, it’s just that you lose the reactivity, which I admit is a huge drawback. But conversely it’s a hell of a lot simpler to add a Meteor reactivity layer to an existing view-layer than it is create an entire view-layer from scratch, maintain it, add the latest and greatest concepts, etc.