Comment by dvt | Hacker News Reader

Comment by dvt | Hacker News Reader

100% agree with this post. I also co-authored a book about Meteor[1] and, to me, it's really the "framework that got away." Modern React/Redux/JSX/Next/etc. completely sucks compared to how awesome and seamless Meteor felt when it first came out. Surprised you didn't mention anything about RPCs. Having methods that can run on either the front end or the back end with basically zero boilerplate was an incredible idea which unfortunately never really got traction. A few comments:

I think that HTML over the wire is still pretty context-specific. There's even modern cases where I think it makes sense to just render whatever blob you get over the wire.

I don't think that "Database Everywhere" deserves a thumbs down. It's an insanely useful prototyping tool, genuinely useful when trying to replicate reactivity, not to mention extremely performant for all that work it actually did (it sort of "hacked" this by hooking into Mongo's oplog). Meteor's mistake was, imo, mainly deciding to do this with MongoDB instead of a SQL variant.

I think I'd probably give "Embrace the Ecosystem" a shrug. The modern-day "Ecosystem" is a mess. To start a project, you need tsc, but wait not that version of tsc, and you also need React, but now you need Webpack. And also a CSS plugin, but also a SASS plugin. Oh, an SVG plugin too. But now you have a conflict. Have fun. I actually prefered using Meteor's more limited ecosystem where everything just worked out of the box.

Also no mention of CoffeeScript (which was heavily pushed); that deserves at least two thumbs down.

Anyway, I miss Meteor :)

[1] https://www.oreilly.com/library/view/introducing-meteor/9781...

Agree with all your points, think it's a bit subjective, but yeah... I loved how if I wanted to install my meteor project on a new machine it was just a couple of commands and everything including the database was ready to go. Contrast to these days, where you have 15 microservices, a dozen docker containers, ten million npm packages... :)

Basically it was a huge trade off: a 100% batteries included product that worked very well together because it was all made by the same people, Vs. the npm "bring your own whatever and wire it all up" approach. There are big pros and cons to both.

I think the comparisons to Rails are interesting, but actually not entirely fair either. Rails will always be primarily a back-end framework, no matter how much stuff is bolted on to its highly opinionated (of course) front-end toolchain.

Meteor was full-stack from the ground-up. In fact, Meteor was just "stack".

Meteor RPCs look cool, I've only started to see this elsewhere in frameworks like Solid.js. Was Meteor the first web framework to do this kind of seamless backend calls from the frontend?

It was certainly the first big framework to do it. The phrase at the time was "isomorphic javascript" - i.e. javascript that could run the same on server and client.

While today I might re-use _some_ code, like helpers or TypeScript types for API responses, by and large I feel like that dream is unrealized and probably a never great dream in the first place. In practice there just weren't a ton of wins from doing so, as there were not many cases where you needed the same code in frontend and backend.

This is not at all what RPCs were. And plenty of frameworks use "isomorphic javascript" (i.e. Javascript on both the front-end and the backend) -- Next, Nuxt, and many others.

Thank you for the correction, apologize if I muddied the waters. I didn't use meteor and only saw it from a distance. I do however use Next/nuxt/etc, and you're right that SSR/SG is a good counter-example to my point. I will say that outside of SSR/SG, isomorphic javascript isn't used that much in my experience. But it is a great counter-point for sure.

For the uniformed, like me, here's a meteor RPC - https://guide.meteor.com/methods.html

I think components exist today that can replace meteor:

- EdgeDB

- tRPC / Blitz

- React

Reply on news.ycombinator.com