Meteor competes more with LAMP / WebPack and doesn’t compete at all with vue.js. You can just use vue.js now, without any extra effort above what it takes to use Blaze or React.
On Meteor vs. WebPack - I’ve used both, and I prefer Meteor. It’s so much easier to both setup and to keep it working. I just update, and go. To me, that’s the value. And we get things you can’t get at all with other packages - perfect code splitting, the coming dual bundles system. It’s pretty great in Meteor these days.
I’m really not clear what is working and what is missing from the vue integration, I guess because I don’t use it. I’m hearing conflicting messages, on one hand I see people using it and creating starter kit and on the other hand we’ve this open issue that seems to be stuck.
That’s for a specific type of vue.js integration (and looks like it was rejected because it dug too deeply into vue.js internals). You don’t need that at all to use Vue.js from npm. Just install vue.js, and get started.
I think that this issue only relates to Tracker integration, required to use Blaze and Vue together. Without Blaze, the work that Akryum has done is sufficient.
Right, that issue is realted to “first-class” – drop-in replacement of Blaze – the kind of integration you’d expect in the Meteor community. Right now you can use Vue of course, but there’s going to be edge case issues, bumps in the road so to speak IMO. YRMV, so good luck.
Do we actually need that “first-class” integration? is this even desirable?
In our react project we minimized the use of tracker or any other meteor specific libraries because we want our view to be portable and we want to stick wth the rest of the ecosystem, so perhaps this also make sense for the vue integration. Perhaps we can leave concepts like tracker to Blaze (which I still love and use), and keep the integration thin and pure as @vooteles suggested. It’s really hard to beat meteor/blaze speed and simplicity of development, all you need is basic html, css and JS knowledge and you got to go! it’s really a league on it’s own. These view layers are targeting more complex apps and designed to work with rest, apollo or other data layers so why’re we expecting the meteor/blaze paradigm from this integration?
Furthermore, if you observe the work being done to Meteor last two years, you can clearly notice the focus toward positioning Meteor as a build system with loosely coupled modules, take a look at the minimal flag coming in 1.6.2, it doesn’t even have tracker. Thus having a tight/highly coupled integration to the view doesn’t seem aligned with the overall direction.
I still think Meteor should list vue as potential integration just like what we’ve with react and angular, I mean we don’t have an official tracker integration with those view layers either.
Do I understand correctly that if I create a “minimal” app and run my own socket.io server that there shouldn’t be any performance problems, because the Meteor Server itself won’t be running?
Had that problem recently when trying to port the lance pong game onto Meteor.
Core Meteor devs can keep me honest here, but it seems they’ve removed DDP package with the minimal flag as well, so I think you’ll have the HTTP server but no socket connection opened by default, and if my understanding is correct yeah it should be similar to any other node backend in terms of performance.
I’ve been using another slight variation of this, to use Meteor as a build tool only (ie. instead of webpack). After creating a new app, change the .meteor/packages list to:
Then to work around Meteor’s required exported single main() function (that webapp provides), you can use a small local build-tool package with just one file:
Now after firing the Meteor Tool up, it just builds (babels, bundles, minifies, runs any build plugins, etc.) and dumps everything in the apps .meteor/local/build directory. I then have a single build /server/main.js control file, that moves the built JS files to where I need them.
As an example, I’m using this approach to develop a frontend React based framework, that integrates with Wordpress. So all of the React development is done as you would expect with the Meteor Tool, and the resulting files are injected into the desired Wordpress instances.
It works amazingly well, and is just another testament to Meteor’s flexibility!
After being gone from this community for a year or so I can say the crying doesn’t stop lol. Cmon what do you want just import your JS view layer of choice and get on with it.
I’m using Meteor + Vue, and I have to say, it’s been a pretty bumpy ride. You can search the vue-meteor repo for the issues and pull requests opened by me to see what I’ve gone through. The vue-meteor packages aren’t written very safely; a lot of the “integration” of hooking .vue files into Meteor’s build system involves doing find-and-replace on your code, for example replacing import and export statements using regex, and beware if your particular syntax is slightly different from what the vue-meteor package is expecting. There’s also just a mountain of open issues, and unreviewed pull requests that fix major bugs, like this one.
So by all means let’s get some good docs written in the guide, but the vue-meteor packages themselves can use some help. They may be small in terms of lines of code, but they need some careful code review and improvement. A review by someone in MDG would be especially good, to ensure not just that the code is using JavaScript best practices but also that it’s using Meteor best practices, by calling the correct APIs and integrating in the best ways. I agree with @hwillson that MDG is better positioned than we are to know what MDG’s priorities should be, but devoting some developer resources into polishing the vue-meteor packages and adding “official” support for them seems to me like a fairly low effort, high reward proposition. Perhaps someone could even convince/pay Evan to spend some time on it, as he would be the idea person who knows both platforms intimately.
I hate criticizing open-source packages that people have devoted lots of time into creating for my benefit, so @akryum and the others involved in vue-meteor please don’t take this post the wrong way! I’m very grateful for the vue-meteor packages and indebted to all your work, and we wouldn’t be using Vue with Meteor if not for these packages. But since these packages seem to be the current de facto standard for using Vue with Meteor, and since it seems that imperfect Vue integration with Meteor is a factor holding back Meteor’s own success, I think improving these packages should be a priority for the community.
You can always use Vue without Meteor. That’s the direction we are moving. Here are slides from Guillaume Chau’s (@Akryum) talk which I attended at Vue Conference in Amsterdam last week
But they are failing if many developers feel Vue delivers a more awesome developer experience than Handlebars templates and React. That Vue was the most starred repo in 2017 and Laravael’s popularity certainly seems to support this argument. I’ve talked to a lot of React and Angular devs who moved to Vue and say they would never go back. So far never heard of a dev who preferred switching from Vue to React. (Of course, this is just anecdotal, and subject to confirmation bias, but it might not be wrong)
it’s hard to know what MDG’s priorities are. Andreessen Horowitz may have invested simply because improving the quality of frameworks available to startups improves the whole startup industy–which increases the value of A16Z holdings across the board.
We’ll never know how many others (like my team) are rebuilding our Meteor apps in Vue + Graphcool or some other non-Meteor stack.
Factually, we know MDG’s income comes from consulting (you can buy developer support), selling dubious “partner” listing, and Galaxy hosting. None of us really know how well any of that is working out, but we do know that haven’t invested much in the way of new features for Galaxy years after launching i.e. if they only added two API endpoints–one to monitor resources; and, another to create new containers–then we’d have all we need to implement auto-scaling.
With their focus on React and GraphQL maybe they are just hoping their team and tech will be acquired by Facebook. Andreessen, the major backer of Meteor, is on the board at Facebook. This has been speculated about for years http://joshowens.me/facebook-to-acquire-meteor/
We can speculate all we like, but their business strategy is essentially a black box.
@maxhodges for my perspective, and I by no means a MDG insider, their development strategy pertaining to Meteor is pretty clear. They wanted the community to handle the view integrations so they can focus on the core tech, data layer and build system and I’m really happy they’ve focused their effort at what they’re uniquely positioned to do. And their business strategy is also clear from their product/service, they have said clearly that the lack of official support for view layers is due to resources constraints. Although to your point, I think their executives used to communicate more in the past (and sometimes it didn’t work very well like what happened in 2015). Frankly all the left over tasks can be done by the vue/meteor community and MDG has shown it’s willingness to support and endorse this effort.
We need to update the guide, write tutorial and add an example project, that can be done by the community, there are already open issues on that.
@GeoffreyBooth that is expected, I don’t use this integration since I’m a react user but I’ve already listed a task item for MDG to support closing any major open issues so I really think those bumps can be ironed out.
I personally think it was / is a great idea to invest time into GraphQL as it’s a technology that holds a lot of potential. The apollo libraries are delighful to use and some of them even expand beyond the “typical” capabilities of what people think GraphQL can do.
Agreed, but then again the right tool for the right job.
Some projects don’t really need a very flexible end point and RPC methods is simpler to reason about and implement. But for more complex projects, I think GraphQL is superior to rest in many ways.
