Why doesn't MDG just adopt Vue.js and forget about React vs Blaze?

core
1

With all of the discussion surrounding what is going to happen to Blaze and how soon React will be the default UI layer of meteor, why is everyone ignoring vue.js?

Reasons why vue.js should be considered

  • Vue is maintained by a core meteor developer.
    Evan You created and maintains vue.js, and is a core meteor developer. This gives him insight into what meteor needs, as well as having an independent, agnostic UI layer (which I believe is what meteor needs)
  • Similarity to Blaze
    The syntax for vue.js is extremely similar to blaze. In fact, it seems like a perfect three-way marriage between angular, react and blaze. However, the focus of vue.js is strictly to be a front-end UI built for quick starts and short learning curves. This fits into meteor’s wheelhouse perfectly.
  • Maintaining meteor patterns
    One of my biggest issues in using react is that it does a terrible job of maintaining separations of concerns (in a front-end developer experience). While react tries to manage your entire application state through flux/redux, vue.js doesn’t care.
  • Speed/Small learning curve
    What many of us may not realize is that one of the main stengths of meteor is that it allows developers with little to no experience learn how to make rich applications through it’s speed of getting set up and running. It’s why I learned meteor, and why I’m a developer to this day. The front-end UI layer of meteor should be the same and should not require a complete rethink of your application.
  • It provides possible stability
    React is the hotness right now, we can all agree to that. But last year at this time it was angular. Many years ago it was Ember. Essentially, every so many years we see a change it what people prefer. Being that React is going to have to compete with angular 2.0 soon combined with the fickleness of front-end techs, why not just choose a quickly up and coming framework now and make it our own? If not, what happens if the tides turn and angular 2.0 usurps react as the front-end framework du jour?

I ask this because I see for the first time, a large fracture in the meteor community. As a person who’s been evangelizing meteor every chance I get, that uncertainty makes it harder to do so. It also provides a pause for me on if I even want to start a new project in meteor today, instead of just waiting for things to shake out (however long that might be).

It seems to me that meteor should be keeping everything it can in-house because it provides stability for the future. Vue.js looks to me to be that candidate that can be merged into meteor without much effort and front-end UI can be considered stable for a long while allowing MDG to focus on better things like integrating webpack, etc.

33 Likes
2

Simple, adopting Vue.js doesn’t align with MDG’s new priorities.

1 Like
3

I’d guess it also has to do with React Native - MDG probably wants to support native apps and not just Cordova. And maybe they want to be the unifying build tool for these two before Facebook does it and potentially creates a competitor.

12 Likes
4

OK, I get that. But FB is going there anyhow. Could MDG think they could get enough of a lead on FB to make a difference?

5

Vue is truly fantastic. But the thing is this, in addition to the “React Native” argument, React actually closely resembles Web Components. The parent to child composition of components dictated by props is looking like what is “it”. The interface presented by React is looking like it. Doing things like providing special element attributes like v-model in Vue or the plethora of attributes you supply in Angular is not it. That’s not the way. That’s not the interface of the future. I.e. yet another custom DSL for the web is not it. And then you have all the $ symbols in your js code–didn’t we get rid of the dollar sign with jQuery?

Conclusion: new DSL bad. It feels like duck-tape hacks holding things together, and that’s not the feel the web should be pushing forward. That’s why React decided on JSX (which is languages we already have: js + html, no more no less), and why Spacebars is so minimal in terms of what you can do–i.e. there is syntax for loops (#each) but no syntax for attributes.

As for Web Components, besides universal support (only Chrome natively supports Object.observe()), it’s missing some things for reactivity. Essentially to get the same level of reactivity as React requires quite a bit more boilerplate. In short, Web Components and React share a common composition interface, but not a common model for reactivity. I can go into that in another post. The point is people shouting , “why not web components” dont fully understand its capabilities and limitations. That said, Web Components in fact is not far off. But React is ready today. Since their interface is similar, by picking React, we are 90% future-proofed if Web Components takes over. If Web Components did take over, it would be a lot less difficult to make an adapter for React to Web Components than Blaze to React.

So anyway, by settling on this unidirectional composition/component-based props-pass-down interface, we are basically future-proofed for all that will come our way. What templating language you use shouldn’t matter–whether that’s JSX, handlebars, etc. I’m not sure why more templating languages aren’t in fact used with React currently. While I have no problem with JSX, there are plenty of times where it doesn’t make sense. You should just be able to mix and match templating languages in one project, and that will likely become common place at a certain point. That’s one thing I’m gonna offer in Sideburns.

Anyway Angular and Vue aint it. At the end of the day, it’s looking like React is gonna be more than the flavor of the month. Its “interface” is looking like it has a lot of staying power, and that’s the difference. Now, add React Native, the shear explosion in its ecosystem/community among serious developers (which is bigger than what we saw with Angular in previous years), well, “The React Interface” is looking like its hear to stay.

6 Likes
6

@faceyspacey Looks like you haven’t really checked out Vue’s component system:

Back to the original question - probably because the community simply don’t know enough about Vue. It’s easy to look at the Vue examples and assume it’s only for simple stuff, because it’s so simple.

For MDG, Vue’s primary drawback is that it’s DOM-centric - it doesn’t address SSR and Native UI. Sure we can try to build SSR and VueNative, but React already has that. While Vue SSR is somewhat feasible, ReactNative has more than a dozen full time engineers working on it. MDG simply doesn’t have the resource to build a competing solution. The strategic decision lies between going with Vue and may just lose out on the native front in the long run, or ride with React and leverage what Facebook has built.

So in short, Meteor as a platform has a different set of criteria on picking a view layer than a company building a specific product. While I personally believe Vue is probably the most pleasant view layer out there for pure web applications (and even hybrid apps), as a company/platform I can understand why React seems to be a safer bet.

27 Likes
7

Evan, of course you can use components in Vue. And that “re-introduction” article you wrote I’ve read several times and is great. Blaze is like the only system of recent times that didn’t include a component system. So that’s clearly not my point. The point is to use Vue, you gotta learn an entire DSL, which you don’t have to with React or Web Components; and ultimately that obstructs any simplicity you may in fact have in your props-passing component system.

Now that said, there is a lot of simplicity to Vue, which is why it could be said that it’s “under-rated.” It’s almost easier to get started with than React–which is an awesome thing–but then once you dive in the API surface is many times bigger than that of React. Like I said, it basically has its own DSL.

ps. @evanyou left you a question in your Vue forum about an hour ago.

1 Like
8

Great answer. Thanks for this. This helps clear up MDG’s thinking as well.

So it seems “native” is the missing component that Meteor is looking to fill with React’s ReactNative. This makes sense in the short term.

But what are you giving up, strategically speaking, by going with React over keeping Blaze and building BlazeNative or going with Vue and doing a VueNative for example? What are the downsides to “leveraging” React?

1 Like
9

Vue’s DSL is tbh not any more complex than JSX or even Spacebars. In fact, the readability is often significantly better than poorly-written JSX render functions.

As for Web Components - you need to realize that the specs itself is far from sufficient than building actual apps. Raw web components do not address props passing or data binding at all. You still need a DSL on top of it to do anything meaningful (e.g. Polymer).

The API surface argument is also subject to debate - while React’s core API surface is minimal, it leaves a LOT to the user land and once things get complex you end up having to resort to higher order components with complex prop expectations, which essentially have a mini-API of its own. It’s a tradeoff. I can write a library with only one API method and claim it to be the best, but that doesn’t make sense. The better question, in fact, is how big an API surface it should be to provide the best learning curve / productivity ratio.

4 Likes
10

I agree with you on that one. But it’s all about marketing, presentation, etc. Learning how to swim in shallow water before being thrown into the deep end is important. React helps you learn to swim in the shallow end better via the “addons” approach.

agree.

Brother man, the plethora of custom attributes and dollar-sign-based methods–i could be wrong–but just doesn’t have the same appeal and staying power. There’s an aesthetic aspect, a taste aspect. Im sorry to say, but Angular and Vue lacks because of that. Also, it may not be more complex because of the argument (I agree with) that you make that React addons ultimately adds likely more complexity, but it gives the feel of a way bigger barrier to entry. So minus the addons, JSX only has like style and className behaving in a special way, and it’s not too different than what you would expect in plain HTML. That means JSX doesn’t even have a DSL.

I personally prefer Spacebars + React than JSX. That to me is the simplest yet most effective.

11

It’s pretty pointless to judge the “appeal and staying power” based on your personal preference, to be honest. Web developers have diverse preferences. For example, many people simply hate JSX while some find it superior. Many backend devs who hardly do any frontend have found Vue to be easy to pick up and get productive with, that “it’s the first JS framework that clicks.” It can be pretty subjective. If you don’t like Vue, fine, but maybe others do.

3 Likes
12

Another option is that MDG, with millions of investments, needs to keep options open for a potential acquisition. Facebook has the money and is actively pursuing a huge developer following. Going all-in on React increases MGD’s chances of some day getting acquired by Facebook. Facebook in turn might like to buy MDG because they provide the data-layer that just works - for React based apps.

2 Likes
13

I love Vue. I was amazed when I saw it. Funny thing is I saw it long ago, but it didn’t stand out. However when I saw it again recently, and gave it a second shot, I was really impressed. I think maybe it was that “re introduction” article. That goes to show you how marketing and presentation is everything, or at least more important than us developers often want to consider it

…I’m aware of Subjective vs. Objective. Perhaps, that’s the point of life: discerning what are subjective opinions while pursuing seemingly higher objective truths, which themselves often turn out to be subjective. So clearly what I’m saying isn’t that this or that solution is “it” because of my personal preference–rather what i’m saying (and it should be implicitly understood that this what i meant) is:

“it’s my PREDICTION that more people subjectively prefer not to have a DSL, custom attributes, dollar signs everywhere, then a component system that almost resembles HTML + JS as is.”

But let’s widen the perspective of this conversation. It’s my prediction that "professional application developers" prefer not to have angular style DSLs, dollar signs everywhere, and rather something that looks a lot more like React classes. It’s no wonder Angular achieved such popularity–it tackled a way larger audience: plain web designers. After all it’s a lot easier to design HTML/CSS and a bit of jQuery than to be a real developer. So that’s obviously why there are so many Angular developers, and same likely goes for Vue. But us real full stack application developers shouldn’t let our future be guided by HTML and designers anymore. Those days are over.

Anyway, what I’m really saying is it’s not even a binary equation. There’s a place for everything. Angular was great for web designers. I know that goes a bit against what I’m saying about web components being simpler, but that’s because in React you gotta write classes (which is anathema to non-developers) whereas in Angular you can basically get things going without a real line of JS. It did a good job of marketing itself that way at least. Basically HTML element attributes was something already familiar to web designers–so angular capitalized on that–whereas to full stack developers that has poor taste. Call it a subjective preference, a prediction, whatever you want. It doesn’t stop the fact that it is likely an accurate prediction for the target market I’m specifying: we dont like custom html attributes; we rather deal in true code; and therefore we don’t like their associated $dollarSignEverything counterpart.

So MY PREDICTION IS that Vue and Angular stay great for web designers. But serious application developers gravitate towards React. I don’t need to produce statistics for this for it to be obvious to everyone that this is more than my personal preference. Everybody with experience watching the game knows. So lets not get stuck on semantics. It just boils down to what Meteor wants to be, who it wants to target. While they do wanna be easy to onboard newbs, it needs to fully satisfy full stack developers (the ones that will eventually pay for Galaxy). In other words, when it boils down to it, full stack developers trump newbs as the target market. It’s a close race, to the bitter end, but full stack application developers comes in 1st as a priority. …again, I’m implicitly saying that’s my “prediction,” lets not get stuck on semantics…

Anyway, I really dont mean to come off as negative against Vue, Evan, as I know what it’s like to put a bunch of work into a project that in various ways is getting beat by competitors. I really dont. I just think it’s important we seek to frame things as accurately as possible so the community can understand the decisions being made. And I’d say the most accurate way to frame it is this:

“Well, if Vue (or Blaze) was in fact better–according to our best predictions–for the target market on both the implementation level and interface level, then we may be able to consider going up against React, notwithstanding we are far behind in terms of the Native Solution, SSR, and the dozens of engineers. But the fact of the matter is we (Vue or Blaze) across the constituent points are not better. Not for the full stack application developer target market. React clearly is going to be more than the flavor of the month. Meteor’s style has always been to do a few things really well rather than offer a bunch of 80% competing solutions, so we think the smartest solution is to really rally behind React.”

That all said, i’m actually one of the people really upset with how they’re going about it. Particularly that they have no plans to render Blaze 1 with React alongside the new components. That they made their announcement before figuring out that it was possible. That you personally, Evan, think it’s not possible, when I can show you exactly how it is, and have in these forum posts, and you clearly haven’t checked out the work yet. I get it, ur busy, I’m not judging. I’m just saying I hope before you guys get serious about this task, you consult me, someone who has put a lot of work into a really good backwards-compatibility vision here. …So that all said, MDG is currently engaging in a poor PR strategy. They’re scaring everyone when they don’t need to. If Blaze 1 is remotely backwards compatible it should be attempted by MDG, even if it’s not 100%. The current plan is likely to build what I submitted this week in the TrackerReact package + autoruns/subscribe methods on your React components. Oh and spacebars transpilation. That all great, and you don’t gotta do it Evan–it’s on its way to being done–what we really need is MDG’s commitment to render Blaze 1, provide transpilation tools, etc. If they really really wanna take care of their community, that’s what they would do. Not just make Meteor-enhanced React components, and then throw up some documentation of how to rewrite your components in that style. Not just let us settle for us rendering our Blaze HTML into React components like is currently promoted with the loginButtons UI plugin in the React To Dos tutorial. You can do some tricks with React to render Blaze 1. It’s the perfect stop gap until you convert your components to the new Meteor.Component or whatever it ends up being called. Truth is we need your help. It’s challenging. You should help @timbrandin right now finalize the plain spacebars converter. We removed the more dynamic aspects and I’m now handling them separately as mixins (which can also be used by React on its own), while he is handling plain spacebars conversion.

You guys plan to do that much at least anyway (spacebars transpliation)–you guys should be working with Tim since you guys plan to engage the community more now than you used to.

2 Likes
14

Basically the only downside is that old code won’t easily work. It will be a migration problem. Otherwise most of the great stuff you get in Blaze can in fact be brought to React. Here’s the precise list of what you currently lose (which we’ll hopefully bring back):

  • event selectors
  • reactive data sources (solved this week by the TrackerReact mixin)
  • simplified spacebars syntax
  • custom block helper else blocks (there’s no equivalent in React)
  • a simplicity more natural to web designers coming from a little bit of jQuery knowledge, which Blaze does a better job (the main abstract bullet point here)

There’s a few more, but those are the big ones, so you get the idea. Those don’t come by default with React. So those are PROS of Blaze that React does not have. That said, they can be brought to React essentially as mixins like TrackerReact. So the short of it is we gain a lot more than we lose by going to React. As for Vue, @evanyou basically listed why we dont go to Vue: no “native” or SSR solution, dozens of engineers at Facebook, etc. That said, if it was in fact a better interface and better implementation for the Vue layer, I dont think that should stop us or anyone. Facebook, Google or Microsoft or whoever could and should pick it up and run with it. Maybe MDG isn’t big enough to do so, but you get the idea. If it was really crushing the competition, the development community shouldn’t let it lose to lesser solutions; and then we’d have a case for MDG to rally behind it.

Although I have some disagreements with how MDG is going about it, I 100% agree with the decision to fully get behind React. I don’t think full stack application developers in the meteor community will benefit from a 3rd of the packages being built with one UI framework, another 3rd built with another, and so on. That fragmentation will hurt those of us happy to use the standard Meteor stack. Usually what happens in the evolution of the web is that clear winners emerge and we settle on them. And we do so for a purpose: it makes everyone’s lives easier not having to juggle competing technologies. It’s looking like React has shaped up to be that, or at least a close enough interface to the final protocol that it would be smart to be another company pushing it forward, rather than a company contributing to the fragmentation. There’s a lot to add to truly integrate React with Meteor, and it will be an ongoing endeavor via a barrage of mixins–so that’s why its important we focus our concerns on React. If we can just have the better Blaze, the Blaze 2.0 we really desired, and it just so happens to be with React, we should have it, and attain it quick. I think that’s what MDG has meant by their decisive focused decision. Angular and Blaze and Vue etc will be supported–since they still wanna attract outsiders from all walks of development–but the storyline for insiders, i.e. Meteor purists or whatever you wanna call us, should be that of one that contains one major supported view layer that is supported to the maximum, just like MDG has always done a superlative job supporting their core components in the past. If MDG had to pick one component system that they deeply integrate, it would be React. And clearly, for reasons stated here, they felt they had to pick one.

I think over time–especially as I see how easy it has been to integrate deep Tracker-based reactivity into React–we’ll see the other view layers catch up as well; and it might not be as big of a deal as everyone (me included) is making it out to be. In short, MDG’s conclusion over the summer to full out inter-opt with all major view frameworks may turn out to be spot on. If that prediction is correct, that means a year from now, meteor developers barely care about what view layer you’re using. Our talks here become more about other aspects of the stack. Think about it–once React Native bonafied wins the Native/Hybrid wars (it hasn’t yet, but is on its way to doing so), there will finally be no more conversation about all this view layer stuff anymore (unless it’s a conversation about Oculus Rift). I mean React Native seems to be so effective that Phonegap, Ionic’s Angular hybrid offering, etc, will be obsolete. Think about it–they already basically put Famous out of business! If that’s actually achieved–that’s a big deal. We’ve all been so hungry for that for so long. And think about it–that point is inevitable. I mean, whether its now or 20 years from now. There will be a time where that layer of the stack (the view layer) is no longer a problem, and now we’re on to problems in another part of the stack. So I really think that time is finally upon us. Give it one more year and who knows what we’ll be focused on–perhaps nailing the Relay/GraphQL style ORMs. It’s moved so quickly that hopefully in like January Meteor is using full Tracker-based reactivity within their enhanced React Components within a Native App–that’s as opposed to manually interfacing with DDP as you would have to now. Once that’s accomplished reliably, it’s a whole new ball game. I say we get there as quickly as possible before I gotta setup another client with Phonegap. Now you know what I’m workin on.

1 Like
15

Reactive Native? There is another.

Personally I like straight up Cordova for rapidly pushing prototypes and initial versions. Knowing a clear path to build native mobile versions using Javascript+Meteor as a next step from Cordova before diving into Java/Swift, is icing on the cake.

1 Like
16

I highly doubt there any “web designer” who likes or even understands Angular - if anything, Angular’s massive adoption mainly comes from the enterprise and IT consulting world. And I don’t really see many “web designers” among Vue users either.

Your “prediction” is based on speculations with no concrete data/evidence, so yeah, it’s a prediction, but not a particularly convincing one to me, and far, far away from being “the fact”. As I said, predictions without evidence is pointless.

I don’t mean to come off rude, but you probably want to think about how to better communicate with people. Write more concisely. Make fewer assumptions. And don’t tell people what they “should have said”, that is arrogant.

8 Likes
17

Listen I wouldn’t come off this way if what MDG is doing with Blaze/React wasnt so poorly executed, effecting us all in negative ways. You guys need to wake up, and if this is the only way it can be done… You do the math.

18

But the way you are communicating is really just serving you wrong, because it makes me want to avoid interactions with you, to be honest. Although I’ll try my best to read what you said and keep that in mind when I’m working on the React project.

5 Likes
19

Evan, brother man, we are all just programmers trying to make this better. We are having discussions about technology so the cream rises to the top, the best solutions. So I’m not upset with you. I’m not even upset with MDG. There’s just some opportunities here, and MDG seems to be skippin over them. So it’s just my imperative to make sure they see them. By principle. However it must be done. Especially since it’s a decision important to so many Meteor developers. So if you’re saying there’s an opportunity for you even still to hear me, great. It makes zero sense that both MDG and sideburns would be replicating some of the same work. My email is james@faceyspacey.com. If the plan is to actually work on something, we can throw out this nonsense out the window, and get to work.

As for “telling people what they should have said,” I wasn’t really telling any one person what they should have said. But sure, I’m telling MDG what they should have said. How they should be framing the React challenge, and how they should go about it. If I could ebb/influence an individual into the right direction to solve this, perhaps I would. If we were friends, and I knew you were assigned to it, and i understood the internals of how MDG works, perhaps I’d just quietly convince you on the side and share a few pertinent discoveries. But at this point, the cat’s out the bag and you have a 300 message thread of people clamoring based on some things that were said–essentially by a company–that could have been said better, and hopefully reflect a future that never happens. There’s no one to take it personally, except @gschmidt who’s likely busy with something even more important than this. But I do get that because this thread relates to Vue this is quite personal for you. Let’s just put it this way: I’ve been mentioning you for a week, and crickets. Perhaps if I heard a single response from you anywhere else it wouldn’t come to this. I’ve been providing all sorts of code samples that can help you. If you’re busy on another task, just triage me and let me know personally that as soon as you move to this stuff u’ll give me a shout. Things aren’t happening a vacuum. I know you gave a short response to a sideburns issue, but in the meteor forum thread, I’m sharing valuable things, yet you’re responding with the same party line to everyone else, and nothing to me. I got some good stuff to make Blaze 1 backwards compatible, and really wanna not see all my old code (and the rest of the Meteor Community’s old code) having to be manually upgraded. Can I share them with you sometime.

As for Angular though, I have to agree to disagree. My perspective is it’s not about whether it’s easier for web designers in actuality. My point is it looks easier at first, even if after you end diving deep on a project it becomes more complex than React. It’s all targeting/marketing in other words. Case in point is the old website:


Not an ounce of JS. The entire example appears like HTML.

So my hunch is that the attribute stuff appeals to junior web developers. I’m not talking actual designers that can’t code, but rather guys that just learned HTML/CSS/JQUERY and are in the process of leveling up. Which in actuality is likely many times more people than those that actually do level up and become full fledged programmers. There’s a lot of people at this skill level. Anything that resembles plain HTML is appealing to these people. These are all my assumptions in my model. Do you disagree with any of them?

As for the IT consulting, my guess is that’s an extension of this. First, what are we talkin about here? The big firms in india with hundreds of guys skilled in PHP/JOOMLA/JQUERY and now NODE/ANGULAR?? That’s likely an extension of the same stuff. I mean these developers are “go with the pack” developers. One of my junior developer’s girlfriends was made to learn Angular, and she just learned how to program this past year. Both of them are in Bangalore. What we are both saying seems to be correct. Also, Angular, because of it’s HTML focus, can be understood by other middle-managers. It’s for these reasons that–my guess is–that Angular had such a broad appeal.

However, serious independent and startup application developers all seem to be gravitating towards React. Can you really deny that based on the shear amount of React content permeating the web currently. Your point is “Predictions without evidence is pointless,” but it’s really difficult to get statistics and take polls. So for many things in our career (and lives) we do have to go by hunch and gut. That’s probably the case with the vast majority of things. So you’re right, this is what my gut is saying. And my hunch is it’s because React feels more like real programming than angular does. Vue took a similar approach, so I’m just indicating it as it’s major weakness. That said, I also admit it is a stupid weakness. It’s almost purely aesthetic-based. The system could operate flawlessly otherwise, better than the competition, but because of that, my guess is it isn’t taken as seriously as it could be from serious startup application developers. But like I said, that’s not even the largest market opportunity. I just think the end of the market that should guide the overall decision-making of the overall market. We really should take a poll, and in addition ask people what they consider their skill level. It would be interesting to see the results.

2 Likes
20

If React Native is the goal, I can get on board with that. However, that hasn’t been explicitly stated and would still abandon the patterns that people like me (meteor dev since 0.7) have been using.

I really feel for MDG with this. I can understand their position, but it seems like pandering more than anything. Of course, as I said, if truly “native” apps is the actual endgame, I love that.

1 Like