If I didn't use Meteor, what would I use?

1

This is simply a question born out of curiosity. I have been playing with Meteor for some months now and I have enjoyed creating an application. I haven’t created any SPA’s before this, so, if people didn’t use Meteor, what would they use (for me, this would be for an SPA that had some reactive components in it, but not all of it needing to be reactive)?

2

I would love to explore http://www.phoenixframework.org/ if I had the time

1 Like
3

Probably a plain ol’ node stack like Meatier :laughing:

2 Likes
4

It would be good to hear about non-framework based approaches, e.g. React + API + Aurelia.

5

Before I started with meteor I was building a stack called DoxDB which is basically a MongoDB that runs on a JPA supported database on a JEE7 platform. I had stalled it for now, but the result would’ve been similar to Meteor in a way (I had created most of the plumbing including callbacks to the client via WebSockets with Angular1 as Angular2 wasn’t really mature enough for me when I started it).

In addition, I had the export/import capability partially done so data can be exported into MIME files that can be processed by some other tool to say anonymize production data and then use it as imports to the database elsewhere.

The primary target for the stack was for larger enterprises that have large investments in the operations of JEE application servers and RDBMS databases.

6

I would probably use http://www.phoenixframework.org/ as @dbx834 said above. If I was trying to avoid frameworks though I would probably use golang. It has a great standard library, highly concurrent, scalable, and easy to write.

7

My new projects I am making in feathers.js. As implied by the name, it is a nimble framework (core framework code is only a few hundred lines of code), but provides a lightweight ‘service’ fabric that makes it dead simple to create a REST or realtime websockets interface. Your ‘service’ is generally some database table/collection connected through one of many supported ORM’s. Use feathers with any frontend you want, it doesn’t care. Use feathers with SQL or NoSQL databases; it also doesn’t care there.

The tradeoff here is there is a little bit more boilerplate than a Meteor app. It provides identical realtime functionality, but you have to choose your build tools, etc. whereas with Meteor you get that out of the box. However, if there’s anything you need to subclass or extend for a particular use case in your app, I have found it extremely easy to work with.

It really depends on your needs. Having some working knowledge of what your app’s MVP features are should guide you to the right path. Neither is ‘right’; only more or less useful for a particular set of use cases. I have found that as I build software, I like to use nimble frameworks that can be adapted as I adapt to an ever-evolving set of requirements.

Edit, here is my tech stack moving forward:

  • Presentation Layer
    • React
    • React Router
    • Redux
    • Material-ui
    • redux-form
  • Application Layer
    • NodeJS v5.5.0
    • ES6/7
    • Webpack
    • React (Server Side Rendering)
    • Feathers.js (aka a lightweight wrapper for):
      • Express.js
      • Sequelize
      • JsonWebToken (JWT’s) for Stateless Authentication
      • Socket.io for realtime feeds
  • Data Layer
    • MariaDB
    • AWS S3
    • Redis (for horizontal scaling websockets)
8

Tears. That’s what you would use. You would be using tears of regret.

13 Likes