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
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.