Where is the meteor love?

The name/concept “Meteor” seems to be overloaded and it’s meaning different thing for different people. I think there’re three concepts here:

  1. Meteor as a Full Stack: if you started before 2015 or follow the Blaze tutorial, then you’re using it and it comes with Blaze, mini-mongo, tracker, DDP, many Atmosphere package etc. This stack is a league on it’s own in terms of speed and simplicity of development, great for starting quickly because you’ve all the layers of a web app integrated, perfect for learning, prototyping and small to medium size production apps.

  2. Meteor as a Backend: if you started after 2015, switched blaze to other view layer and followed the guide with validated methods and minimal pub/sub usage, you’ll end up with this architecture. Here we’re using meteor build system and RPC methods powered with DDP but the client has been replaced with something like react, vue, angular, etc. If you don’t have complex API, integrating with only one client, and have few data sources and using mongo as a DB, yet you might change to something else in the future, then this is a great option to start with.

  3. Meteor as a Build Bool: this is the closet you get to plain node.js project and this is how Vulcan.js and other frameworks are being built on top of meteor, they use meteor to primarily package and compile their files and maybe the accounting system. Most of development effort by MDG over the last years has been (in my opinion rightly) placed here, along with Apollo. The data layer can be rest, but who will go back to rest after DDP, so most likely it’s GraphQL and probably Apollo.

The fact that we’ve these options today, and that you can start with one and evolve to another is why I think “Meteor” as platform/ecosystem is much better now. These are not mutually exclusive options and I think they should all be embraced by the community since they really serve different segment of the market.

With regards to vue, again I think it should get the same level of love as react/angular and we’re not too far off. Better vue support willl surely increase meteor’s adoption as a backend and a build too along with Apollo.

5 Likes

Hey @alawi,

I love your post, just have a beef with this for “Meteor as a Full Stack”:

We have a “large” production app and are still using Blaze. We haven’t faced issues yet, so the imperative to switch to Vue is not urgent (but remains important) as our focus is on adding new features and covering more use cases. But … we are not outsourcing our development (except for one project with @diaconutheodor) so are not suffering from lack of UI expertise (not to mention that it’s easy to pick up).

3 Likes

This is the main thing… At the end of the day, even vanilla node apps get stuck with something… vue vs angular vs react OR feather vs next vs express OR oauth vs passport vs firebase accounts vs whatever… if you use meteor + apollo, then really you can leave it pretty easily if you actually ever need to do that. You grab webpack and switch you accounts to something else… not fun but hardly not the end of the world.

Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.

3 Likes

Let’s be real, you are going to “need” to re-write your app in the new latest and greatest thing in a few years… it doesn’t matter what you choose.

Maybe the hope is, if your app’s tiers are properly abstracted and concerns isolated, then you can rewrite certain parts of your app without having to rewrite the entire thing. No?

4 Likes

@GeoffreyBooth 2 months later is the savior of CoffeeScript still trying to use Meteor with Vue? Using CoffeeScript perhaps? Last time I asked you how your debugged your meteor coffeescript code you answered using Chrome Dev Tool.

But I just can’t manage to have it let me put breakpoints where I want inside the <script lang=coffee> ... </script> section of my Vue components. Most line numbers in the CoffeeScript code are disabled and among the few that are abled most put the breakpoint at another line that the one I clicked on. sometimes in comments or blank lines, 10-15 lines away. This is profondly frustrating back to debug with console logs
:scream: :weary:

Do you think it is:

  • an akryum:vue-coffee meteor package problem?
  • a coffeescript meteor package problem?
  • a Chrome dev tool problem?

Do you have a solution for that?

I must say that the number of transpilers between the source code and the code executed in the browser is becoming overwhelming:

  • Coffee -> ES6
  • ES6 -> ES5
  • Vue component build
  • Meteor build

how many source maps are needed for all this stuff and how to properly coordinate their interaction?

I think it’s a akryum:vue-coffee problem. I think the bug is that .vue files usually have a structure like this:

<template>
  <!-- . . . say 20 lines of HTML here -->
</template>

<script lang="coffee">
# First line of CoffeeScript code, but line 25 of the .vue file

My hunch is that vue-coffee sends the CoffeeScript code through the transpilation pipeline without adjusting the sourcemaps for the fact that, in this example, the code starts at line 25 instead of line 1. That should be fairly easy to rectify, I just haven’t devoted the time to it. Please feel free to do so (and let me know if you do, so I don’t duplicate your effort).

My workaround has been to just throw debugger statements in my code:

<script lang="coffee">
import { mapState } from 'vuex'

export default
	name: 'some-component'

	data: ->
		debugger # Chrome DevTools WILL stop here

You need to remember to remove them later, but they’re full-fledged breakpoints, not the limited printing you get from console.log. The debugger statement is core JavaScript, and has nothing to do with Vue or transpilation.

1 Like

Solid point! I made this point in a post a while ago: that MDG was repositioning in the hope of getting acquired by Facebook, hence the official support of React, even when it seems obvious of Vue superiority.

1 Like

Your hunch seems correct. After I externalized the <script> part of my Vue component to a separate .coffee file I can now not correctly set the breakpoints inside of it in Chrome Dev Tools.

Do you stick to manual debugger statements anyway to be able to put the breakpoints at the correct level of nesting and hence block scoping in the CoffeeScript code which is not possible by just choosing a line number in an IDE for those single CoffeeScript lines that exit multiple block scopes through multiple outdents?

I don’t have a one-size-fits-all solution. If I have the code open in my editor, I’ll add a debugger statement. If in DevTools, I’ll set a breakpoint (if it lets me). I do whatever’s most convenient in the moment.

Are you going to patch vue-coffee?

Got it! Thanks!

Sorry but I am still waaaaayyyyy too closer to zero than to hero to try to fix any part of the quite overwhelming (to me) tech stack that I am currently still merely evaluating the viability/practicalilty:

  • Meteor + Astronomy + Vue-Meteor + Vue + Vue-Router + Vuex + Vue-SSR + Quasar + CoffeeScript + Pug + Stylus,
  • recent ES6 and CSS stuff to understand the docs and examples,
  • VSCode + Chrome Dev Tools to understand how to debug this whole enchilada,
  • Visual Studio Team Service + Git + Github to control versions and collaborate,
  • and I haven’t yet looked at the all important testing stuff (Mocha, Chai, Sinon, Chimp and God knows what else I will need to learn when I dive into it)
  • nor at cloud deployment (Galaxy? Node Chef?)
  • nor at mobile (Cordova) and desktop deployment (Electron)

:exploding_head:

There’s a hell of a lot of transpilation going on there!

4 Likes

Meteor is a very inclusive community :wink:

4 Likes

So now that Meteor is in some new leadership hands, we can probably start to spread the love again! I’ve been using @akryum’s packages :package: for Meteor + Vue and it is an amazing combination. Please sponsor @akryum on Github if you use these packages and love them as much as I do. Let’s bring the Meteor & Vue communities together.

8 Likes

I created skeleton files awhile back but don’t have time to contribute right now. Here’s a link if anyone wants to open an issue and add them to the latest Meteor version for a PR.

Thank you

Hi @johncochran92 and @mullojo , Since I wrote made those posts, I’ve come to understand Vue has it’s own way to doing reactivity which isn’t really compatible with Meteor. It’s like saying, “why can’t I drop a Tesla electric car engine into my Ford Mustang?” If Vue was a drop-in replacement for Handlebars, then we wouldn’t be having this conversation. Some have tried to get them working together, but it’s an ugly kludge of workarounds. I believe some of the issues are touched on here:

We were early adopters of Meteor (we were running our business on Meteor v0.6) back when you could host for free. But starting a couple years ago, we switched away from Meteor, in part because we wanted to work with Vue and GraphQL.

There are lots of choices when it comes to your stack these days. Meteor was great choice for us at that moment in time. It was cool, experimental, and ground-breaking. But the landscape has changed: we have Vue, GraphQL, and Gridsome. We have JAMstack architectures, sites pre-rendered during build and hosted on Netlify, we have tools like Prisma, and backends like Hasura and Faunadb.

Meteor is was it is. Sometimes you just can’t get your old girlfriend to change; and you have to move on and find someone else. :wink:

You can use Vue and Meteor as a backend, that tighter integration is for reactivity I believe. You can also use GraphQL with Meteor build system, many projects does. And finally you can run a JAMStack with Meteor API. Prisma looks interesting though.

1 Like

@maxhodges I’m curious, are you building a consumer or enterprise applications? and how many developers in your team?

I did a quick breakdown of the tech you mentioned for reference, thanks.

Client:

  • Vue: clients rendering engine
  • Gridsome: static site generates, (GatsbyJS for Vue), useful for blogs CMS
  • JAMstack: Architecture style where you’ve SPA clients hosted on a CDN connecting to a backend
  • Netlify: static hosting platform

Data Protocol:

  • GraphQL: Data query language protocol, independent of the tech stack

Backends:

  • Prisma: SQL ORM, generate API and CRUD from SQL databases (ORM)
  • Hasura: Create GraphQL API from Postgres DB (GraphQL ORM from Postgres database)
  • FaunaDB: Database as a backend (kind similar to Firebase with GraphQL API)

I everyone! I just wanted to express my personal joy in using Vue with Meteor since Dec. 2018. At that time, I decided to start building a new app with Meteor + Vue and I’ll be honest that I had some concerns due to FUD & scepticism out there, but I’m happy to report is was just FUD . At that time my experience with Meteor was building 1 Meteor (Blaze) app and I had enjoyed that combination (3 yrs ago). Vue alone is now hugely popular as a front-end framework in combination with many types of backends, but Vue devs have to eventually find a great backend to complete a full-stack. I also had no interest in any other database than MongoDB (I’ve used over 10 top databases as a Data Scientist & Dev). Obviously you need Node.js in a JS stack, but I could have built my own stack with websockets and lots of other re-coding of what already exists, or I could just use Meteor which comes with Node.js & MongoDB, and a secure accounts package.

So now about 1.5 years later, I’m very pleased with my choice. There were two very important packages authored by @akryum that made a full integration between Vue + Meteor a breeze 1) vue-component (on atmosphere to use Vue files natively) and 2) meteor-vue-tracker (on npm to have 100% reactivity with Meteor, for pub/sub heaven). I give $10 a month to @akryum via his Github sponsorship which gets you an invite to his private Discord Server. So big Thanks :pray: to @akryum :tada: These packages are featured in the Meteor + Vue guide and a new Meteor + Vue tutorial that is now up thanks to @brianmulhall. There are not many Vue + Meteor “evangelists” out there YET, so I guess I’m feeling that I should be one. To Vue users who have never tried Meteor as a backend, I say it is like Vue for the backend. For past Meteor users, I feel it completes the dream goals of what Meteor was wanting to achieve for simplicity, speed, & reactivity in new full-stack multi-user app development.

Also, I want to say thank you to @filipenevola because he has been easy to collaborate with in the Meteor Community and he has been super supportive of publicly supporting Vue + Meteor.

I’m willing to help people get started with & try this stack if you want to say hi on the new Meteor Slack Community. I’m on a new Meteor Community Discord too if you prefer that.

Here are a couple reminders:

  • Meteor is better than is has ever been with the 1.10 release (latest Node.js & MongoDB & Cordova)
  • MongoDB has improved a lot in the last 3 years, very powerful queries are possible today (& free starter Atlas hosting)
  • Vue brings joy developing the front-end, it’s simplicity + power speaks for itself
  • Galaxy is also a joy, and you get 1 month free now to try it out, and can host an app for $7 a month, this is a big improvement over the previous pricing for smaller apps (Galaxy has a big list of upgrades coming)
  • For new apps, we are going to add new Vue skeletons (like React has) to make it even easier to get started. Thanks @korg0001 for the pointer if you started this already.

We all are building different apps where today there is no one size fits all, but I’m hoping that more people realize the great combo with Vue + Meteor!

Just as a side note, since this came up in a couple responses, I think not everyone knows that Meteor has a new private corporate sponsor as of around fall 2019, Tiny Capital. Here is a post that kind of explains why Meteor’s MDG had to pivot to Apollo to create a different solutions for its investors, not beause Meteor itself was not a great idea. Twitter post by Tiny Capital’s Managing Partner Andrew Wilkinson. @johncochran92 there is no longer the MDG as a corporate entity, their $53 mil in VC funding was a pressure that got relieved with Tiny’s aquisition. So now there is support for integrations with all the best modern front-ends. I’m just trying to clear up OLD FUD. Happy developing everyone! :raised_hands::grinning:

Lastly a big thanks to @evanyou for creating Vue in the 1st place, working at the old Meteor (MDG) in the past to probably learn more of what not to do, and then creating something that is perhaps the best example of what open-source communities are capable of, much love man! :rocket:

17 Likes

Many thanks for the update on Tiny Capital. I had no idea although I am a Meteor devloper and read the meteor forum evey once in awhile.

2 Likes