9 ms·

Ask HN: Is Meteor.js still a thing?

146 points by tiri 9y ago

Should I use Meteor for production apps? If not, which Framework should I use for reactive realtime apps?

_mrmnmly 9y ago
For some time, I was amazed by Meteor.js developer-friendy approach and it's "magic" stuff. But after some time I've found that I had to do many hacks to achieve something and gave Express.js a shot - it was a purification experience for me - You have more control what framework do out of the box and You can avoid using hacks easily.
michaelrambeau 9y ago
About the first part of the question, Meteor is still a thing for several reasons: * It's a project with a strong community (364 contributors) that still has traction among developers (+ 8 stars by day on average over the last month, check the numbers here https://bestof.js.org/projects/meteor https://bestof.js.org/projects/meteor) * They keep moving in the right direction: moving away from their own package manager (https://atmospherejs.com/ https://atmospherejs.com/) to NPM, accepting ES6 syntax everywhere, client and server-side without config, enabling AngularJS or React for the front-end layer... Since Meteor 1.6 version, they use under the hood one of the latest versions of node.js. * Other contenders with such a combination "no config / real time / full-stack JS" features out of the box have less traction (check some contenders here https://bestof.js.org/tags/fullstack https://bestof.js.org/tags/fullstack) Some great projects on GitHub are built on top of Meteor: - https://rocket.chat/ https://rocket.chat/ a clone of Slack chat app - https://wekan.github.io/ https://wekan.github.io/ a clone of Trello app - http://vulcanjs.org/ http://vulcanjs.org/ "The full-stack React+GraphQL framework" The drawback is that the Meteor is quite opinionated about a lot of things, it's a monster of its own, blurring the boundary between client and server-side code. It can be difficult to debug, test, deploy and scale. So there is no definitive answer about the question "Should I use it in production?". The team behind Meteor is really committed to keep on moving forward, GraphQL and Apollo support are coming soon, the post about the latest release gives interesting insight about their vision: https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 The author said that, at the end of the process, "Meteor may look less like a framework and more like a library of middleware that can be used in any existing application, JavaScript or otherwise". One important thing is that they move forward steadily, without breaking things, which is important when you run applications in production.
felipellrocha 9y ago
No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
- mattacular 9y ago
  Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.
  - brlewis 9y ago
    I had steered clear of websockets a lot until recently. Turns out it's not a big deal. The API is easy in node. It's easy on the browser side too, and now widely supported. You only have to give up IE9 and Opera Mini.
- tiri 9y ago
  Thank you! Which backend framework should I use? I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?
  - albertgoeswoof 9y ago
    http://megaboilerplate.com http://megaboilerplate.com will get you set up fastest, with auth already in there. It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.
- vazamb 9y ago
  You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.
vazamb 9y ago
The team behind it released version 1.6 just a few days ago, so it is definitely still alive. I haven't used it since a few versions ago but I don't see we it wouldn't still solve the same use case as it did before: making it trivial to build real time collaborative web apps (that don't require extreme scale). With rethinkdb being an unsure bet and graphql not offering the same ease of development I am also not aware of a competing framework. Arguably meteor is getting better and better by integrating more with the broad node/Javascript community. This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.
egeozcan 9y ago
I don't know a better tool for prototyping but I found it too slow even with ~1000 clients and that is on a beefy server. If, by some magic, they switch to a more modular design (maybe they already did, not following closely) and that in some way enables the use of postgres (as a 1st class citizen), I'd give it another go for something more than a prototype. Here is my humble opinion: If you aren't writing business logic, and will do mostly network programming, try Go. If you are doing something enterprise-y, use Kotlin or (IMHO even better) .NET Core. If you want to like writing code, try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair with Python/Ruby).
- cies 9y ago
  > If you want to like writing code [then names dynamically typed languages] Huh? :)
  - egeozcan 9y ago
    That's why I explicitly stated that it's my personal opinion, although "comment" already means "a verbal or written remark expressing an opinion" :) I actually like JavaScript more than many typed languages but I don't like writing a server that runs on an event loop. Again, preference. ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a tease with a smiley at the end. Relax, people.
    - cies 9y ago
      > I tried to compensate by upvoting. Thanks.. > It is just a tease with a smiley at the end. Relax, people. Indeed, what's wrong with these people! :-P (I was a dynamic typer myself, but changed sides when learning about strong typing, especially in FP langugaes)
Blixs 9y ago
I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that caused a lot of scalability and maintainability problems in production. Its "make reactive all the things" model also gave (less experienced) developers a huge gun to shoot themselves in the foot with, causing a lot of performance issues. If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.
- icc97 9y ago
  You can use React as a front end for Meteor
  - a_humean 9y ago
    That wasn't at all their point.
    - icc97 9y ago
      Perhaps I misread, but I got the impression they were going from Meteor front and back to React + Python. All I'm saying is that if you'd done that you wouldn't have to throw out everything to get React.
- michaelsbradley 9y ago
  Any thoughts on RxDB? https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb
  - 9y ago
neoh 9y ago
It depends entirely on the budget really. Meteor is great for turning over applications quickly, but that's it. Ember is a better frontend full stack framework and if the server is to be built by someone else, go with Ember. If the budget is large, there's a good dev team and the project needs a performance kick then React is the better choice, if built right. We've been handed over React codebases though that needed saving and while the previous devs might have been fairly competent, React has a lot more work involved which can make people get lazy after a while and have the opposite effect of what it was intended for, and that's speed. For personal projects I will never go for React. I love the concept of React and how it works, but there's too much boilerplate and I personally prefer more full stack solutions.
- cies 9y ago
  > I personally prefer more full stack solutions. You might like Elm. If you also control the backend you may want to look into PostgREST (there's an Elm lib for it iirc). See also `elm-mtl`.
squid3 9y ago
If you want to look at it from popularity angle, we continue to see many meteor deployments on https://nodechef.com/meteorhosting https://nodechef.com/meteorhosting suggesting it's still a popular choice out there.
- maxsavin 9y ago
  More details please :)
kimjongman 9y ago
We migrated on of our customer app from Meteor to Vue and Rails. By doing this, the app is much more easier to scale. They are happy with the result. It's is easier to find developer for Rails and Vue.js
- forgot-my-pw 9y ago
  The author of Vuejs used to work for Meteor and he proposed them to officially integrate Vue as the front end layer. They didn't like the idea.
neximo64 9y ago
It used to be, now I find it quite bloated and slow. There was a time a save diff would be instant and startup was also just as quick. Now even to run 'meteor shell' and meteor mongo in an admin environment spits out instructions which are unnecessary and bloated. I could really go on.. Also, they used to have focus in 'blaze' which served a good purpose and then they reverted to a generic model where you use React (which needs all sorts of plugins to be reactive). It used to have direction and was very well thought out.
maxsavin 9y ago
Lol - a thread like this seems to pop up every couple of months. They are updating it like all the time with new features. The biggest problem with it is that the data layer does not scale well for large apps, and that has tainted the reputation of Meteor as a whole. However, there are community packages on the way to fix it, and hopefully Meteor will implement MongoDB's new Change Streams feature, which essentially puts the reactivity on to the database. I'm still holding my bet on Meteor, having recently launched an admin panel tool for it: http://meteorcandy.com http://meteorcandy.com
goloroden 9y ago
Spoiler: I am one of the authors of a competitor product (wolkenkit), so my answer won't be perfectly objective. IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart of Meteor is modeling your data, and it basically builds upon a CRUD approach. This is perfectly fine for very simple use cases, but it doesn't work well for more complex things, because limiting yourself to create, read, update and delete limits your expressive power dramatically. In contrast, when we designed and developed wolkenkit, we put the verbs into the center of the development process. With wolkenkit, you model processes that describe what your application does. This way, wolkenkit is a pretty good fit if you do domain-driven design (DDD), but you do not need to do DDD to use wolkenkit. wolkenkit gives you the option to focus on your domain expertise, and provides all the technical stuff below, such as persistence, authentication, real-time updates, and so on… We built it based upon CQRS and event-sourcing, so you have a pretty good foundation for scaling and reporting / analyzing data. As it's only for the backend, you are free to use any UI framework you want to use, but we have a client-side SDK for JavaScript to assist you. You can find more information at https://www.wolkenkit.io/ https://www.wolkenkit.io/ and in its documentation https://docs.wolkenkit.io/1.1.0/ https://docs.wolkenkit.io/1.1.0/ If you just want to get started with the concepts, have a look at our 68-pages brochure on DDD, CQRS, event-sourcing and wolkenkit: https://docs.wolkenkit.io/1.1.0/downloads/brochure/ https://docs.wolkenkit.io/1.1.0/downloads/brochure/ wolkenkit is available as open-source and under a commercial license. If you have any questions, feel free to contact us. PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS, event-sourcing & co., but once you get it, I think it is a pretty good approach to developing software.
- maxsavin 9y ago
  I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.
  - goloroden 9y ago
    I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.
deleted 9y ago
[deleted]
troika 9y ago
I've switched to https://deepstream.io https://deepstream.io for my projects. It's just the realtime aspect of meteor, but in an entirely different league when it comes to performance
- rfrey 9y ago
  "switched to"? Aren't you the CTO of Deepstream?
  - VeejayRampay 9y ago
    Looking at troika's submissions, there's one "Show HN" about Deepstream so yeah, definitely involved in the project. Don't understand why one would say "I've switched to" for an application they've created or contributed to, especially if there's proof in your history that you have marbles in the game.
    - rfrey 9y ago
      He also posted the who's hiring entries. Regardless, deepstream seems pretty awesome.
andrew_wc_brown 9y ago
I really wanted to buy into Meteor. It felt like the second coming of Rails. I just couldn't get onboard with something I couldn't plug SQL into. A psql adapter never came.
- petre 9y ago
  I wonder if you can run it over ToroDB.
  - xet7 9y ago
    Yes, it's possible to have Wekan Meteor.js <=> MongoDB <=> ToroDB => PosgreSQL or MySQL read-only mirroring, for reporting etc if needed https://github.com/wekan/wekan-postgresql https://github.com/wekan/wekan-postgresql https://github.com/torodb/stampede/issues/203 https://github.com/torodb/stampede/issues/203
ordinaryperson 9y ago
So much hate for Meteor here, but I use it at work and it's been great for what we wanted. I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days. Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordova, so you can easily port your website to mobile apps. It supports importing of node packages. Is Meteor the answer for everything? Of course not. But for a fast, data-driven app it's still great, IMHO. The alternatives recommended in this thread so far are: 1. Firebase + React/Angular 2. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY 3. Deepstream.io 4. Kotlin 5. .NET Core 6. Vue and Rails If those things work for you, great, but I'm not sure they're 10x better than Meteor or that MDG is in some kind of death spiral -- it's still a viable solution for fast NodeJS apps.
- deleted 9y ago
  [deleted]
- throwanem 9y ago
  > Is Meteor the answer for everything? Of course not. It sure does claim to be.
  - stvrbbns 9y ago
    And poptarts claim(ed) to be part of a "complete breakfast"... - https://www.youtube.com/watch?v=_nqhoP_ychc https://www.youtube.com/watch?v=_nqhoP_ychc Promotion/marketing speak is promotion/marketing speak.
    - throwanem 9y ago
      At least Pop Tarts throw in "part of a". Meteor wants to be your entire stack, to such an extent that I'm honestly a little surprised they don't ship their own editor.
icc97 9y ago
Yes, built a React front end on meteor a few months ago. Well documented, excellent tutorial. They worked well together.
kabes 9y ago
Contrary to many here, I feel over the last year they made themselves totally relevant again. And I think that the negative reactions here are from people that aren't fully aware of the current state of the project. Note that Meteor is much more than a data layer. Even though you won't find any easier system to deal with reactive data than their livequery system, I get that you don't want to be bound to Mongo or even need reactivity. But it's also a server and build tool that has given our application: - A stable upgrade path for almost 4 years where we could keep up with new ES features incrementally, with full backwards compatibility. In Javascript-framework land this is really unique. We've been able to keep adding features, expanding our product and building for our customers. While at the same time continuously update our codebase to the latest and greatest. - By far the best easiest way to do code splitting (since 1.5) without any configuration or overlap in bundles. I don't know about any other tool that offers something similar. Webpack doesn't even come close in this area. - Because they had node-fibers to get synchronous code from the start, now it's really easy to adopt to async/await. - They have good integrations for React, Angular 1 & 2, Blaze and there are third-party integrations for Vue (haven't used that one myself) - They're also the same people behind Apollo which people do seem to like for their data layer. And they announced Meteor will focus on full Apollo integration. But yeah, their current data layer requires you to buy in to Mongo. And yes, there's no good separation of concerns in their data layer. And yes, the oplog tailing can't handle "facebook-scale" and I know you believe you need this. But picking this allowed our application (that needs a reactive data layer) to be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I would have ended up 2 years later with a nicer codebase and no customers. TL;DR Have a look at their latest release (1.6), build a small application and chances are you might really like it.
- flippyhead 9y ago
  We've been building an large, complex application on Meteor for the past year and most definitely agree with this assessment. We've also found Galaxy to be incredibly easy.
- albertTJames 9y ago
  I agree with this assessment. But meteor's main problem is being able to interface with providers that are not Galaxy, at least they dont have good documentation on it and you have to rely on blog posts. Plus galaxy is at least twice as expensive as aws for small projects.
virgil_disgr4ce 9y ago
As a product designer and entrepreneur, Meteor is still absolutely a thing. The products I've built simply wouldn't exist without the massive (development) speed boost it gave me. I'm well aware of its problems and faults, but I love it for the amount of work I don't have to do.
whois 9y ago
Yes! The company I work for uses it for most of its user facing apps. No matter what poeple say about Meteor, the fact remains that having the ability to live push data to the frontend, and share code between client and server, with absolutely no extra work is supper appealing.
mariopt 9y ago
Meteor developer for a long time here. Meteor, today, is still a good match for small to medium applications that provide real-time features in more than 50% components/pages. For most applications Meteor becomes a real pain in the ass. I wrote several applications for multiple clients, in 4 years I haven't wrote a single one that used the real-time features properly. A tradicional stack is simply much more flexible when compared to Meteor. The problem today is that Meteor is not a component that you can't easily plug and play like Angular, React, Express, etc. Example: You would like provided a real-time widget on another website? Open an iframe and load the entire application and waste more than 300 megabytes on the browser. Or use a non-official package and hack the shit out of it. MDG (Company who developed and maintains Meteor) went too greedy. In order to use Meteor you have to be fully committed to the stack. Although the project is open source, you will waste several hours trying to modify Meteor to be make it more modular. Event today if you want to use the DDP protocol outside of Meteor, you've to use 3rd party non official packages. Meteor was great in the beginning but failed to play nicely with the rest of the JS ecosystem even although some work was done in that direction. Arunoda played a HUGE role by building and writing a lot. As a prototype tool Meteor is excellent, it's very hard to find a framework/tool that provides what Meteor provides. Building a real-time application with modular components isn't trivial, Meteor just offers a lot for free: LiveQuery, Authentication, Server-Client shared code, Consistent API, client side implementation of MongoDB (minimongo), painless build system, easy deployment, etc. You can build a prototype in record time. Play with Meteor, you won't regret it. Scaling applications is always hard, requires in depth knowledge and time. Meteor is websocket based, there is not need to compare with an HTTP based API since it is unfair. Scaling a real-time application is hard on any language/framework. For most projects FireBase will do the trick if you've a small number of real-time components. My advice: Pick the right tool for the right job. Most of the complains typically come from project that are not a decent match for real-time applications. I worked on many project because someone decided to use Meteor regardless of their technical knowledge to decide so.
- _mrmnmly 9y ago
  +1 from me for mentioning Arunoda. He has done a lot to Meteor.js (and many others) community.
- 9y ago
rishav_sharan 9y ago
For me its mithril (frontend) + micro (server) + Hasura (BaaS)
clement75009 9y ago
I've used Meteor a lot over the last 4 years. Recently I had to start a new project and I wanted to move away from Meteor because clearly it has less traction lately. I've considered a lot of things, but I couldn't find a setup as simple as Meteor with database integration. I ended up going back to Meteor and I'm very happy with it. The tooling keeps getting better (recent 1.6 release), server-side rendering is almost there (already possible but no clear best practices yet), and scaling seems like it will be getting better soon (MongoDB upade + a path toward GraphQL with Apollo). I had my doubts but I'm back on board. I recommend every JS developer give Meteor a good look.
sergiotapia 9y ago
Reposting my comment because it's going to help you: Meteor projects are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug. Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly. On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure. I say this as someone who has used Meteor for multiple projects and used to love it!
- alonisser 9y ago
  "Testing is still a third-class citizen" The exact reason meteor is disqualified for me. Even the basic manual is broken and wrong in some ways. Internet searches point to frameworks which are broken or obselete and to the meteor testing site (If I recall correctly even docs point to it) which has a notification for a long time about being "rewritten" and no actual content (and would be a paid book .. :( ) If testing is a third class citizen then No real professional software development can take place with it. A real deal breaker
DerWOK 9y ago
If you look at some quite active meteor open source repos with a non-trivial size, you may also see that meteor is still alive and kicking. ;-) * WeKan - FOSS Trello clone https://github.com/wekan/wekan https://github.com/wekan/wekan * Rocket.Chat - FOSS Slack clone https://github.com/RocketChat/Rocket.Chat https://github.com/RocketChat/Rocket.Chat * Vulcan - React, GraphQL & Meteor toolkit https://github.com/vulcanjs/vulcan https://github.com/vulcanjs/vulcan * 4Minitz - FOSS Collaborative Meeting Minutes and Protocols WebApp https://github.com/4minitz/4minitz https://github.com/4minitz/4minitz & https://www.4minitz.com/ https://www.4minitz.com/ Disclaimer: I'm one of the contributors of 4Minitz. ;-)
- M4v3R 9y ago
  Thumbs up for Rocket.Chat, love it!
  - jadbox 9y ago
    How does Rocket compare with Mattermost these days?
    - M4v3R 9y ago
      I didn't use Mattermost, but probably the biggest advantage of Rocket.Chat is that it is totally free to use. On the other hand the UI is sometimes not as polished as other commercial solutions.
M4v3R 9y ago
I am using Meteor in my work on a daily basis, and still love it! On the frontend I use Vuejs instead of Blaze, though.
- thsowers 9y ago
  Late to the party here, but could you comment on your experience with Meteor-Vue? I just ported an app from Viewmodel back to traditional blaze, but really want to rebuild the frontend in Vue for performance. What do you use for forms and other items that have packages in the blaze ecosystem?
j6m8 9y ago
We used Meteor for a long time as our primary stack at my current company. We just finalized the switch to React/Webpack + AWS Lambda/DynamoDB this week. The main motivator was that Meteor's big sell — the "zero-latency" data sync — wasn't enough to outweigh the overhead of having to keep up with the constantly shifting landscape of which libraries were now deprecated, which were suddenly "anti-patterns", which were suddenly insecure... That being said, I still prototype all new projects with Meteor. It's by far the fastest to go from 0 to 60, and it's extremely pleasant to ignore data transit and focus on the Big Ideas. tldr; Prototype things in Meteor because it's a great platform. Your production stack may or may not need the same things your prototype stack needs.
je42 9y ago
Lot's of people mentioning "reactivity as being expensive/non-scalable". is there a good read up on what reactivity in the context of meteor.js is and why it is expensive ?
- mxxx 9y ago
  TLDR is: - Meteor uses MongoDB as a data store - You write queries on the server called "publications", that make documents available to the client - The client implements "MiniMongo", which basically lets you query the documents that have been published via your publications using Mongo queries as if you were writing them straight from the server - The publications are (by default) reactive, so whenever any of the documents in your queries is added/removed/modified, the changes propagate instantly to your client. - The original view library (Blaze) would seamlessly update with these changes in your UI. From memory, the performance bottlenecks here are: - It uses the Mongo OpLog to determine when changes have been made to the collections, which makes the queries themselves quite slow. - For every dataset published to the client, Mongo keeps a cache of that dataset on the server so it knows when it needs to send deltas over the wire. So for both of these reasons, once your queries get big, they get SLOW. The other thing that is costly (but not fundamentally a fault of Meteor itself), is that most people building web apps model their data in relational terms. If you try and apply that to Mongo, (ie, treating collections as tables and "joining" across them instead of nesting data hierarchically inside your documents), you'll end up writing slow queries.
kharms 9y ago
What's the best framework for a personal/learning project? My only recent .js experience has been with d3.js.
- brlewis 9y ago
  Mithril is light but still batteries-included (routing, fetching). See my essay: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
- Jonovono 9y ago
  Go React. Great community. Learn ReactJS and now you can use the knowledge to build native apps with React native.
d0m 9y ago
From my experience (a.k.a tried and failed..), I'd rather take a bit more time to glue a few amazing open-source tools together than to use an "all-in-one" framework that will screw me down the road. Over the years, I've built the equivalent of those real-time systems using postgres, redis, rabbitmq and node that can scale horizontally. It's obviously longer than using firebase, but at least I know what's going on under the hood, I can easily optimize and debug it, I can add any missing features or switch any tools (I.e. can easily switch off postgres to something else if I needed it). It's for the same reasons that I use React on the front-end. It's great for the view layer, but I still get to pick and use great libraries for the rest of the app (in-memory database, state management, routing, etc etc.) I can easily switch off React to something else because the surface API that I'm using is extremely small. I would still use meteor or any of the competitors for a hackathon or prototype, but never for a long-term project. YMMV
Can_Not 9y ago
I missed the opportunity to use meteor, but these days the big appeal of meteor (minus one opininated framework) is that I can get the same experience with VueJS/React and Feathersjs
mariushop 9y ago
I would say yes. I used it for over 10 projects over the years and haven't found something more compelling in the JS ecosystem in terms of speed, database integration, easy of use. Reactivity should be off by default, that's right. Last thing I build has a React front (it's a text editor for medium-long form writing) and I'm super happy with the data layer on Meteor.
sova 9y ago
After a couple years of research, my next project will be incarnated from the following DNA: ▪Clojure backend ▪Clojurescript frontend page ▪Rum (react cljs lib)
markoshust 9y ago
I've had great success with Meteor. I started with v1.2, and it was quite painful to develop in. However, with improvements start within 1.3 and onward, every release has gotten better. Meteor 1.6 has the same concepts as Meteor 1.0, however it is extremely different and is up to date with standards of the Node/JS ecosystem. I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box. In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues. I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer. You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time. My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.
api 9y ago
Few things on the web are still a thing a year later. That's why I favor a thinner less complex stack.
ikatalan 9y ago
Do not touch this platform. it caused us so much problems and didnt seem to solve any real issue. each new project we start without it is a bliss. you dont need it and the voodoo bugs it will create. you can just use react+node js. works great together and will be lot easier to solve platform issues when they come
mxxx 9y ago
I've been working on Meteor apps for a few years now, and my TLDR answer for you is, no, don't use it. The releases since 1.3 have definitely pushed it in the right direction: * NPM instead of atmosphere * React/Vue/whatever instead of Blaze * ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order * ESNext support * Getting Node and NPM up to current LTS versions Next stop on their roadmap is integrating Apollo, at which point it'll basically be a turnkey system for building React/Vue apps on top of GraphQL. Most of what originally made Meteor what it was will have been removed in place of sensible best practices that everybody else in the JS world has since moved on to. But for me the sticking point is that Meteor is built on a couple of assumptions that, in my humble opinion, are fundamentally incorrect. 1. Focusing on writing code that runs on both the server and the client is a useful idea. 2. MiniMongo is a sensible way to handle the data layer and reactivity everywhere is helpful. I personally reckon these are both crappy ideas, and combined with the "magic" parts of the framework, they encourage people who are new to full stack JS to develop bad habits and skip learning some of the real fundamentals that every developer should know in relation to security, performance and scalability.
deleted 9y ago
[deleted]

146 points by tiri 9y ago

Should I use Meteor for production apps? If not, which Framework should I use for reactive realtime apps?

For some time, I was amazed by Meteor.js developer-friendy approach and it's "magic" stuff. But after some time I've found that I had to do many hacks to achieve something and gave Express.js a shot - it was a purification experience for me - You have more control what framework do out of the box and You can avoid using hacks easily.

michaelrambeau 9y ago

About the first part of the question, Meteor is still a thing for several reasons: * It's a project with a strong community (364 contributors) that still has traction among developers (+ 8 stars by day on average over the last month, check the numbers here https://bestof.js.org/projects/meteor https://bestof.js.org/projects/meteor) * They keep moving in the right direction: moving away from their own package manager (https://atmospherejs.com/ https://atmospherejs.com/) to NPM, accepting ES6 syntax everywhere, client and server-side without config, enabling AngularJS or React for the front-end layer... Since Meteor 1.6 version, they use under the hood one of the latest versions of node.js. * Other contenders with such a combination "no config / real time / full-stack JS" features out of the box have less traction (check some contenders here https://bestof.js.org/tags/fullstack https://bestof.js.org/tags/fullstack) Some great projects on GitHub are built on top of Meteor: - https://rocket.chat/ https://rocket.chat/ a clone of Slack chat app - https://wekan.github.io/ https://wekan.github.io/ a clone of Trello app - http://vulcanjs.org/ http://vulcanjs.org/ "The full-stack React+GraphQL framework" The drawback is that the Meteor is quite opinionated about a lot of things, it's a monster of its own, blurring the boundary between client and server-side code. It can be difficult to debug, test, deploy and scale. So there is no definitive answer about the question "Should I use it in production?". The team behind Meteor is really committed to keep on moving forward, GraphQL and Apollo support are coming soon, the post about the latest release gives interesting insight about their vision: https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 The author said that, at the end of the process, "Meteor may look less like a framework and more like a library of middleware that can be used in any existing application, JavaScript or otherwise". One important thing is that they move forward steadily, without breaking things, which is important when you run applications in production.

felipellrocha 9y ago

No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.

mattacular 9y ago
Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.
- brlewis 9y ago
  I had steered clear of websockets a lot until recently. Turns out it's not a big deal. The API is easy in node. It's easy on the browser side too, and now widely supported. You only have to give up IE9 and Opera Mini.
tiri 9y ago
Thank you! Which backend framework should I use? I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?
- albertgoeswoof 9y ago
  http://megaboilerplate.com http://megaboilerplate.com will get you set up fastest, with auth already in there. It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.
vazamb 9y ago
You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.

vazamb 9y ago

The team behind it released version 1.6 just a few days ago, so it is definitely still alive. I haven't used it since a few versions ago but I don't see we it wouldn't still solve the same use case as it did before: making it trivial to build real time collaborative web apps (that don't require extreme scale). With rethinkdb being an unsure bet and graphql not offering the same ease of development I am also not aware of a competing framework. Arguably meteor is getting better and better by integrating more with the broad node/Javascript community. This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.

egeozcan 9y ago

I don't know a better tool for prototyping but I found it too slow even with ~1000 clients and that is on a beefy server. If, by some magic, they switch to a more modular design (maybe they already did, not following closely) and that in some way enables the use of postgres (as a 1st class citizen), I'd give it another go for something more than a prototype. Here is my humble opinion: If you aren't writing business logic, and will do mostly network programming, try Go. If you are doing something enterprise-y, use Kotlin or (IMHO even better) .NET Core. If you want to like writing code, try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair with Python/Ruby).

cies 9y ago
> If you want to like writing code [then names dynamically typed languages] Huh? :)
- egeozcan 9y ago
  That's why I explicitly stated that it's my personal opinion, although "comment" already means "a verbal or written remark expressing an opinion" :) I actually like JavaScript more than many typed languages but I don't like writing a server that runs on an event loop. Again, preference. ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a tease with a smiley at the end. Relax, people.
  - cies 9y ago
    > I tried to compensate by upvoting. Thanks.. > It is just a tease with a smiley at the end. Relax, people. Indeed, what's wrong with these people! :-P (I was a dynamic typer myself, but changed sides when learning about strong typing, especially in FP langugaes)

Blixs 9y ago

I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that caused a lot of scalability and maintainability problems in production. Its "make reactive all the things" model also gave (less experienced) developers a huge gun to shoot themselves in the foot with, causing a lot of performance issues. If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.

icc97 9y ago
You can use React as a front end for Meteor
- a_humean 9y ago
  That wasn't at all their point.
  - icc97 9y ago
    Perhaps I misread, but I got the impression they were going from Meteor front and back to React + Python. All I'm saying is that if you'd done that you wouldn't have to throw out everything to get React.
michaelsbradley 9y ago
Any thoughts on RxDB? https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb
- 9y ago

neoh 9y ago

It depends entirely on the budget really. Meteor is great for turning over applications quickly, but that's it. Ember is a better frontend full stack framework and if the server is to be built by someone else, go with Ember. If the budget is large, there's a good dev team and the project needs a performance kick then React is the better choice, if built right. We've been handed over React codebases though that needed saving and while the previous devs might have been fairly competent, React has a lot more work involved which can make people get lazy after a while and have the opposite effect of what it was intended for, and that's speed. For personal projects I will never go for React. I love the concept of React and how it works, but there's too much boilerplate and I personally prefer more full stack solutions.

cies 9y ago
> I personally prefer more full stack solutions. You might like Elm. If you also control the backend you may want to look into PostgREST (there's an Elm lib for it iirc). See also `elm-mtl`.

squid3 9y ago

If you want to look at it from popularity angle, we continue to see many meteor deployments on https://nodechef.com/meteorhosting https://nodechef.com/meteorhosting suggesting it's still a popular choice out there.

maxsavin 9y ago
More details please :)

kimjongman 9y ago

We migrated on of our customer app from Meteor to Vue and Rails. By doing this, the app is much more easier to scale. They are happy with the result. It's is easier to find developer for Rails and Vue.js

forgot-my-pw 9y ago
The author of Vuejs used to work for Meteor and he proposed them to officially integrate Vue as the front end layer. They didn't like the idea.

neximo64 9y ago

It used to be, now I find it quite bloated and slow. There was a time a save diff would be instant and startup was also just as quick. Now even to run 'meteor shell' and meteor mongo in an admin environment spits out instructions which are unnecessary and bloated. I could really go on.. Also, they used to have focus in 'blaze' which served a good purpose and then they reverted to a generic model where you use React (which needs all sorts of plugins to be reactive). It used to have direction and was very well thought out.

maxsavin 9y ago

Lol - a thread like this seems to pop up every couple of months. They are updating it like all the time with new features. The biggest problem with it is that the data layer does not scale well for large apps, and that has tainted the reputation of Meteor as a whole. However, there are community packages on the way to fix it, and hopefully Meteor will implement MongoDB's new Change Streams feature, which essentially puts the reactivity on to the database. I'm still holding my bet on Meteor, having recently launched an admin panel tool for it: http://meteorcandy.com http://meteorcandy.com

goloroden 9y ago

Spoiler: I am one of the authors of a competitor product (wolkenkit), so my answer won't be perfectly objective. IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart of Meteor is modeling your data, and it basically builds upon a CRUD approach. This is perfectly fine for very simple use cases, but it doesn't work well for more complex things, because limiting yourself to create, read, update and delete limits your expressive power dramatically. In contrast, when we designed and developed wolkenkit, we put the verbs into the center of the development process. With wolkenkit, you model processes that describe what your application does. This way, wolkenkit is a pretty good fit if you do domain-driven design (DDD), but you do not need to do DDD to use wolkenkit. wolkenkit gives you the option to focus on your domain expertise, and provides all the technical stuff below, such as persistence, authentication, real-time updates, and so on… We built it based upon CQRS and event-sourcing, so you have a pretty good foundation for scaling and reporting / analyzing data. As it's only for the backend, you are free to use any UI framework you want to use, but we have a client-side SDK for JavaScript to assist you. You can find more information at https://www.wolkenkit.io/ https://www.wolkenkit.io/ and in its documentation https://docs.wolkenkit.io/1.1.0/ https://docs.wolkenkit.io/1.1.0/ If you just want to get started with the concepts, have a look at our 68-pages brochure on DDD, CQRS, event-sourcing and wolkenkit: https://docs.wolkenkit.io/1.1.0/downloads/brochure/ https://docs.wolkenkit.io/1.1.0/downloads/brochure/ wolkenkit is available as open-source and under a commercial license. If you have any questions, feel free to contact us. PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS, event-sourcing & co., but once you get it, I think it is a pretty good approach to developing software.

maxsavin 9y ago
I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.
- goloroden 9y ago
  I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

deleted 9y ago

[deleted]

troika 9y ago

I've switched to https://deepstream.io https://deepstream.io for my projects. It's just the realtime aspect of meteor, but in an entirely different league when it comes to performance

rfrey 9y ago
"switched to"? Aren't you the CTO of Deepstream?
- VeejayRampay 9y ago
  Looking at troika's submissions, there's one "Show HN" about Deepstream so yeah, definitely involved in the project. Don't understand why one would say "I've switched to" for an application they've created or contributed to, especially if there's proof in your history that you have marbles in the game.
  - rfrey 9y ago
    He also posted the who's hiring entries. Regardless, deepstream seems pretty awesome.

andrew_wc_brown 9y ago

I really wanted to buy into Meteor. It felt like the second coming of Rails. I just couldn't get onboard with something I couldn't plug SQL into. A psql adapter never came.

petre 9y ago
I wonder if you can run it over ToroDB.
- xet7 9y ago
  Yes, it's possible to have Wekan Meteor.js <=> MongoDB <=> ToroDB => PosgreSQL or MySQL read-only mirroring, for reporting etc if needed https://github.com/wekan/wekan-postgresql https://github.com/wekan/wekan-postgresql https://github.com/torodb/stampede/issues/203 https://github.com/torodb/stampede/issues/203

ordinaryperson 9y ago

So much hate for Meteor here, but I use it at work and it's been great for what we wanted. I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days. Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordova, so you can easily port your website to mobile apps. It supports importing of node packages. Is Meteor the answer for everything? Of course not. But for a fast, data-driven app it's still great, IMHO. The alternatives recommended in this thread so far are: 1. Firebase + React/Angular 2. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY 3. Deepstream.io 4. Kotlin 5. .NET Core 6. Vue and Rails If those things work for you, great, but I'm not sure they're 10x better than Meteor or that MDG is in some kind of death spiral -- it's still a viable solution for fast NodeJS apps.

deleted 9y ago
[deleted]
throwanem 9y ago
> Is Meteor the answer for everything? Of course not. It sure does claim to be.
- stvrbbns 9y ago
  And poptarts claim(ed) to be part of a "complete breakfast"... - https://www.youtube.com/watch?v=_nqhoP_ychc https://www.youtube.com/watch?v=_nqhoP_ychc Promotion/marketing speak is promotion/marketing speak.
  - throwanem 9y ago
    At least Pop Tarts throw in "part of a". Meteor wants to be your entire stack, to such an extent that I'm honestly a little surprised they don't ship their own editor.

icc97 9y ago

Yes, built a React front end on meteor a few months ago. Well documented, excellent tutorial. They worked well together.

kabes 9y ago

Contrary to many here, I feel over the last year they made themselves totally relevant again. And I think that the negative reactions here are from people that aren't fully aware of the current state of the project. Note that Meteor is much more than a data layer. Even though you won't find any easier system to deal with reactive data than their livequery system, I get that you don't want to be bound to Mongo or even need reactivity. But it's also a server and build tool that has given our application: - A stable upgrade path for almost 4 years where we could keep up with new ES features incrementally, with full backwards compatibility. In Javascript-framework land this is really unique. We've been able to keep adding features, expanding our product and building for our customers. While at the same time continuously update our codebase to the latest and greatest. - By far the best easiest way to do code splitting (since 1.5) without any configuration or overlap in bundles. I don't know about any other tool that offers something similar. Webpack doesn't even come close in this area. - Because they had node-fibers to get synchronous code from the start, now it's really easy to adopt to async/await. - They have good integrations for React, Angular 1 & 2, Blaze and there are third-party integrations for Vue (haven't used that one myself) - They're also the same people behind Apollo which people do seem to like for their data layer. And they announced Meteor will focus on full Apollo integration. But yeah, their current data layer requires you to buy in to Mongo. And yes, there's no good separation of concerns in their data layer. And yes, the oplog tailing can't handle "facebook-scale" and I know you believe you need this. But picking this allowed our application (that needs a reactive data layer) to be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I would have ended up 2 years later with a nicer codebase and no customers. TL;DR Have a look at their latest release (1.6), build a small application and chances are you might really like it.

flippyhead 9y ago
We've been building an large, complex application on Meteor for the past year and most definitely agree with this assessment. We've also found Galaxy to be incredibly easy.
albertTJames 9y ago
I agree with this assessment. But meteor's main problem is being able to interface with providers that are not Galaxy, at least they dont have good documentation on it and you have to rely on blog posts. Plus galaxy is at least twice as expensive as aws for small projects.

virgil_disgr4ce 9y ago

As a product designer and entrepreneur, Meteor is still absolutely a thing. The products I've built simply wouldn't exist without the massive (development) speed boost it gave me. I'm well aware of its problems and faults, but I love it for the amount of work I don't have to do.

whois 9y ago

Yes! The company I work for uses it for most of its user facing apps. No matter what poeple say about Meteor, the fact remains that having the ability to live push data to the frontend, and share code between client and server, with absolutely no extra work is supper appealing.

mariopt 9y ago

Meteor developer for a long time here. Meteor, today, is still a good match for small to medium applications that provide real-time features in more than 50% components/pages. For most applications Meteor becomes a real pain in the ass. I wrote several applications for multiple clients, in 4 years I haven't wrote a single one that used the real-time features properly. A tradicional stack is simply much more flexible when compared to Meteor. The problem today is that Meteor is not a component that you can't easily plug and play like Angular, React, Express, etc. Example: You would like provided a real-time widget on another website? Open an iframe and load the entire application and waste more than 300 megabytes on the browser. Or use a non-official package and hack the shit out of it. MDG (Company who developed and maintains Meteor) went too greedy. In order to use Meteor you have to be fully committed to the stack. Although the project is open source, you will waste several hours trying to modify Meteor to be make it more modular. Event today if you want to use the DDP protocol outside of Meteor, you've to use 3rd party non official packages. Meteor was great in the beginning but failed to play nicely with the rest of the JS ecosystem even although some work was done in that direction. Arunoda played a HUGE role by building and writing a lot. As a prototype tool Meteor is excellent, it's very hard to find a framework/tool that provides what Meteor provides. Building a real-time application with modular components isn't trivial, Meteor just offers a lot for free: LiveQuery, Authentication, Server-Client shared code, Consistent API, client side implementation of MongoDB (minimongo), painless build system, easy deployment, etc. You can build a prototype in record time. Play with Meteor, you won't regret it. Scaling applications is always hard, requires in depth knowledge and time. Meteor is websocket based, there is not need to compare with an HTTP based API since it is unfair. Scaling a real-time application is hard on any language/framework. For most projects FireBase will do the trick if you've a small number of real-time components. My advice: Pick the right tool for the right job. Most of the complains typically come from project that are not a decent match for real-time applications. I worked on many project because someone decided to use Meteor regardless of their technical knowledge to decide so.

_mrmnmly 9y ago
+1 from me for mentioning Arunoda. He has done a lot to Meteor.js (and many others) community.
9y ago

rishav_sharan 9y ago

For me its mithril (frontend) + micro (server) + Hasura (BaaS)

clement75009 9y ago

I've used Meteor a lot over the last 4 years. Recently I had to start a new project and I wanted to move away from Meteor because clearly it has less traction lately. I've considered a lot of things, but I couldn't find a setup as simple as Meteor with database integration. I ended up going back to Meteor and I'm very happy with it. The tooling keeps getting better (recent 1.6 release), server-side rendering is almost there (already possible but no clear best practices yet), and scaling seems like it will be getting better soon (MongoDB upade + a path toward GraphQL with Apollo). I had my doubts but I'm back on board. I recommend every JS developer give Meteor a good look.

sergiotapia 9y ago

Reposting my comment because it's going to help you: Meteor projects are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug. Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly. On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure. I say this as someone who has used Meteor for multiple projects and used to love it!

alonisser 9y ago
"Testing is still a third-class citizen" The exact reason meteor is disqualified for me. Even the basic manual is broken and wrong in some ways. Internet searches point to frameworks which are broken or obselete and to the meteor testing site (If I recall correctly even docs point to it) which has a notification for a long time about being "rewritten" and no actual content (and would be a paid book .. :( ) If testing is a third class citizen then No real professional software development can take place with it. A real deal breaker

DerWOK 9y ago

If you look at some quite active meteor open source repos with a non-trivial size, you may also see that meteor is still alive and kicking. ;-) * WeKan - FOSS Trello clone https://github.com/wekan/wekan https://github.com/wekan/wekan * Rocket.Chat - FOSS Slack clone https://github.com/RocketChat/Rocket.Chat https://github.com/RocketChat/Rocket.Chat * Vulcan - React, GraphQL & Meteor toolkit https://github.com/vulcanjs/vulcan https://github.com/vulcanjs/vulcan * 4Minitz - FOSS Collaborative Meeting Minutes and Protocols WebApp https://github.com/4minitz/4minitz https://github.com/4minitz/4minitz & https://www.4minitz.com/ https://www.4minitz.com/ Disclaimer: I'm one of the contributors of 4Minitz. ;-)

M4v3R 9y ago
Thumbs up for Rocket.Chat, love it!
- jadbox 9y ago
  How does Rocket compare with Mattermost these days?
  - M4v3R 9y ago
    I didn't use Mattermost, but probably the biggest advantage of Rocket.Chat is that it is totally free to use. On the other hand the UI is sometimes not as polished as other commercial solutions.

M4v3R 9y ago

I am using Meteor in my work on a daily basis, and still love it! On the frontend I use Vuejs instead of Blaze, though.

thsowers 9y ago
Late to the party here, but could you comment on your experience with Meteor-Vue? I just ported an app from Viewmodel back to traditional blaze, but really want to rebuild the frontend in Vue for performance. What do you use for forms and other items that have packages in the blaze ecosystem?

j6m8 9y ago

We used Meteor for a long time as our primary stack at my current company. We just finalized the switch to React/Webpack + AWS Lambda/DynamoDB this week. The main motivator was that Meteor's big sell — the "zero-latency" data sync — wasn't enough to outweigh the overhead of having to keep up with the constantly shifting landscape of which libraries were now deprecated, which were suddenly "anti-patterns", which were suddenly insecure... That being said, I still prototype all new projects with Meteor. It's by far the fastest to go from 0 to 60, and it's extremely pleasant to ignore data transit and focus on the Big Ideas. tldr; Prototype things in Meteor because it's a great platform. Your production stack may or may not need the same things your prototype stack needs.

je42 9y ago

Lot's of people mentioning "reactivity as being expensive/non-scalable". is there a good read up on what reactivity in the context of meteor.js is and why it is expensive ?

mxxx 9y ago
TLDR is: - Meteor uses MongoDB as a data store - You write queries on the server called "publications", that make documents available to the client - The client implements "MiniMongo", which basically lets you query the documents that have been published via your publications using Mongo queries as if you were writing them straight from the server - The publications are (by default) reactive, so whenever any of the documents in your queries is added/removed/modified, the changes propagate instantly to your client. - The original view library (Blaze) would seamlessly update with these changes in your UI. From memory, the performance bottlenecks here are: - It uses the Mongo OpLog to determine when changes have been made to the collections, which makes the queries themselves quite slow. - For every dataset published to the client, Mongo keeps a cache of that dataset on the server so it knows when it needs to send deltas over the wire. So for both of these reasons, once your queries get big, they get SLOW. The other thing that is costly (but not fundamentally a fault of Meteor itself), is that most people building web apps model their data in relational terms. If you try and apply that to Mongo, (ie, treating collections as tables and "joining" across them instead of nesting data hierarchically inside your documents), you'll end up writing slow queries.

kharms 9y ago

What's the best framework for a personal/learning project? My only recent .js experience has been with d3.js.

brlewis 9y ago
Mithril is light but still batteries-included (routing, fetching). See my essay: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
Jonovono 9y ago
Go React. Great community. Learn ReactJS and now you can use the knowledge to build native apps with React native.

d0m 9y ago

From my experience (a.k.a tried and failed..), I'd rather take a bit more time to glue a few amazing open-source tools together than to use an "all-in-one" framework that will screw me down the road. Over the years, I've built the equivalent of those real-time systems using postgres, redis, rabbitmq and node that can scale horizontally. It's obviously longer than using firebase, but at least I know what's going on under the hood, I can easily optimize and debug it, I can add any missing features or switch any tools (I.e. can easily switch off postgres to something else if I needed it). It's for the same reasons that I use React on the front-end. It's great for the view layer, but I still get to pick and use great libraries for the rest of the app (in-memory database, state management, routing, etc etc.) I can easily switch off React to something else because the surface API that I'm using is extremely small. I would still use meteor or any of the competitors for a hackathon or prototype, but never for a long-term project. YMMV

Can_Not 9y ago

I missed the opportunity to use meteor, but these days the big appeal of meteor (minus one opininated framework) is that I can get the same experience with VueJS/React and Feathersjs

mariushop 9y ago

I would say yes. I used it for over 10 projects over the years and haven't found something more compelling in the JS ecosystem in terms of speed, database integration, easy of use. Reactivity should be off by default, that's right. Last thing I build has a React front (it's a text editor for medium-long form writing) and I'm super happy with the data layer on Meteor.

sova 9y ago

After a couple years of research, my next project will be incarnated from the following DNA: ▪Clojure backend ▪Clojurescript frontend page ▪Rum (react cljs lib)

markoshust 9y ago

I've had great success with Meteor. I started with v1.2, and it was quite painful to develop in. However, with improvements start within 1.3 and onward, every release has gotten better. Meteor 1.6 has the same concepts as Meteor 1.0, however it is extremely different and is up to date with standards of the Node/JS ecosystem. I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box. In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues. I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer. You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time. My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.

api 9y ago

Few things on the web are still a thing a year later. That's why I favor a thinner less complex stack.

ikatalan 9y ago

Do not touch this platform. it caused us so much problems and didnt seem to solve any real issue. each new project we start without it is a bliss. you dont need it and the voodoo bugs it will create. you can just use react+node js. works great together and will be lot easier to solve platform issues when they come

mxxx 9y ago

I've been working on Meteor apps for a few years now, and my TLDR answer for you is, no, don't use it. The releases since 1.3 have definitely pushed it in the right direction: * NPM instead of atmosphere * React/Vue/whatever instead of Blaze * ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order * ESNext support * Getting Node and NPM up to current LTS versions Next stop on their roadmap is integrating Apollo, at which point it'll basically be a turnkey system for building React/Vue apps on top of GraphQL. Most of what originally made Meteor what it was will have been removed in place of sensible best practices that everybody else in the JS world has since moved on to. But for me the sticking point is that Meteor is built on a couple of assumptions that, in my humble opinion, are fundamentally incorrect. 1. Focusing on writing code that runs on both the server and the client is a useful idea. 2. MiniMongo is a sensible way to handle the data layer and reactivity everywhere is helpful. I personally reckon these are both crappy ideas, and combined with the "magic" parts of the framework, they encourage people who are new to full stack JS to develop bad habits and skip learning some of the real fundamentals that every developer should know in relation to security, performance and scalability.

deleted 9y ago

[deleted]