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.
It was even worse. At the time Geoff wrote this, they didnât even have a proper React support layer in Meteor. So they dropped Blaze before being able to offer something good in exchange. This in fact caused a lot of unnecessary confusion and fractions in the community. Guess this is why Geoff became quite silent in these forums afterwards (probably on advice by his VCs).
None of the more successful technologies mentioned in this thread (Vue, Laravel, etc.) try to do as much as Meteor did when it first launched. We can see that once MDG refocused their effort on a smaller scope with Apollo (and even arguably with the ânewâ Meteor-as-a-build-tool approach) theyâve been very successful.
Ironically, thanks in large part to MDGâs efforts with Apollo I think Meteorâs original vision has now become viable, since all the pieces are there to be put together. Itâs a shame that MDG doesnât seem interested in taking on that challenge anymore, but at the same time itâs quite understandable.
Agreed, they were aiming very big and aggressive initially, which partly why Meteor was sitting at the top of the backend systems. Theyâve also managed to pivot and co-evolve meteor with the node.js ecosystem while maintaining backward compatibility which is truly an engineering achievement, much smaller js libraries canât pass a year without a major rewrite.
My only criticism is the way they managed the community expectations in 2015 and not pushing on-boarding the vuejs community today in 2018, both criticism are really not technical, Iâm really happy how meteor is evolving technically. Itâs just PR, marketing and community management.
Also the community and the public sometimes overreact emotionally and jump quickly in conclusions, we saw that in 2015. So let us help them to get vue officially endorsed!
Been gone from the community for about an year or so. Instead of complaining, I learnt React Native+Apollo+Express. Also converted a meteor app to see the experience first hand. The experience was flawless. After doing that I realised what sashko said a long time back in a thread: for a little bit of more code, you get back tons of more control with apollo. there were other big players like josh owens who predicted the future of meteor as a build tool long back. But that ainât too bad either. Meteor with Apollo almost looks like a normal express app.
Iâve looked at Apollo and didnât really feel the need for small to medium size apps, the method RPC approach works just fine for many apps, not everyone is looking for tons of control and a year worth of learning, some folks just want to get started quickly.
This is never going to happen for two reasons: first MDG uses React internally; and also their entire strategy is positioning Meteor as a front-end-agnostic build tool. If youâre looking for a full-stack all-in-one solution then youâre welcome to check out Vulcan (vulcanjs.org) instead
update the guide (weâve an open issue that encourage contribution)
add a tutorial (just like react/angular)
add example to the meteor CLI
write a blog and some do some PR work within the vue community
I think this can happen, they are using react and theyâve listed angular, so why not vue? and yes I do get that they want meteor the built tool to be front-end-agnostic, Iâm just saying we need to give the vue community the same level of support angular/react has, I think itâs a total (and relatively easy) win for meteor/galaxy/apollo. Iâd go further and state that itâs a win for the entire node ecosystem instead of having devs go back to php.
By the way I really love Vulcan! itâs great work, thank you so much for the effort on it and sharing it with us
Never say never; and how truly âfront-end agnosticâ is Meteor when there is official support for React but not Vue when they are nearly equally popular? Thatâs like saying the strategy of my [English] post here is to be language agnostic.
