Really nice to see, hard to beat that landing page, best backend framework ever!
We also need a tutorial, guide section and a blog post going to officially welcome the vue folks 
2 Likes
Correct! 
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:
ecmascript
meteor
standard-minifier-css
standard-minifier-js
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:
export const main = () => {
console.log('Build complete.');
return 'DAEMON';
};
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!
9 Likes
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. 
3 Likes
Maybe you have article about this experience? (((-:
I sometimes think about create-react-app + apollo-server-express as an alternative to MeteorJS…
1 Like
Just a question the initial post - how does somebody come up with comparing a php framework to a js framework? (Anyone can explain that to me?)
I mean personally I think a dev project that requires to write a backend in php is to me like going down to the hell of programming (o.O)"
This experience is why I finally found a js fullstack framework that works out of the box and why I am still here.
3 Likes
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.
5 Likes
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
and an earlier version of the talk from Sept 2017
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.
1 Like
@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.
2 Likes
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.
1 Like
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.
1 Like
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).
1 Like
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.
4 Likes
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!
2 Likes
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.
2 Likes
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
By officially endorsing it I specifically mean:
- update the site (which they did)
- 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
2 Likes
Oh yeah in that case I totally agree. My point was that they would never adopt Vue the same way Blaze was built-in way back.
4 Likes
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.