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.
As per @SkinnyGeek1010’s comment, this is complete nonsense. You can add any blaze component into React with about 10 lines of code. It’s this “scare-mongering” nonsense thats being thrown around that’s making people make snap decisions.
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?
I think Meteor was “sold” more like the latter, really. Remember what they used to call “Meteor Platform” and “Meteor Distribution”? It went along the lines of “a set of packages tested and designed to work well together…”. The distribution included both the back end and the view layer. React and Angular were not even part of it. So I don’t think many people can say they came to Meteor because of it being open to all the JS world. I think it was the opposite. I knew what I signed up for when I started putting time and resources to learn Meteor.
I know a lot of people have a negative connotation about Meteor being closed and not being in the “real world” Javascript. We envy the world, the world doesn’t envy what we have. Maybe they’re right.
1 Like
I am very unhappy with this move. Though I can understand that React has reached a momentum that Blaze might not be able to achieve, I’m getting more and more the impression that investing in Meteor in effect means that you have to completely re-write your apps once a year (or so) – which is completely counterproductive from a business perspective.
Not everyone wants to be at the “cutting edge”, just for cutting edge’s sake. Though I clearly see the benefits of React’s component approach (and yes, I am missing this a lot in Blaze), constantly re-writting my app to hang around with the “cool kids” is not an option to me. I want to focus on business value rather than on having the latest technology stack.
And from that perspective, Meteor used to be the place to go, because of its simplicity and super-fast “from prototyping to production” cycle. But now I’m faced with a lot of community fragmentation (which will eventually lead to a lot of incompatible packages) and much more complexity.
It looks like if Meteor is becoming more and more a stack “from developers, for developers” rather than a stack for a quick time-to-market - which Blaze supports very well due to its proximity to HTML, which makes it quite easy to board new developers or designers.
Besides this, I expect that Facebook and Google will develop their own full-stack solutions based on React and Angular, so if Meteor is dropping one of its core USPs (which Blaze and its simplicity is, at least to my point of view), it will sooner or later become obsolete.
Maybe you will manage to keep Blaze’s simplicity on top of React, but I am not very optimistic that this will be possible - the approaches are too different. I really hope you will prove me wrong…
23 Likes
Like I mentioned before, everybody talks of “opening Meteor to the whole JS community”, add this, add that… But no one seems to care about the documentation and making it all actually work together. Who’s gonna write the documentation for all this stuff? Which package is gonna work with which package? These are practical questions.
Writing documentation is a lot easier said than done. Or we can just forget and let others figure it out. If that’s the case, we’re back at square one and Meteor web development will becomes neither fun nor accessible.
3 Likes
The whole point of the “Blaze templates over React” is to bring the ease of use of templates to work with a well thought-out component system of React. What approaches do you see to be different exactly? Why do you think it is not possible? Are those concrete technical matters?
1 Like
Hi Evan, correct me If I’m wrong, but this template layer on top of React is just going to be for those who want to transition from Blaze, right? Should I just jump into pure JSX for my new projects?
What do you recommend going forward? I’ll take whatever solution MDG recommends from now because my primary concerns (and I think of many other too) is what will have better support and resources, in terms of integration and documentation.
Thanks!
2 Likes
@evanyou
Thank you for this reply. The way you have composed this post, is an announcement worthy response for developers and people investing in Meteor as a serious project. I believe this should’ve been the official answer from MDG. If done like this, I sincerely believe that there would be a whole less drama. I do not see an issue when it comes to migrating for improvement. I see issues in the field of solution lifecycle and existing production apps. And this response has clarified the things I really care to know about.
10 Likes
Is this something that may be incorporated in the near future? Hoping to start a new React Native project by the end of the year, and would much rather have it directly within a Meteor app. Would you say this is something worth waiting for or should I just go the DDP route?
I don’t think we’ll have a seamless react native integration by the end of the year.
4 Likes
If you are open to trying pure JSX, then yes, I’d say start using React now is a smart move.
8 Likes
I don’t want to be picky, but when can we expect an official blog post on this matter?
1 Like
Is “Blaze templates over React” going to be maintained in the long run or is it going to be a one time deal? (so that old projects can still run and new ones are pushed to React)
4 Likes