For this kind of stuff you might be interested in the private package server I’ve been working on: https://github.com/sebakerckhof/stratosphere
1 Like
For this kind of stuff you might be interested in the private package server I’ve been working on: https://github.com/sebakerckhof/stratosphere
Whoa! This deserves its own thread, don’t you think? It sounds really exciting!
3 Likes
I understand that people are invested in Blaze, but here’s a reality check:
https://www.meteor.com/people
and
https://angular.io/about/
Angular has more people working only on a frontend framework than meteor has on frontend, backend, communications, tooling, database, … together. There’s just no way to keep Blaze up to par.
The only thing this is bad for is tutorials and packages that are not universally applicable anymore. It’d be hard writing a book for meteor nowadays. It’d get even harder if they include SQL support instead of only Mongo, but I still think that has to happen in order to secure the future of Meteor.
Btw, React people might be a vocal minority, but this entire forum might only contain a minority of Meteor users and give a very skewed view. Look at this thread: it is narrowed down to react vs blaze. Now React might be the new hype in Silicon Valley, but I’ve asked around to my contacts in IT recruitment companies here in Europe, and they have 0 requests for React developers. Most enterprises are still training their Java/.Net developers into Angular developers. Now these kind of companies are interesting for Meteor’s financials (and therefore for any Meteor user) and it’s much easier to convince them to use Meteor if it supports Angular.
8 Likes
I personally now have just decided to move to React. In many important aspects it’s just better than Blaze I think. MDG has created a nice migration path for Blaze to React in Meteor 1.2, so there is no problem in moving to React step by step. You can just convert templates as needed bottom up the template hierarchy to React and you can also have both at the same time while you migrate.
In my opinion MDG should recommend React as UI component part and put their efforts into other parts of the Meteor platform. Because for apps that eventually get large you would have wanted to start with React anyways and by recommending React to start with, less developers will need to convert to React later when there app got big and their view layer got messy before they realize. This could potentially save a lot of resources.
4 Likes
Should we also recommend people to use GraphQL and Relay instead of Meteor on the backend, so that people don’t have a problem later with switching, when GraphQL becomes the new hype?
2015 may be the React year. 2016 may as well be Angular 2 year. Who knows about 2017. Switching recommendations every year won’t lead anywhere.
9 Likes
Quick reaction to this as i am on my phone right…
- Blaze is still simple
- Webcomponents is simpler
- Almost every one i know loves react right now… But what if Angular 2.0 comes out?
- What if there’s a webcomponent engine that just loads a webcomponent and be a reactive reusable component that can act like a layout and also a component as well? And it also supports double and one way binding? Very light weight too… Would that be more superior than react, blaze or angular in the future?
For me, react is what node js when ruby on rails what the thing, ruby on rails when PHP was the thing, and php when .net was the thing…
MDG might be in the crossroads right now… And i guess it is a good move for now to accommodate react and angular. It is a bad move that they are not updating blaze to be more reactive and “scopish”… But if they can create a better component based rendering system that is very light weight, not entirely dependent on jquery, and easy to debug, test and code with… Plus the ability to render webcomponents and not clash with {{ }} [[]] then i am all ears 
I don’t think front-ends and back-ends are really comparable in that aspect. Backends have seen more evolutions than revolutions and you have a much longer lifecycle (you can probably still run your PHP4 apps for another 10 years). In the meantime, the languages adjust to each other (PHP even tries to look like any other language in the world). But in the frontend jQuery is still jQuery. Backbone is still backbone, … and change always comes more as a revolution in the form of a new library. Why? I guess because we’ve been abusing an unfit platform into doing something it was not meant to do. That’s why it takes a lot of iterations to discover what works well and to evolve the platform.
It’d be foolish to think that we’re at the endpoint. It’s our fate as web developers to keep adapting to new stuff. Maybe sometimes we’re following the hype to fast, but still, we’ve seen the evolution: all jquery widgets → backbone → Angular/Knockout → React/Angular2 and I think nobody who’s gone through the process ever wanted to go back to a previous stage. IMO, we’ve gone from a platform I hated for developing frontends to a platform I prefer to any desktop/native mobile front-end technology I’ve ever used.
So yes, in 2 years there will be a new favorite library, and we’ll probably be better of using that one.
And hey, in the meantime companies pay for people like us to upgrade their old app, so that’s positive ;).
1 Like
Problem is, some of us are either people who will have to rewrite their own stuff or who will have to pay for that. People who are not hired to work on others people webapps, but who develop their own ones.
An honest answer to the question “what’s exactly going to happen with Blaze from now on” is the least they could expect.
4 Likes
I am currently quite pleased with what Blaze can do. It most certainly one of the things that initially drew me to Meteor. I personally don’t want a templating engine as verbose and sophisticated as say, Angular. Since there are larger projects where that level of sophistication is relevant, of course Angular and React should be supported by Meteor-- for those who opt in. I wouldn’t mind enhancements to Blaze, but I would be opposed to an outright deprecation.
3 Likes
This, which in theory is part of the complaints within the community interaction thread. The community has to interpret what MDG is doing independently of what MDG says. Look at the Trello roadmap is this still valid? I don’t think so… Move routing into core is still marked as Future. New, object-oriented API for UI components is still in Future??? With the guide coming down the pipeline how about the meteor manual?
Right now MDG is in the driver’s seat for Blaze but for all intents and purposes have taken their hands off the wheel. @mitar is all like I’ll drive this thing, but MDG effectively says this is our bus so no you won’t. So no one is driving the bus, and the community in the back is all concerned, and then @sashko calms everyone down by explaining why the bus we’re on isn’t as nice as other busses so they don’t really want to drive it any more, and it is probably wise to try to jump onto one of those other busses.
So IMO drive the bus or get off the bus and let someone else in the community drive it. I’m sure @mitar would be gracious enough to accept pull requests from MDG.
11 Likes
I am not that sure but I think no other topic results in such an amount of discussions then Blaze does in the meteor community. So everyone in this thread is here because they love Blaze, to be more specific: the BlazeAPI, its concepts (e.g. separation of concerns and more) and the the template syntax (more or less)…
Its not about comparing Blaze with other Engines such as React or Angular, so please if you dont mind, open up or go to a thread with such topics. I think its more about how we will proceed with Blaze and what are the opinions and thoughts about the engine regarding MDGs decisions and the communitys wishes. I hope we all made it clear that we want Blaze to stay - one way or another (at least the “look & feel”, not necessary whats going on behind the scene). Furthermore we all see the need for improvements in Blaze.
And since forking is hip these days, why not releasing Blaze into the hands of the community to evolve. Its already decoupled from the meteor “core” since Angular and React had to fit in. Or MDG need to continue to work on it somehow. The only wrong way IMHO would be doing nothing regarding to Blaze.
8 Likes
Well, what is stopping the community? It’s MIT license after all…
I think in open source it has to go the other way around. First, there are community forks, some of them build new good stuff and get popular and ultimately MDG could give a recommendation or even merge it back in the core if they want to keep maintaining blaze. Then it will really be driven by what the people use and think is good.
1 Like
I think the issue here is that we are all “competing” for the same scarce resource: MDG time. So people who like Blaze are not satisfied with how MDG is not investing time into Blaze anymore (for example, myself, I do not have anything against investing time to support also other rendering engines, but I do not like that Blaze is not developed anymore, or that it would not be developed anymore). And people who love React would like that MDG would be investing more time into React and not Blaze (or would like that they would invest into other features, like SQL support, instead of Blaze, because they do not see the purpose of Blaze, now that they can use React). So we are confrontational because of this. If we knew that MDG has enough resources for everything then probably nobody would be objecting to having everything. As a consequence, our conversations center around the question which is better because we want to show to the other side why MDG should not be investing time into something which is less.
But maybe even if something is less, there might be some reasons to continue investing time into that. Many such examples were mentioned, like stability of the solid base to build upon (so maybe MDG should be investing time into fixing existing bugs), existing projects already developed or in the pipeline (which cannot just pivot), trust we have into MDG (we believed that 1.0 means 1.0 and that it is a LTS release). In some way it also switches MDG’s resources with resources of others: then others have to invest resources into migrating to React.
I do not have a new point to make, I just wanted to present another perspective for this topic.
(BTW, in this perspective the argument “React has Facebook and everyone else behind it” in fact means that yea, great, if so much resources are already being invested into React, then MDG maybe should be the one investing dedicated resources into Blaze, from the broader societal perspective of resource allocation. React does not need more, no? It will happen anyway, community will use it anyway, no?)
10 Likes
This was so fun to read. Thanks for writing it! I love it. How a good story can bring the point closer. 
7 Likes
I do agree with what you have said… But i cant shake the feeling that i get when react is being now pushed more and more. I have the same experience when i was fresh out of jquery when angular was the new wave…
OK let me try a different analogy - let me be 100% clear this is an un-official statement from me personally, not a representation of MDG or anything else. I don’t think driving a car is a great analogy here, because almost anyone can drive so it makes things look easy. Let’s talk about building a car.
MDG has built a car. The car can drive around, and has some really good times for 0-50 acceleration. It’s great for city driving, looks really cool, has a really sweet color of paint, really comfortable seats, etc. However, once you take it out on the highway, it gets a little scary - the car rattles a bit, you can’t really accelerate fast enough from the on-ramp, and some of the lights don’t quite work. Now MDG hasn’t put much work into this car for a while, and doesn’t have the resources to build a 2016 model. @mitar is all like, I’ll build the 2016 model for you, but MDG says this is our car model so no you won’t. So no one is building the 2016 model, and the community is concerned because they only have licenses for this particular model of car. Then @sashko tries to calm everyone down by explaining that there are some other 2016 model cars that are quite nice, and we could put the same paint, seats, and body on top of those, so there’s no point building a new car chassis and engine anyway.
Oh, and the other cars have some beta self-driving functionality, tons more repair shops and charging stations, and someone is already talking about bolting on wings so they can fly.
23 Likes
I keep hearing people keep making this point about Web Components, but Web Components doesn’t include reactivity. Using Web Components is by no means a panacea to the reactivity challenges that Blaze, React and Angular solve. The browser would need a Reactive Web Components API. So you’re suggesting we wait until they build React into the browser?
That’s why we need an official one. Please.
If MDG chooses to do it… Then that puts me at ease. At least there will be development going on Blaze. Nice interview http://info.meteor.com/blog/meteor-guide-interview by the way.
2 Likes
@sashko there’s a small problem with these 2016 models - they’re not as comfortable to ride around the town as that old model built by MDG. And there’s plenty of drivers who never actually have to ride it outside of their town and even when they do, it’s only few days in a year when they visit a family for Christmas. They don’t really want this 2016 model and somehow, the freshly developed wings make it pretty difficult to park in front of work office or shopping mall.
New paint, seats and body on top of the 2016 model that will make it behave as well on city roads as the old model would be great.
But as you said, that’s your personal opinion and we can’t take it as MDG’s word. So while the vision sounds really nice, it can’t really calm anyone.
For now, people are wondering if in a year or two from now they’ll still be able to buy new parts for their car if something gets broken.
I realize there’s lots of other topics MDG has to take care of. I know we can be pretty annoying with asking about Blaze. But other groups of interest are lobbying for their features too, so we don’t want to be worse. 
10 Likes
…The thing is Angular and React made poor interface decisions. The Angular interface simply sucks. The React interface, though is necessary to achieve performance, is a lot more extra work than Blaze. So all these frameworks have all this extra technical minutia to do, whereas Blaze is basically the most natural “what you would expect” interface to have, minus the fact that it doesn’t have Components. That said, it essentially does thanks to @mitar’s Blaze Components. It’s a clean interface into what React complicates.
That said, performance is an issue, and Blaze 2.0 would have to solve that, perhaps by complicating the interface, but I get the feeling that David Greenspan would make a cleaner simpler interface than React yet again. React’s a bunch of extra work. That’s a fact we have to face. It’s also a fact that Blaze without a meteor-approved Components API steers developers into poorly organized projects. What Meteor has needed for a while now is a proper extensible Components AND Models system. Essentially classes for each. That way, as another commenter mentioned, new developers aren’t writing DB calls in event handlers, rather doing things like making calls to static methods of a model class.
So I’m saying in the “steer your into good practices/organization” argument is that what’s at stake is more than just whether MDG has the developer resources to compete with React–it basically is about time Meteor becomes a proper framework. In short, most of all the Meteor community needs the answer to this question: if we were to make a Rails-like interface for Meteor and the modern “Connected Client” application, what would it look like?
In many ways it’s been a smart decision to have a lower level essentially imperative API thus far. It’s allowed for a lot of possibility. It allowed us to build out all sorts of packages without feeling inhibited. But I think at this point where we have gotten an idea how most of our apps are built, it’s crucial to settle on a class-based API for basically everything you do in a meteor. A class for models, a class for view components, a class for stuff that happens on startup. U know, like the sorta automagical classes you see in rails where all you relations, aggregates (and in Meteor’s case, subscriptions!) are setup for you with a few terse lines.
It’s time for that sort of stuff. And my point is Meteor is moving full speed ahead and praying that this area, Blaze, templating/components, is all checked off. A year and a half ago they made Blaze and that was a big deal–they could now keep up (supposedly) with its at the time recent competitor, React. Then MDG spent the next year up until now focusing primarily on Galaxy. Now that that’s done, I get the idea they have yet again more future ambitions that they are hoping they can focus all their attention on. And believe me, we have all been there, and end up kickin the wall when competitors change the landscape and it’s time to essentially pivot the product strategy for our startup. That’s basically happening now. The question is whether MDG wants to face it or not.
I think before moving forward into things like SQL, MDG needs to rethink the entire interface into their product. And the reason I bring that up in the React thread is because what that includes is not just letting some other camp (Facebook et al) dictate our interface. The React interface is no good. We can do better than that. Blaze’s interface is fantastic. It just needed components, and it needs to be more performant. Whether I go so far to say it needs a “Native Strategy” I can’t quite say. But I would say we probably shouldn’t give up on Blaze just because it’s “Native Strategy” seems bleak.
But that all said, if MDG was to revisit the interface into their product, they may realize they do need to assign a lot more resources to this area, and may find that they do have time to make something competitive to React, better yet, that beats it. I mean come on now, the attitude here is so defeatist. Like, there is no way we can defeat facebook and React. I remain unconvinced about React. And a lot of the stuff facebook is doing: GraphQL, Relay, etc. I think it’s awesome the ideas they’re pushing but interface-wise all there stuff isn’t what I would choose. And I’m not alone–if you read the AMA on crater.io, you would read that David Greenspan feels the same about React. Facebook is truly pushing things forward–there’s no doubt about that–but they’re constantly choosing these funky unnatural interfaces. Did we really need to create .jsx? No we really didn’t. Why cant the code in the render method be in its own file and look more like HTML, basically Sideburns is working on? It can–facebook chose not to. Why can’t we maintain the flexibility blaze allows to manage state how we want, and Blaze 2.0 implicitly figures out more about what’s going on to enhance performance–i don’t want to have to pass functions around to keep state managed in one component! I want to manage state how I want to, I’m a big boy. React makes you do lots of extra work, and this is just one example. More can be done to optimize what’s going on underneath the hood for you. React instead just offloads all this extra technical minutia/work on you. It’s like: I don’t wanna manage memory, i wanna focus on business logic–that’s why we choose higher level tools like Meteor.
So my recommendation is MDG makes it first class priority to turn their “system” into a true framework, which steers you into writing good code through conventions, classes, etc. React does such “steering” for part of the stack. MDG should holistically determine their vision steering us into writing organized code for the WHOLE stack, and that requires not letting React dictate how it’s done.
Whatever MDG plans to get into now where they are copping out and saying they just give up on Blaze is bullshit. Blaze, the UI, templating, etc etc, is the gateway into the Meteor world. It’s the shiney door that once was the shiniest across the land that brought us all here in the first place. MDG now (seemingly) wants go focus on what’s in the castle and let the door rust, or rather, replace it with the same door everyone else has. And I’m not even against that–if we do that, we should marry completely to the evolving “Facebook React Stack” (that includes GraphQL, Relay, Webpack, maybe RethinkDB and whatever else Facebook adds down the stack). But unless that’s the plan, we should reinforce the “entrance” and “walls” of our “castle.” All of Meteor from Components to Models to various auxiliary Classes needs to be made into class-based system. It needs to answer the question: what would the Rails API look like on Meteor, given its presence both server side and client side???
Chasing SQL is not as important as this. MDG’s plan is likely all galaxy for a while longer, and probably is how it has to be so they can get some more money to expand the team. But MDG needs to wakeup and realize they need to make a class-based API for the entire stack, not just view components. Most importantly Models!
My final point is don’t give up on blaze just yet. I’m talking to the community and MDG who seems to be in the process of formulating their opinion/plan. Sideburns is getting us an interface into React similar to Blaze. If MDG joined that initiative full force, they could likely come up with something very good that makes this entire thread moot. Check out Sideburns right now if you havent already:
React vs. Blaze may be a false decision. It’s already at least halfway false after looking at Sideburns. They’re doing a great job at making React look identical to Blaze, or rather, making React be what’s powering a Blaze/Spacebars-like interface under the hood. So again, Blaze vs. React is definitely at least a half false decision thanks to Sideburns–my question is: How can we make it an all the way false?? (and that’s essentially a rhetorical technical question; i would like us to think about how we can technically accomplish that; I think we should help the Sideburns guys).
7 Likes