I am the only one who thinks it is strange no other templating is mentioned, just react and angular? Or are these so superior, that nothing else worth mentioning?
2 Likes
The difference is also that you can in Blaze access outside state directly from template helpers (Collection.findOne(...)) while with React you have to pass that state from top to down. I find this really easy to use and easy to make composable.
3 Likes
Wow! You said exactly what I am feeling… I’m developing a big big ERP (like SAP), but a lot more simple to the user. I passed one year to deciding what platform to use, and I chose Meteor because it’s simplicity, reactivity (real time feature makes me crazy), and to only use JS for everything, and I passed months to learn Meteor and Mongo, and doing tests. But with develop of Galaxy, MDG forgot the evolution of Meteor. It make times that Trello page, for example, is not updated. It seems like that they don’t care more about the opinion of us (Where is MySQL, SSR, Routes, Incremental loading?). I feel as if the Meteor was going bankrupt. And it’s bad, so bad, for me, for the future of my project… And this news discourage me even more.
So… and now?
p.s. (sorry for my bad english too)
7 Likes
interesting indeed…
If it can play nice with jQuery and other libs that manipulate the DOM, will be a big plus over React!
6 Likes
For real. I want to be able to use jQuery plugins. Hope MDG makes that a feature of inferno. Plus it keeps in line with @gschmidt’s vision of Meteor cooperating with other JS projects. Although React Components might help bridge that gap, e.g., I was able to find a wrapper for the quite popular select2 jQuery plugin.
4 Likes
that’s “Sideways data loading” and what they already do in a plain form with getMeteorData. It’s not a pattern contrary to React’s beliefs and capabilities. They simply are tracking reactive Tracker-based dependencies within getMeteorData. The same can simply be done within component methods, forcing component updates when any method changes.
1 Like
@gschmidt, I really think that one of big issues was that Blaze was left as it is for a long time. When it got out and had views internally I suspected that sooner or later there will be a component system made around it, but it never was. I do not know why. Because it was pretty obvious how it should be done. Now, we have other libraries bringing UI components to the web and we do not have much feeling of how well Blaze would work as such, because we have not spend much effort really evaluating that option. We, as a community. So I can share some personal experience (and that of my team).
I made Blaze Components and since I made it I observed some really interesting things:
-
Composition and modularity is equal to that of React, things can just be nicely combined, if not even more. Because you can replace templates while keeping the logic around. It is really easy to make then components where the only difference is which classes and structure it has in the template to support Materialize, Boostrap, etc.
-
Integration with jQuery is still possible.
-
It renders much faster than what you are used by Blaze (using things like computed fields and no implicit dependency on data context in template helpers) you allow granular control over reactivity, so Blaze does not have to rerender much, or even try to recompute much, much less than React.
-
You are not forced to only one way to state propagation between components, while it looks beautiful, in practice you get to the same problem as with static typing. Sometimes you just have to go through a lot of complicated stuff to get your job done, and is not beginner-friendly. Limiting approaches to one “beautiful” paradigm often means you limit the set of programs you can express with that paradigm. Blaze Components on the other hand allow you to choose your paradigm. You can pass state in the same way as you do in React. Or you can use new stuff like traversing the tree of components and hook into reactive APIs of other components to get or set the data. This is really powerful and also allows clean separation and modularity. Imagine that instead of having a data only state passing around you can in fact pass around API surfaces components can hook into reactively. But even if that paradigm is not for you, you can use for example traditional event-based messaging as well.
-
Moreover, Blaze Components also allow you to fetch data from other reactive sources, like collections and so on. I think this is very useful because sometimes it is really just the simplest possible thing to do (like fetching current user, or that extra collection when user expanded details view you can then both subscribe to and display).
-
At the end, resulting code is also empty of all
refattributes and other React specific things. If you look at DOM it simply looks clean.
So, what I would say is that we are loosing some great opportunities here because we have not really experienced what a component-based and modular based Blaze would look like, collectively, as a community. I was on the other side so I am reporting back. It is pretty nice there. There are still some things lacking (like server-side rendering), but the rest is more ore less there. Incremental loading should work (no reason why Blaze compiled templates could not load on demand), speed is pretty good as well.
So when deciding about React rendering we should consider what we will be loosing from current solution. I listed above things which will be harder to do. Some of things React brings is maybe good for large projects (like strict-typing in programming languages generally is) but it adds complexity to smaller projects and beginners.
20 Likes
Meteor is barely one year on stable. By all means, now is the time to still make rapid agile moves to re-aligne to the - now - manifested ecosystem. Focusing on the back end of the curve (probably a tiny fraction of meteors overall potential) gets us right on track to a sluggish and potential false overall development. There need to be breaking changes to re-align with the overall ecosystem before we end up with arbitrary solutions.
MDG: forget about the end of the curve, have them fork the project if they insist, and make sure we are on track to a sustainable, fail-tested, application environment. Saying that, while personally having put a lot of money behind meteor.
2 Likes
To me the most exciting part of Geoff’s post is this and not the Blaze part.
MDG is taking a look at the Meteor stack from top to bottom and thinking about what’s next. We’re thinking about testing, routing, schemas, and more, and what should be a core package and what shouldn’t.
If you’re SURE Blaze2/React is the future then go for it. There seems to be a lot of people who think differently though. Don’t waste time on something that will be discarded in 6 months when there are already alternatives available. Meteor is still really lacking in a lot of areas but the view layer already has 3 pretty good options.
7 Likes
So we’ll end up with Blaze, Inferno, React, Angular 1 and Angular 2, right? 
I suppose we need a tutorial for each one. And maybe some in-depth learning material too. Or do we send newcomers on their way? Let them figure it out? As for Atmosphere, do we update packages to work with these front ends?
Which packages? For which front-ends?
Reaction Commerce is awesome. Will it work with Angular 2 or Inferno? Does the Meteor Chef have tutorials for Angular 1 and React?
Honestly, these are all legit questions and it’s something that’s being overlooked: Documentation. I like variety just as much as the next person, but each option you have is an option you have to support. We’re talking at least 5 official front-ends here. It creates fragmentation in the Meteor community and I don’t see that being discussed as a problem often enough. Do you really want to write the same tutorials and packages for these 5?
How will the community help each other if everyone is using different platforms? Suddenly your knowledge on Blaze doesn’t help me on Angular 2 or React. Suddenly my forms package in Inferno is useless for Blaze 1 users. We’ll get frustrated users and a bunch of bugs.
I’m wary of React because when the time comes to decide between what’s better for Facebook and what’s better for the community, they’ll choose Facebook, 100% of the time. My reason is non-technical. React is made to be good at what Facebook does. Whatever is not priority for a social network website is not priority for React, IMHO. That could stifle innovation and creativity in other fields. Would you agree?
As for Blaze2/Inferno, I’m not too sure. Those who love Blaze have made it this far, right?. Blaze is a solid foundation and simple to use. It can be extended with community packages. Seeing that MDG doesn’t want to focus on Blaze, maybe just keep on fixing eventual bugs from now on. Basic support. No more new features. Is that such a crazy concept?
People who like Blaze will keep using it. Many packages are mature and stable, the knowledge base is solid and patterns have emerged. Prominent members of the community are very well-versed in Blaze and can easily assist others without wasting time with refactoring packages. I think overall the Blaze camp is in great shape to be productive.
Those who wish to use React and Angular can already do so! Meteor is decoupled, remember?
In the meantime… there are 3 things that almost one year since 1.0 we still don’t have:
- SSR
- Core router
- Hosting (a cheaper Galaxy tier).
PS: For those who want Inferno, do you think it’s worth it if it’s not backwards compatible with Blaze? Is it such a bad idea leaving Blaze as is and extending with community packages as needed?
19 Likes
Does that mean I’ll have to learn JSX now??
What about Jade - I love it and want to keep using it.
ps. feels like MDG just wishes to eventually be acquired by Facebook(
4 Likes
SSR
Core router
Hosting (a cheaper Galaxy tier). - I guess, they’re working on it
+100 Incremental loading!
3 Likes
The horror of making JQuery plugins compatible and work as expected is unimaginable. It takes so many man hours to a point where you sit back and ask yourself if you are really making the right decision.
9 Likes
I completely agree. This Blaze Mk2 debate is interesting enough and maybe it will lead to something good, but NPM integration is just much much more important.
1 Like
Exactly… as far as I can understand it, all the very real problems you list are there because Meteor is silo’d from the rest of the javascript community, basically NPM yes?
1 Like
Well MDG are a business. They’ve been given large amounts of money by people who hope for 10x return. Selling to Facebook et al would be one way to get a return. I actually want MDG to behave more like a business… creating products that other businesses (like mine) really want to use.
Anyway FB are alright, they’ve just created a brilliant new way to use Javascript on the web and on native, and they’ve given us that for free, which is pretty awesome 
1 Like
Just business. Maybe Facebook it made such an offer you can not refuse? (-:
Well, getting 10x profit usually means walking over someone (just like Karl Marx used to say). In this case - dumping Blaze and all its multiple fans.
Yes, Meteor is free and MDG is free to do as they will, but since now they have many devs and apps dependent on their free product - they also have a responsibility before that community.
2 Likes
Meteor is definitely going the hard way. When it was created, many nice things simply didn’t exist.
Today, we have working Webpack (fast and easy build system + incremental loading), updated Npm (atmosphere, hi, but you soon will be a mess, just like npm), React, Redux, etc. Instead of reinventing everything (package system, modules system, build system, view layer) it is better to spend the time and open Meteor to the whole js community.
Finally add additional databases, make easy work with npm, easy webpack integration. Build models, validation, choose the router. Use the things, all js community uses (React, Angular, etc).
This reinventing of everything just stops the whole Meteor development and is bad for all of us.
5 Likes