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

181–189 of 189 posts

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

#181

Post by nostrademons »

debaserab2 wrote: post #169
nostrademons wrote: post #131

Earlier quoted context omitted.

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 l…

Your rewrite doesn't need to be on a completely new platform or language, and depending on the use case you'd still benefit greatly from using some of the original functionality of the current code base to do things until you're in a position to replace them. In my experience, you often iterate towards a replacement instead of pulling the rug out from the current platform and replacing it with another. This isn't alw…

Agreed, but the first step in a major rewrite that's necessary because the product has outgrown its original purpose is to draw up appropriate system boundaries. These could be in-process libraries, webservices, RPCs, data protocols, database schemas, or whatever, but if they're out-of-process, there's nothing preventing you from using a different language or platform to rewrite that subsystem. You can decide to continue using the original proprietary platform based on whether it's still appropriate for your needs, and you're not locked into it just because all the existing code is in it.

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

#183

Post by tim333 »

e12e wrote: post #176
heliostatic wrote: post #88

Earlier quoted context omitted.

I'm biased as the co-teacher, but I've been hugely impressed by progress our students have made in just three weeks. Meteor really does fit in well to the beginner curriculum.

Looking at the course page, it does indeed look like meteor is a good fit; it appears that if the course was from the late 90s it would be 2 parts html, 1 part css and 1 part cgi. But for a little higher level I always liked web2py[1] - it always felt like they managed to balance bundling/simplicity with proper documentation that build confidence in what is (and is not) included: like having a db schema accompanying…

I like web2py too though there don't seem to be too many people using it. Comparing to things like Meteor and Rails it's striking how it's remained backward compatible and much the same since it was launched 8 years ago.

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

#184

Post by klibertp »

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…

> Never jump on the new thing. Always lean toward the simple thing. Always prefer tools closer to your core competencies.

You can attack this problem from different angles. You can either refrain from using new tools OR you can widen your core competencies.

I work ~30h a week. The next 50h I spend doing my hobby thing, which is learning and using new - and old, as there are many forgotten tools which give you an edge over whatever is considered mainstream - tools in various areas. I'm a pathological case of a generalist, but even I have one or two things I specialize in.

Now, I did this for the last 10 years. The ratio of work vs. tech exploration was not always that favourable, but I kept doing this basically throughout the last decade. What I ended with is a skill that lets me very easily learn, understand and modify or fix new tools, be it languages, frameworks or libraries (among other things, ofc). So, in principle, I should have a vast choice of tools accessible to me.

But it doesn't work at all, because even if my project is currently being written by me only, it will be maintained by some other person in the future. And that person is almost guaranteed not to know any of the tools I decided to use, despite them being the best tools for the job.

Well, it looks like I'm just venting my frustration here, so please don't mind me. :)

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

#185

Post by flippyhead »

muloka wrote: post #135
yawboakye wrote: post #99

Earlier quoted context omitted.

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.

This is really a fantastic point. It's sometimes as if people think these type of projects exist in isolation and any perceived flaws are permanent. They often fail to appreciate how much the flaws will invoke a response to address them, making them better than they would have been had the flaws never been strongly felt by the community in the first place.

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

#186

Post by Sewdn »

The challenges discussed by the OP apply to any large-scale complex project and are not limited to developing in Meteor. True, some are specific to Meteor (besides the challenges that go with all NoSQL architectures), as is the case with any tech stack. IMO it’s quite unfair to obsess about the cons only (especially if they are the kind of “problems” you can’t tackle), and to take the pros for granted.

Routing in Meteor, for one, is trivial (esp. with Flow Router). Subscription management and caching are solvable problems too (esp. if you refrain from doing subscriptions during routing, but instead declare your dependencies where you are really are dependent on your data: in the UI components).

What’s the problem with using NPM packages inside Meteor, exactly? The fact that you must write a single additional line in a package? Well, if you’re not used to organize your code in re-usable Meteor packages, then, I guess, it’s more your problem, than it is a problem with Meteor.

Meteor does not scale well? How is that? Any Meteor app can scale, as can every application that has been set up with a well engineered architecture: implement you logic in micro-services and your Meteor app will scale smoothly, horizontally, until your database (and not your app layer, that is!) becomes the bottleneck.

Most of the comments here, seem to emanate from me the degree of freedom that comes with Meteor (platform vs. framework). If you can’t architect, then, obviously, Meteor won’t save your day and do your engineering for you.

I put up some slides with Meteor best-practices for building large-scale apps: http://meteor.redandivory.com/ The presentation is almost two years old, but most of the guidelines still hold.

tl;dr — It’s not the framework’s job to do your architecting. Don’t blame the tool if you don’t read the manual.

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

#187

Post by virgil_disgr4ce »

wsvincent wrote: post #75

I'm currently using Meteor to teach a college-level course on Web Development for beginners. https://csci16.hellometeor.com/ It's incredible how accessible Meteor is for this purpose: * One line complete local setup * One line deployment (to Meteor servers, but still) * Javascript only (no need to learn Python, Ruby, etc in addition) * Out of the box User Accounts * Simple templating engine with Blaze I can think of…

I've taught using Meteor as well, and I agree that it's incredibly wonderful for getting a real, live, modern web app off the ground in minutes. I plan to do more workshops with Meteor.

However, I wonder about what exactly beginner students are learning. It's important to illustrate foundational concepts, and Meteor's foundational concepts are quite different in some places: no traditional CRUD API, but rather an entirely new protocol (DDP) for automagically syncing databases. It's wonderful for prototyping but is something of a black box unless you're really going to dive deep.

My current philosophy is to teach Meteor as a rapid prototyping tool, for which it absolutely excels, where the audience is actual more on the product designer end but with nontrivial javascript experience. When I taught an absolute beginner's workshop, I realized (as others have said here) that the complexity level really does ramp up rapidly.

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

#188

Post by explorer666 »

bpicolo wrote: post #172
explorer666 wrote: post #95

Earlier quoted context omitted.

Or because it's a mature language, with a robust, very rich and up-to-date ecosystem.

It's really not very rich and up-to-date, in my opinion. In my experience, the vast majority of oss PHP projects started a decade ago, and they all keep certain back-compat, so they run with the drag of old paradigms. Actual new contribution to the ecosystem seems almost impossible to find, and there's a lot of areas that simply aren't great. E.g try to find a sane way to work with PostgreSQL json,jsonb columns in a…

> It's really not very rich and up-to-date, in my opinion. In my experience, the vast majority of oss PHP projects started a decade ago, and they all keep certain back-compat, so they run with the drag of old paradigms. Actual new contribution to the ecosystem seems almost impossible to find, and there's a lot of areas that simply aren't great.

100% false.

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

#189

Post by canthonytucci »

debaserab2 wrote: post #65
canthonytucci wrote: post #47

Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated. I just spent a good amount of time over the last few months building a prototype for an application in Meteor and it has been a joy. Out of the box I got happy, grokable app/server communication, I got sane user account tools and I got a build process that works well enough that I haven't thought abou…

> Give me a box of boards and nails any day. All my ikea furniture is rickety and much of it is starting to look dated. This seems to contradict the rest of your post where you go on to talk up the plug and playness of meteor. That's much more like ikea furniture than a board and nails. The board and nails approach requires you to do all the planning that meteor gives you out of the box.

I guess I think those things to be the building materials, and folder structure/routing/etc to be the stuff I don't mind making my self. I get how this might be opposite for others though.
Post reply on HN