Hacker News new | ask | show | jobs
by ibejoeb 4046 days ago
I wonder where all of the dislike for Meteor originated. It's a cool product built buy some really smart people. They have the best cli tool I've used in a dev environment, and they're making a ton of progress. They're constantly publishing materials on integrating with third-party components including react, rethinkdb, famo.us.

I hear you about the potential implosion by acquisition. It's definitely a risk. It's not much different than other burgeoning technologies in that regard.

Meteor is advancing a new paradigm of building consumer applications, much like Django and Rails did for REST. It lowers the barrier to entry, and it really has the potential to expose a new generation of programmers to modern techniques.

I also think they've been pretty clear about when Meteor is unsuitable, despite the hype. It's not going to magically scale. It's not a bad place to start, though.

2 comments

Seems to me I'm one of the few people who are willing to openly express their dislike while also having a real life use case where it caused harm to a startup actively seeking funding.

I was brought into a company where the lead dev was doing everything in Meteor, if I wasn't open to Meteor at the time I would not have taken the job. Over the course of 6 months I watched this dev utilize their ability to sound smart to fool everyone into thinking Meteor was the right tool for the job when they really just wanted to become a Meteor expert since they thought this would be the next .NET that would give them sweet cushy consulting gigs in industries with crazy technology budgets.

I worked with the technology and was unimpressed. Everything needs to go through Meteor and it leaves no room for flexibility. Going with Meteor is an all-in strategy... and anyone who knows strategy ought to know that going all-in is for when you're exceedingly confident or exceedingly desperate.

I recognize Meteor's utility as a rapid prototyping tool. I will openly say anywhere that if you have little development resources and want to build out a proof of concept. Yes, utilize Meteor. But if you don't throw it away after you've shown whoever needs the proof, you are asking for trouble.

The problem with lowering the bar with a new paradigm exposed to a new generation of programmers is that they're being taught bad habits and bad patterns. Tightly coupling the front and back end (what "isomorphic javascript" really means) is Meteor's main selling point. Tight coupling of systems is a universally accepted anti-pattern and anyone who has a product that eventually requires flexibility in their client-server communication is going to find themselves stuck when everyone just stares blankly repeating "but... DDP?"

Creating a new generation of programmers who call themselves rockstars because they know how to run a couple Meteor CLI commands and make a Todo list app in 20 minutes is not going to make the Internet a better place.

How did Meteor fail and cause harm?

It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.

I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.

First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.

* The website has a whole subdomain devoted to using it with Angular: http://angular-meteor.com/.

* Here's talk given about using React: https://youtu.be/-QtrkXKvQFc. I'm currently doing this with great results.

* Here's one of a few projects providing support for PostgreSQL: https://github.com/meteor-stream/meteor-postgres/wiki/Gettin...

Basically, if there is javascript support for it, you can use it with Meteor.

Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.

Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.

If I want to use Angular, I can include a single javascript file and then bootstrap my entire page, or a portion of the page with an application module.

If I want to make an application where one page is an Angular client app and the other is an Ember app, but they're both served by the same server and communicate to the same API you can do that with number of server-side frameworks and architectures... not Meteor though.

Meteor is an all-encompassing server+client package. You'd need to include all your angular application code along with all your ember application code because they share the same meteor server application and meteor is not built to separate clients from servers.

My bad experience and much of my frustration comes from Meteor's hype machine. This person was hyping Meteor as a production ready framework to a startup when it was not... hell it hadn't even reached the arbitrary 1.0 version number yet.

In fact, when Meteor upgraded to 0.9 it force upgraded everyone... i couldn't run `meteor -v` without Meteor saying "Upgrading to v0.9...", which of course would break all the atmosphere packages we were dependent on to have Meteor connect with all the normal functionality that NPM modules would offer.

Meteor evangelists will say "oh, but it wasn't 1.0 and atmosphere isn't a thing, or whatever", because it's always a deflection when it comes to this conversation. The fact that this is a thing that COULD happen is never addressed, the architecture and patterns that led to something like that happening is just ignored.

Exactly. Coming from a different background (not CS), Meteor is a great place to start. The barriers to entry are really low and specially the risk is also very low: it's javascript ,"late bloomers" can't afford to learn something that might not be directly useful if their bet turn out a loss.

I am all in.