Poll: Which Frontend Framework do you use? (2017 Edition)

  • AngularJS
  • Angular2 (>2)
  • Blaze
  • Ember
  • Polymer
  • React
  • VueJS

0 voters

Which framework do you use and why? Are you happy with it? Would be great to have an updated statistic and small discussion here.

3 Likes

React, since it is only a view layer it fits well with Meteor and best my needs.

1 Like

Currently migrating everything step by step from Blaze to React. All new features are React only.

5 Likes

Using Blaze, and migrating everything to Vue

5 Likes

I’m also thinking about migrating my blaze project to something more modern. I’m not sure if I should choose vue or react. It seems to me that react is supported better by meteor. Does ssr and code splitting work with an vue frontend?

How has your experience with the Vue integration been? I’m hesitant to try because it says “beta” and isn’t official, but would love to move from Blaze to something better (and with less boilerplate than react) for production use

We are using Vue in a new project, so no Blaze at all on this new codebase. In our current app with Blaze, we keep using Blaze, but we will stop few weeks in the near future and migrate to Vue, Bootstrap 4 (which currently is 3) and maybe Apollo.

So I don’t have the experience of using both in the same codebase.

But the learning curve has been ok, and to be honest, after you start using Vue with Vuex, Blaze starts to fell dated.

React. Because:

  • Huge community
  • Backed by Facebook
  • JSX
  • Excellent documentation and tutorials out there
  • Incredible performance with React 16
6 Likes

Vue. Because:

  • Huge community
  • No Facebook :stuck_out_tongue:
  • Single file components with easy to learn template language, or JSX if you want
  • Excellent documentation and tutorials out there
  • Usually faster than React

@mscherer82
Meteor’s code splitting works with Vue. Vue supports SSR and @akryum has made a vue-meteor-ssr package though I haven’t tried it.

14 Likes

Blaze all day:

  • fast to develop
  • very flexible
  • great minimongo integration
  • doesn’t lay opinions over html/css/js
  • working with dynamic imports is easy
26 Likes

Vue has really stolen my heart. I don’t use many of Meteor’s front-end features like optimistic UI, mini mongo, ReactiveVars, etc. I like Meteor for it’s publications, accounts system, build system, and RPC system (mdg:validated-method). For state management and reactive data I use Vue’s existing systems instead.

I use React at my day job and really like its tool set and component system, but any opportunity I get I use Vue instead. The long list of core libraries all work together to create a really easy to understand API that’s easy to explain to new people and enables me to build features much faster than I could with React or Blaze.

2 Likes

Currently using Blaze. I have a project I built with Blaze that I’m trying to finish. May look into building a new project with Vue afterwards since I started learning Vue recently.

Yeah I think you’re best off not using ReactiveVars/Dicts with Vue, to keep as much as possible in Vue’s reactivity system instead of Tracker. Minimongo and optimistic UI still works great with Vue though! Using a package like Akryum’s vue-meteor-tracker or my grapher-vue as a bridge.

I haven’t found much use for Vuex though actually, doesn’t really seem necessary when you have live subscriptions + local component state.

1 Like

For the most part I don’t use any of Meteor’s optimistic UI because I like to have more control over it via Vuex’s mutations and state. I personally tend to prefer building the user experience of having a loading animation when something’s happening, instead of optimistically changing the UI to pretend it worked when we don’t really know if it did yet. That way the user really knows what’s going on

Each time I call a Meteor method I’ll dispatch a mutation called something like GET_USERS_START, which updates the state.getUsersLoading=true, and in my component if getUsersLoading==true then I display a loading spinner. Then when the request is done I’ll dispatch a mutation GET_USERS_COMPLETE or GET_USERS_FAILURE which will set store.users or store.getUsersError, and my component will render something differently depending on which of those values is set. It’s more boilerplate, but you get more control over the application’s behavior.

Good to know MiniMongo will still work well. Thanks for mentioning that.

Using Blaze for RadGrad (http://radgrad.org). In no big hurry to switch. It’s really easy to bring new developers up to speed with Blaze.

1 Like

We are using Vue in a new project, so no Blaze at all on this new codebase.

I’m not opposed to doing a complete rewrite in Blaze. Quick question, what (if any) package are you using for forms? Wondering if there is something comparable to Autoform. In any case, thanks so much for sharing your experience with me!


To everyone choosing Blaze going forward: I agree that it’s a wonderful framework for building things quickly, but once things get complex and performance really matters it’s a tough sell. Mitar wrote some benchmarks here: https://github.com/mitar/meteor-web-rendering-framework-benchmark

100% React, but only via https://viewmodel.org/react which makes it much simpler!

2 Likes

Using Blaze and sticking with it for the foreseeable future because we already have a large code-base that uses it.
Also because that code-base is a bit spaghetti and it would be difficult to transition without stopping all feature development for a while…

1 Like

We will probably do the same in the near future. Any tips or insights you can share?