In my opinion, because it’s faster, provides more options without forcing your code to be written a certain way, and packs most of the best features from React and/or Angular, in a very lightweight package.
If Blaze 2.0 went with React + Mobx as your describing, it would take huge refactors in order to get existing Blaze code to work. Where if Vue was used, the refactors would be much more reasonable. Vue offers more choice and seems more aligned with how Blaze works, where React is a bit more opinionated.
I agree with all of this. If the goal is to have a new templating system and remain backward compatible, then Vue is the best choice.
But the thing is Blaze 1 isn’t going anywhere so existing code will continue to work, with zero refactor. If you are writing new apps or new components, why not use React? IMO any template based system (Angular, Vue, Ember, Aurelia etc) are not as ‘fast’ or easy to reason about and you pay a huge cost when using templates.
And if you do want to use Vue, it should be Vue, not Vue under the layers of Blaze 2.0. There’s nothing preventing MDG from adding official support for Vue (like with React, Angular) and keep Blaze 1 also. I’m not suggesting Blaze 2.o use React, there’s no need for a Blaze 2.0.
The goal shouldn’t be to keep the same style as Blaze or whatever we have today, it should be to use the best approach.
I “think” that’s the purpose of this proposal of Blaze 2.0. Otherwise, it would just be Vue support for Meteor.
Regarding Blaze 1 - I believe it’s important because while, as you said, Blaze isn’t going anywhere, it’s kind of at an impasse. It just got switched over to community-supported, but if we think realistically, it’s doubtful that anyone is going to put as much work in to Blaze as the developers of Vue, React, Angular, etc are getting.
As much as I would love it if MDG does give Vue the React treatment, I can’t say I agree with your first sentence there in all circumstances.
Sure, as a new project, you can use Vue. But there’s many situations I could think of that this would not be ideal.
For example, many of us have existing Blaze projects that have been kind of in limbo. I would love to have support for some newer view framework features, but a complete refactor to Vue directly would be a lot of work. But it would be quite an awesome upgrade for Blaze if Blaze still worked and I could simply start using those new features in addition. This would keep projects functioning correctly during transitions to Vue as well, allowing users to refactor their projects over time/as needed, rather than all at once.
Also keep in mind, most new users of Meteor end up choosing Blaze initially. Rather than this being a long-term limiting factor, Blaze 2.0 w/ Vue could allow new users to start almost the same exact way they did in Meteor 1.0, and then as they become more experienced, dip in to the new features.
Not to mention, it’s a huge benefit if users have been using Blaze for years, and have collections of different systems/components/etc, and be able to still use them after switching to Vue. Of course, refactors would make them work even better - but just being able to use your old code is a huge boon.
That’s true to a point. But with all the potential refactors we have coming up in Meteor, the last thing we need is even more on our plate. If I was going to complain about 1 thing in the state of Meteor right now, it’s the worry about major refactors.
Fully viable Vue support, with an additional package that could optionally be added for legacy Blaze support in Vue, in my opinion would fully achieve that goal of the best approach, while helping out all the users who stayed faithful to Blaze (which, according to polls here, is a very large part of the community, despite some comments indicating otherwise).
A lot of what defines Meteor is being deprecated or will be - Atmosphere, MiniMongo, DDP, pub/sub, self contained installer/build etc, as Meteor tries to become more mainstream. DDP/Tracker/MiniMongo is the Meteor ‘magic sauce’ and that’s all going away for Apollo. Talk about major refactors
I’m not sure how much resources MDG has. Which of these options is simpler ?
add support for Vue as view layer
build Blaze2 on top of Vue while exposing all its extra features and use Blaze syntax
1 seems easier to me. A lot of the work in adding React/Angular was probably in integrating their build pipelines. I am not a fan of providing shims for a framework because it leads to problems. e.g. say we do 1.
the shim between Blaze and Vue will have to be updated with every Vue update
devs won’t be able to use the existing community of Vue, their docs etc
all the features have to be duplicated in Blaze 2. e.g. will there be single file components?
Yeah, your first paragraph is the issue. We’re already going to have to refactor all of that. Having to refactor for a modern view framework is the last thing we need.
Also for any users that stay <= Meteor 1.4, the majority of them would be doing so for the sole reason of not having to do major refactors. (That’s the spot I’m in on our businesses production app) So being able to have something like this is very appealing.
I don’t believe that MDG is contributing any resources to Vue (or Blaze really) at all. It’s in the communities hands completely. Which is why I’m throwing in my thoughts/support of this idea.
So the communities choice is: Work on Vue support only, or work on an additional package (likely on top of the Vue package) that will add support for Blaze in Vue.
With that said, I have been one of the most vocal people speaking against how MDG is handling their current upgrades… It seems to me a bit like users who have supported MDG through their tough times are kind of getting shafted by the direction changing so much. Most of the roadmap is not too useful for any of us that have existing Meteor apps, so it’s pretty much just refactors coming up…
Some users have even expressed fear that Meteor is already deprecated as a whole. I can’t even say if this is true or not - they are very quiet about what to expect. But it’s a real worry and I have been vocal about being worried as we have a production app & a lot of future work planned in Meteor. I feel refactors should be avoided as much as possible (and I likely would not have made the decision to scrap so much of Meteor if it were up to me).
With their decisions of so many things being deprecated, including major systems that every user was reliant on (such as Atmosphere), as well as the old principles they used to have on the website about what Meteor was about, I feel they should be more vocal with what we can expect so we can prepare for it, as well as they should take some consideration that we will have to refactor. At least give us some sort of path for refactoring and porting our Atmosphere packages over to NPM or something. They have said they will try to keep backwards compatibility as much as possible, but have been pretty hesitant to commit beyond that.
I just think that if it’s true that Meteor is still “Meteor”, that refactors should be kept to a minimum, and users should have a reasonable path for upgrading. If it’s really not Meteor anymore and Meteor has been abandoned, that should have been told to us up front, considering some of us have production apps.
This is getting a bit off topic. So back to topic - my point is that if it were up to me, I believe the best thing for Meteor and the community would be putting in a little bit of extra work to support the Meteor Blaze community as a whole. Rather than just replacing Blaze (which, lets be honest, if polls are correct the majority of people are still using Blaze), giving that majority of users new features from Vue would be the best that Blaze users could possibly hope for.
Again, this is from the perspective of someone with a production app made in Meteor that is to have ongoing development - I personally know how it feels to be worried about Meteor’s future, and it’s not good to feel unsure if you’ve been abandoned. I’m not sure what the community as a whole thinks about this, but from my perspective, I’m more concerned with future updates supporting current Meteor developers, rather than new features that will only support new users creating new projects. Many upcoming features are not going to be useful for current Meteor devs - I think it’s about time current Meteor devs should receive a bit of love.
Why should it be the replacement for Blaze - just because it has templates?
Vue has server-side rendering
Vue performance can be faster than both React and Blaze because of it’s awesome reactivity system
Vue provides hot-swapping components for development
Vue’s component system is much more explicit in terms of data passing and interfaces between parent/child components than Blaze, which took direct influence from React
Vue has a chrome extension for dev tools that allows inspecting the component tree and component states, as well as time-travel debugging
Single file components are incredible. Having your view (<template>), controller/view model (<script>), and styles (<style>) all in one file is really amazing for code clarity, maintainability, and readability.
Vue has a router and a flux implementation that are officially built by the Vue project maintainers, there’s no “which router should I use”. This enforces consistency across mulitiple code bases and makes swapping between projects really easy.
Yes I know the standard reply to this is that Vue can do JSX…and its kludgy in Vue.
The API is almost exactly the same as React’s, a render() function that can use JSX. I’m not sure what you mean by “kludgy”, if it’s fine in React then it’s fine in Vue.
I really can’t say enough good things about Vue. It takes the best parts of React and Angular, and combines them into a powerful UI layer that has an API that is, IMO, much more developer-friendly and easy to user than any other framework out there.
A complaint that naysayers had about Meteor was how ‘opinionated’ it was. They weren’t really complaining that there were multiple routers to choose from, they saw the variety of options as a plus (not me though). And in response, Meteor became less opinionated. And now we have to use includes and explicitly declare file dependencies in our code outside of packages (as if Meteor’s magic isn’t what caught our eye to begin with)
Well… we don’t have to. I’ve got a production app that’s gone with Meteor from 0.5.7 to 1.4.2.3 and I still use globals because I can’t be bothered doing all the imports. That works just fine at the moment and, if/when it doesn’t, I suppose I’ll just pin to the last compatible version of Meteor.
I’ve been sponsoring the new Blaze standalone at $100/month for a few, and will continue. Just need a few other larger/similar contributors and we will have a VueJS situation/momentum for blaze/2.0. I don’t see it as paying for current blaze, but pushing for that next iteration.
For people that complain about imports or having to do an npm i, after a git pull, not wanting to be rude, but this isn’t an issue with Meteor, welcome to the best practices of the JS community in general
Some would see the lack of having to write explicit imports as a feature that addresses a pain-point. It’s extremely useful during rapid prototyping when the form and function of the app is still volatile. Same reason NoSQL is great for rapid prototyping compared to SQL; you can modify or completely overhaul the database’s structure on a whim. Being able to move files around, or to cut a chunk of code from one large file into a new specialized file – all without having to refactor import statements and keep track of which file is using what – that is a benefit IMO, a utility.
They have stated in the past that this backwards compatibility is only temporary until 1.5+.
I’m not sure if this has changed, after all the complaints about it being temporary. I’ve asked about it before and responses have seemed non-committal. They have said things such as “their recent updates should show their committed to backwards compatibility”, but haven’t actually responded directly to the point of backwards compatibility on imports.
I, too, am in the same situation. We have a very large production app at work. It has well over a thousand files at this point, and that would be a huge job to refactor. I spoke with management and they have backed the decision to hold off as long as possible.
Again, these type of situations with having a production app, are exactly why some of us are pushing for Blaze 2.0 as Vue. Because with Meteor’s current direction, devs with production apps seem to be forgotten. But the Blaze community, for the most part, has obviously stuck with the old direction. Vue would be an awesome gift for us Blaze users sticking with the “old” way.
I don’t necessarily think it’s the fact of imports directly, as much as many users see it as a downgrade from “Meteor’s Magic”.
The lack of communication also caused damage with this issue. Amid all the worry about Meteors direction changing after the ruckus with React last year, people weren’t sure if classic Meteor was going to be abandoned. MDG gave a resounding “No”, but then in 1.3, all of a sudden everyone is supposed to do imports now, and when looking at the tutorial/Meteor guide, suddenly everything is twice as verbose. It felt a lot of the magic was lost.
Many of us considered the lack of imports, a huge boon of Meteor’s magic. If you take out the magic, it feels less and less like Meteor.
Hence, a lot of the worry for the future, as well.
It’d be nice to have some official communication from MDG about these issues.
I’m more worried about what will happen in 1.5 with data. As I said before the real magic in Meteor is pub/sub, DDP and Tracker, all of which is going to go away with Apollo. If you look at any GraphQL examples, its extremely verbose and not simple, it doesn’t have any equivalents for realtime data really.
If they want Meteor to compete with the big frameworks then there’s no option but to adopt the newest JS trends - that’s the sad reality in modern JS, everything is obsolete in a few months when something new comes along and legacy support be damned.
Also I’m guessing the money is in courting new developers to use Galaxy and Apollo,
Where was that stated? I have seen this mentioned often in the forums, but never seen it officially or even as a statement from someone at MDG. My perception is that this has become a myth, and because no one from MDG will officially state the reverse (in OS everything is “possible” so I guess that guarantees are never a good idea), it keeps living on. But I have seen statements/opinions (from @sashko I think) that indicate the intent is that for the foreseeable future backward compatibility would be maintained as much as feasible. Or maybe I really did miss it, in which case a link would be great. An official clarification of intent from someone at MDG (not asking for guarantees) would also be great.
That’s the problem. It was only stated to us that it was temporary ON the forums (aside from the brief mention in the Guide).
Here is the quote from the “Application Structure” page of the guide:
This old system still works, so to opt-in to the new module system code must be placed inside the imports/ directory in your application. We expect a future release of Meteor will turn on modules by default for all code, because this is more aligned with how developers in the wider JavaScript community write their code.
More recently, I have requested more information on much of the same that I’m mentioning here. For clarification of if the backwards compatibility is still to be temporary, or not. And yes, sashko did respond mentioning something along the lines of “the recent updates should show their trying to support backwards compatibility as much as possible”…
But regarding the specific question of the backwards compatibility on imports, that question was not answered any of the times it has been brought up, and they have been very careful to be non-committal.
I, too, would like an official clarification. But noticing that this very specific scenario has been non-committal is a bit worrying.
Hey thanks for the mention. Unfortunately it seems that clarifications in random forum threads haven’t been very effective - people just ask the same questions over and over again and misinformations become memes.
Trying as hard as possible to maintain backwards compatibility has been one of the core drives of Meteor for years. We are going to keep prioritizing that, otherwise we would lose all of our customers. The number of people who upgrade to each new version is one of the most important metrics we track.
We’re not some sort of illuminati that’s controlling the message everywhere. We are just a team of people honestly doing our best. I can promise you that it would make no sense to release a version of Meteor that breaks all current apps. But why should it be up to us? Get involved on GitHub! Review our PRs! Comment on design discussions! That’s where all of the action is. “Official” statements on forums don’t help anyone since the same stuff comes up over and over again.
lol, I didn’t think it was a conspiracy. It’s only that, a few times (including this topic) the question has been directed specifically at the modules/exports part of backwards compatibility, but the answers are more along the lines of “general backwards compatibility” which gives the impression of either “undecided” or “bad news” for the modules aspect…
Using the above message as an example, it gives relief for general backwards compatibility, but even with that, I’m still unsure on a direct answer for the modules/imports backwards compatibility, since it has not explicitly been mentioned (and considering the guide does explicitly mention it).
Since there has already been a warning in the guide, so it’s not too far fetched to think that it may not be considered “breaking the app” if we were expected to have added the imports already.
We expect a future release of Meteor will turn on modules by default for all code …
really implies that there will be an option to not enforce the use of module imports, just that sometime in the future it may not be turned on by default
I really believe that people tend to read too much between the lines… I expect that applications developed using pre 1.3 will continue to work very much as they were written for a long time.
I mean, you more or less did that by introducing imports and not really provided a way to disable them for those who do not need/want them. Because of that you effectively deprecated use of custom packages as a way to organize code because now it takes much longer to process hot-reload changes in them than in client directory outside. Moreover, if package contains a lot of JavaScript code, which is never used, only addFiles is used, Meteor now still tries to parse all those files and process them, because they might be imported, but they are not. And this happens even if your package is not using modules package. Because those extra files can be really large (in my case, I have node.js as a git submodule inside my package, to pick few files from there), Meteor never manages to finish processing such a package.
I have been involved in this and commented on this, but nothing happens. That old behavior is simply deprioritized so that not much development goes into it, which then makes it really hard to keep using it, without having to refactor things. And yes, there is on paper backwards compatibility, but in reality some things are needed to be implemented to be really useful again. And because this is not priority, they are not implemented by MDG. So community should be maintaining old versions while MDG is moving to new stuff?
Let me make a list of issues which are around because of introducing imports, or which are related to packages, but nobody works on them because packages are not really supported anymore:
Vue 2.x templates are just syntaxic sugar on top of render functions, just like JSX. At runtime, there is no difference between writing render functions, JSX or templates (see this package). The added bonus there are that templates can be compiled at build step OR at runtime, and that static parts of templates are hoisted from the rendering pipeline, meaning even better performance.
The whole philosophy of Vue is being progressive and incrementally adoptable. You don’t have to learn more than 20% of the api surface to start writing awesome apps or even just widgets for any webpage (for example, a PHP site). Here is an example.
