I've switched to 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
"switched to"? Aren't you the CTO of Deepstream?
Ask HN: Is Meteor.js still a thing?
41–50 of 107 posts
Re: Ask HN: Is Meteor.js still a thing?
#42As 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.
Re: Ask HN: Is Meteor.js still a thing?
#43Yes! 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.
Re: Ask HN: Is Meteor.js still a thing?
#44Contrary 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…
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.
Re: Ask HN: Is Meteor.js still a thing?
#45Meteor 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.
Re: Ask HN: Is Meteor.js still a thing?
#46For me its mithril (frontend) + micro (server) + Hasura (BaaS)
Re: Ask HN: Is Meteor.js still a thing?
#47I 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.
I wonder if you can run it over ToroDB.
Re: Ask HN: Is Meteor.js still a thing?
#48Spoiler: 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…
I’ve read through your pdf docs explaining wolkenkits approach to CQRS.
I think most of the value you’re describing through correctly modeling behavior to language is only important at the level with which most teams deal with data—and this isn’t necessarily the DB level. Just like our brain may use (relatively crude) bio mechanical processes to encode & recall information, yet at a higher level of abstraction relies on the flexibility of natural language, to codify and transmit meaning between idea storage systems (people), I think a similar process is at place with programming. Let the low level stuff stay low level and optimize for performance/throughout and not meaning, then in the higher order aspects of code make sure the abstractions that are most used by teams map data to constructs which humans use to communicate meaning.
I think this approach can be found in any framework, including meteor through effective abstractions, as nearly all frameworks give you the necessary mechanisms to map data. I think the issue with ineffective language systems is mostly the same reason people hate poetry. Most people have a difficult time adequately mapping ideas to language, because it is extremely difficult to do it correctly to the satisfaction of others.
Re: Ask HN: Is Meteor.js still a thing?
#49I'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.
Re: Ask HN: Is Meteor.js still a thing?
#50Reposting 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!