Hacker News Reader

Comment by magicmu | Hacker News Reader

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 actually had a total mastery of what was going on under the hood in meteor, which was a terrifying realization. All things considered, though, I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before. On the other hand, blaze is pretty rough...

View on HN

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 almost never the right tool for the job. And even if your project has those requirements, there are plenty of high-quality alternatives to Meteor.

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...

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

This is correct, but it is also a balancing act. Sometimes the new thing is better. Sometimes it is simpler in important ways that provide leverage in the long run, despite being complex in other ways that create confusion in the present. Sometimes you need to learn new tools and shift your core competencies toward them.

An analogy: Nobody writes directly in machine code anymore. Symbolic assemblers were new technology that was better. The early ones may have been buggy, and it may have been simpler to just write it by hand instead of debugging your own code and the assembler, but eventually it paid off. Your core competency may have been writing machine code, but once the assemblers became good enough, it made more sense to be competent at using them.

Very few new technologies represent such a massive and obvious level-up as that, and it is unwise to chase everything in hopes that it will be one of those paradigm-shifters, but it is equally unwise to hide your head in the sand, believing that all new things are necessarily complex and unworthy.

I have been, and remain, skeptical of Meteor itself, but the problems it is targeting are real, and I think it and other projects are circling in on good approaches to solving them, which is worth paying attention to.

> 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. :)

>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.

> I think our biggest mistake was biting off more than we could chew in using React and Meteor, when we had never made an app using either before.

I see people make this mistake over and over again. It's so easy to underestimate the cost of learning something new. Often times it's best to just go with what you already know until you've done enough non-mission critical in the shiny new thing to be confident in it.

It's why PHP still thrives.

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 safe way in php. There's no even halfway decent solution. Half-supported, roll-your-own in doctrine is the best you can get

> 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.

Yep, lesson learned big time :)

So why did you pick a tech stack for this project, given that you had not used it before, sounds like no-one in your team had either, nor is this stack widely used (afaik)?

It seemed to fit our use-case really well. The CTO and I did a Meteor hackathon to get a feel for the tech, and thought that it would be a lay-up. Alas, it was quite an error.

Don't evaluate a technology after having used it only during a couple-days hackaton.

If you had to do it all over again what would have been your choice(s)?

Reply on news.ycombinator.com