Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Meteor Part 1: What Went Wrong

discovermeteor.com

Post reply on HN
Print view View original

131–140 of 189 posts

Re: The State of Meteor Part 1: What Went Wrong

#131

Post by nostrademons »

debaserab2 wrote: post #69
eterpstra wrote: post #57

Earlier quoted context omitted.

Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate coding. For small teams with outsized requirements, it's a perfect fit. I've built a couple (internal) apps with Meteor and got a tremendous amount done in a short time. Maybe someday I will need to replace 'x' with 'y' and have a hard time (or maybe not), but the t…

> but the time savings now are worth the technical debt that I might face in the future Oh, man that statement makes me cringe. Have you ever replaced a piece of proprietary technology with a different one before? I promise you, you will consider this decision up front much more closely next time.

Most apps that become successful have to be rewritten multiple times as they grow. One of Jeff Dean's rules of thumb [1, p. 11] is that a system will generally need to be completely rewritten every 1-2 orders of magnitude growth.

Yes, this sucks, as anyone who's gone through a rewrite can tell you. But the broader perspective is that this is what software engineers are paid for. If you could just build a system and let it grow with minimal tweaks, the only people the software industry would employ would be technical founders.

[1] http://static.googleusercontent.com/media/research.google.co...

Re: The State of Meteor Part 1: What Went Wrong

#132

Post by tomcam »

ianamartin wrote: post #64

I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions. I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It's not really that hard. If you can JS, you can SQL.

> If you can JS, you can SQL

Reactive SQL in the Meteor style is tricky because who has time to reverse engineer DDA, and rolling it yourself would mean guaranteeing that you ended up doing it not the Meteor way.

Re: The State of Meteor Part 1: What Went Wrong

#133

Post by ThrustVectoring »

ploxiln wrote: post #123
cmdkeen wrote: post #14

Earlier quoted context omitted.

I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.

I think it's interesting to consider the reasons why that is. Why are backends typically slowly upgraded while maintaining a compatible API, while front-ends undergo big re-designs and re-writes from scratch just about every year? At commercial, successful startups? One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully sim…

Front-end systems have more room for creative expression, drawing in more of those who want to express themselves with a major overhaul. Furthermore, the base skills of front-end developers are more of "understanding how humans interact with user interfaces" and managing complex state. Back-end developers tend to need more understanding of the problem domain and communication skills, so the developers that do better at back-end work tend to build things that need less updating.

Basically, I'm asserting that front-end and back-end work attracts different kinds of developers. Back-end developers are less likely to write things that need replacing, and front-end developers are more likely to want to replace things.

Re: The State of Meteor Part 1: What Went Wrong

#134

Post by oldmanjay »

goldenkey wrote: post #58
oldmanjay wrote: post #55

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…

Off topic but is there a reason I keep seeing this word 'grok' used all over HN? Just say 'understand' unless there's a reason to sound like you have aspergers. And 'fully grok' is redundant anyhow - grok implies a full and deep low level understanding with no lapses, you cannot partially grok something. It's dissapointing to see uncommon words used in poor ways, I'm seeing this word misused all over HN as if its now…

I apologize for the redundancy in my phrasing. Hopefully you can get over it.

I do not appreciate you using "Aspergers" with an insulting tone.

Re: The State of Meteor Part 1: What Went Wrong

#135

Post by muloka »

yawboakye wrote: post #99
at-fates-hands wrote: post #40

Earlier quoted context omitted.

Agreed. This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level. Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off,…

Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new ideas by the second (pods, composable components, components over controllers, DDAU, etc) but the community eagerly awaits and embraces them. I don't know why that is.

Rails forked sometime ago (around 2.0) into Merb then later on merged back into Rails 3.

Similarly Node forked into io.js then later back into Node 4.

Re: The State of Meteor Part 1: What Went Wrong

#136

Post by ThrustVectoring »

mrcwinn wrote: post #108
magicmu wrote: post #23

The startup I'm with right now just finished a meteor/react project that I led. This article really touched on our major pain-point with the learning cliff that you hit after a certain point. We used FlowRouter since it has React support, but managing subscriptions correctly (let alone caching them) took way more time than we had anticipated. It wasn't until near the end of the project that we realized none of us act…

It's good to realize the mistake here, so good job. Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies. Meteor is really fun to play with and the community is very good, but Meteor creates complexity over time. It's also worth mentioning that unless you have a real-time app whose data model fits nicely with schema-less document storage, Meteor is alm…

>Always prefer tools closer to your core competencies.

This is basically the reasoning behind my recent choice to not use an API documentation framework. Our application framework already has the ability to introspect and render templates, so there's minimal advantage in adding yet more tooling surface area.

Re: The State of Meteor Part 1: What Went Wrong

#137

Post by s_kilk »

ploxiln wrote: post #123
cmdkeen wrote: post #14

Earlier quoted context omitted.

I think the big problem with isomorphism is that there's a fundamental disconnect between the lifetimes of front and back end systems. Well written back end code (hell, badly written back end code) could be left running for decades with better front ends bolted on. A front end system written even a couple of years ago starts to be less maintainable as developer skill sets move on, best practice evolves etc.

I think it's interesting to consider the reasons why that is. Why are backends typically slowly upgraded while maintaining a compatible API, while front-ends undergo big re-designs and re-writes from scratch just about every year? At commercial, successful startups? One obvious reason is that the appearance of looking "modern" and "up-to-date" is a strong signal of vitality for many consumers, and this is awfully sim…

Data is forever.

If you've got a working model (and system) for Users, Widgets, Gizmos and Sprockets, then there's little reason to change.

New client devices come and go though, and users expectations of a good interaction experience change, and once your backend is solid you can quickly throw a new skin over it and view/interact with it in a new way.

Re: The State of Meteor Part 1: What Went Wrong

#138

Post by gknoy »

angersock wrote: post #118
m52go wrote: post #106

Earlier quoted context omitted.

I'm not saying the # of GitHub stars is a good reason to choose a framework. But it is an indicator of it being something more than not-just-another-stupid-shiny framework that cannot be immediately dismissed.

I'd disagree--a lot of the JS folks I've met are like magpies and will star anything that looks remotely interesting on Github. It is exactly chasing shiny.

I normally treat stars as a bookmark, rather than as a declaration that I believe this is High Quality Work. Rather it's more along the lines of "I want to be able to find this easily at home when I have spare time next week".

Re: The State of Meteor Part 1: What Went Wrong

#139

Post by al2o3cr »

oldmanjay wrote: post #55

I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…

See also Martin Fowler's "First Law of Distributed Objects" - "Don't distribute your objects". The reasoning is exactly as you described.

Re: The State of Meteor Part 1: What Went Wrong

#140

Post by zzzmarcus »

muloka wrote: post #130
fefifofu wrote: post #128

This article does a disservice to Meteor. The article feels drama filled and says many things are broken when they are not. "Blaze is threatened by React". You can use React or you can use Blaze. If React becomes so popular that Blaze is not longer used, that's OK... nothing to be threatened about. It's nice that Meteor can move with a trend. "Tracker and Minimongo might eventually disappear as well". Tracker and Min…

RethinkDB is still a strong possibility as an alternative, it's similar enough to MongoDb. While there is no official core SQL support yet there are 3rd party add ons for PostgreSQL and MySQL available.

There are no Postgres or Mysql add-ons for Meteor that are actively maintained or even close to production ready. Hopefully you can prove me wrong on this, but I've looked and have only found preview releases and alpha quality packages.
Post reply on HN