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

121–130 of 189 posts

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

#121

Post by keithwhor »

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…

I've experienced this pain point (exceedingly complex systems) over and over again, and it's something I'm pretty passionate about. There's a lot of experimentation in JavaScriptLand that involves doing something cool or novel while totally forgetting about managing complexity. This is exactly why I built Nodal [1], I just wanted a fast, easy solution to build API servers.

We're a new thing, but the focus is on simplicity and how easy the system is to grok. The goal is to reduce complexity via separation of concerns as related to systems, not just programming modules (actually, Nodal itself is opinionated and some parts are tightly coupled. The argument there is consistency within the service to keep it easy to reason about. There's no DSL outside of the ORM, which reads like Django's. Just ES6 JavaScript.) We're not trying to compete in the space of "real-time apps" at all, because microservice architectures are tried, tested, and much easier to reason about (at the expense of having separate codebases - which I actually view as a positive).

I did a write-up about it this week [2] and we're focused on trying to tackle pain points re: web app complexity as best we can.

1. http://nodaljs.com/

2. https://medium.com/@keithwhor/hello-nodal-why-we-re-building...

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

#122

Post by cloverich »

popmystack wrote: post #98
ccallebs wrote: post #93

Earlier quoted context omitted.

> Where do you see negativity? The same place you saw the negativity, which is why you prefaced the sentence with "I'm sorry." One should not assume someone's technical prowess based on one poor decision (a decision they've recognized as suboptimal). Also, they still shipped.

That's a ridiculous statement. "I'm sorry" is not an indication of negativity. Nor is it indicative of my posting history. Apparently criticism is simply not allowed. Sorry to poke the fluff that is somehow being perceived as value. You most definitely can judge someone's technical prowess as well based on their decisions. I am not sure how you're going to grey-wash this into some kind of innocent mistake. The decisi…

> Apparently criticism is simply not allowed. Sorry to poke the fluff that is somehow being perceived as value.

Your original comment suggested this person mis-understood a foundational principle of software development. I, and I suppose many others, have been reading Hacker news since before we were senior engineers. So its not being "perceived" as having value; by your own admission, it is full of value (for a large portion of hacker news). While criticism is indeed tolerated, it must provide some value to the discussion. your original comment effectively read: "You are so incompetent, how did you ever get hired". That is not conducive to discussion; hence the down votes.

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

#123

Post by ploxiln »

cmdkeen wrote: post #14
s_kilk wrote: post #10

Earlier quoted context omitted.

Same. Welding the frontend to the backend is a definite no-go for me, regardless of the supposed benefits of this isomorphism.

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 similar to the yearly fashion cycle. But are there other reasons?

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

#124

Post by extrapickles »

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.

I currently use Meteor for a production app, but only use Mongo as a scratch pad (holding data until the user is mostly done changing their mind and other minor UI state). Data is then packaged and sent to MS SQL Server for long term storage and reporting.

As an example, a user can start updating a piece of data (eg: sales order, item, etc), with everyone able to see the changes as they happen (no hard need for locking, easy to support temporary network loss). Once they are done with changes, they are sent to SQL.

The advantage of doing it this way, is that the data stored in SQL Server can be completely optimized for reporting/storage and doesn't need the schema to support UI requirements. This makes things much simpler for people writing the UI as they don't have to change the SQL schema often to support the shinny new UI widget of the day and the report writers don't have to sift through a million useless to them tables/columns or partially entered rows to find the data they need.

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

#125

Post by Luyt »

elbigbad wrote: post #37
mariusmg wrote: post #26

Earlier quoted context omitted.

"likewise with frontend JS frameworks" And jQuery. Probabil still the most used JS library.

I believe this is correct to the point where jQuery is synonymous with javascript and thus doesn't need to be even mentioned. Plus jQuery isn't really a framework.

I see jQuery mainly as a library to eliminate browser differences.

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

#126

Post by edwinnathaniel »

There does not seem a day to go by without a NodeJS-based framework/library get the heat from the community ever since December 2015.

It appears that 2016 is the year when the hype from NodeJS died down and vendors/OSS-community must now deal with the hard, un-glamorous, work to clean up, maintain, prepare roadmap, and so on. Which is good!

Or it could also be the year where people realized that the use-case for NodeJS is fairly very very specific/niche (unless if they love JS so much that they're willing to absorb the pain using NodeJS + its ecosystem).

SailJS vs TrailJS, ExpressJS is dying, NodeJS vs io.js, StrongLoop+IBM fiasco (and SL reputation), now MeteorJS!. I had high hopes that MeteorJS can be one of the premier NodeJS frameworks (Rod Johnson, who created Spring Framework, invested in the company. I hope they listen to him...).

I love to see competition in NodeJS ecosystem and hopefully sooner than later, a few solid options emerged because right now, everything is not a good option except barebone NodeJS and roll-your-own-framework.

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

#127

Post by rgoomar »

This article is really great. Yes, Meteor is still one of my favorite platforms, but every library / framework / platform always comes with its pain points. I have had a great experience with it so far and I have to admit, I did get to a point recently where I was having trouble recommending it to other people and companies due to the various points stated in the post.

But, having said that, there is still a very bright future ahead for Meteor. The people at Meteor Development Group have identified these pain points and have plans to improve some of it. There are various tasks that they are working on now that will change Meteor a bit, but also make it a better platform (in my opinion). Things such as better NPM / module support, support for multiple different types of databases, faster build times, better testing support, etc.

The platform has been around for awhile and I still think that it can reach the goal of being the go-to JS platform for building cross-platform applications.

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

#128

Post by fefifofu »

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 Minimongo aren't giant stick bugs near Australia that need to be preserved. It's ok if they are replaced. They are internal tools for Meteor provide its "reactivity". I doubt reactivity is going away.

Other non-scary things: Routing is solved by community packages. Pagination, forms... really? Server-side rendering has the "spiderable" package, but the SEO / server-side rendering problem isn't unique to Meteor.

The database issue is valid. Meteor uses MongoDB. But, you shouldn't go down the Meteor road and try to shoe-horn a relational DB into non-relational DB, then say WTF. You knew from the beginning that non-relational DBs have their own set of problems. My limited understanding is that MongoDB was picked because it was the easiest way to get the reactivity that the MDG was looking for. Meteor road maps says SQL support is on its way.

I don't know where the OP is going with this. Maybe this is the part 1 of the late night TV commercial where they list all of our problems (think Slap Chop), then in Part 2 he'll solve all of our Meteor problems if we buy the next book he writes.

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

#129

Post by dvt »

So, full disclosure: I recently co-authored a book on Meteor which comes out in a few months[1]. I don't think Meteor is a cure-all panacea or that it's the Best Framework Ever®. I've come to Meteor with a fair bit of experience (Play 1.0/2.0, Sails.js, Flask, etc.) and a fair bit of skepticism. However, I really don't think much went wrong with Meteor. In fact, it treads some of the same ground as its predecessors. As far as OP's article is concerned, I have some very specific squabbles with it:

> This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.

Okay, Meteor has an arguably bigger barrier to entry than React or Angular (maybe), but definitely 100% not Go or Elixir. I think this is just disingenuous.

> I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.

This is the #1 problem of every framework, ever. Mr. Greif is not saying much, if anything at all.

> Once a new Meteor user starts to go beyond the basics and look into things like routing, pagination, subscription caching & management, server-side rendering, or database joins, they realize that the difficulty curve quickly ramps up.

Here, he's conflating things that are easy (routing and pagination) with things that are hard (subscription caching), so it's hard to see exactly what the criticism is here. Not to mention that Iron Router are pretty mature. I haven't run into a routing issue yet that it couldn't solve. As far as joins and caching, etc., these are definitely difficult things. I don't think any framework out there completely (and in the general case) solves these out-of-the-box. Maybe someone could introduce me to one.

> The result of all this is that Meteor has ended up in an awkward place.

I think it just ended up where almost all other frameworks end up: useful, but not completely generalized. In fact, I think striving for a very high degree generality might be a mistake, lest we want to end up with something like Hibernate.

[1] http://www.amazon.com/Introducing-Meteor-Josh-Robinson/dp/14...

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

#130

Post by muloka »

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.

Post reply on HN