4 ms·

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

by magicmu 11y ago

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

marknutter 11y ago
> 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.
- magicmu 11y ago
  Yep, lesson learned big time :)
- ams6110 11y ago
  It's why PHP still thrives.
  - explorer666 11y ago
    Or because it's a mature language, with a robust, very rich and up-to-date ecosystem.
    - bpicolo 11y ago
      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
      - explorer666 11y ago
        > 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.
scient 11y ago
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)?
- magicmu 11y ago
  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.
  - spdionis 11y ago
    Don't evaluate a technology after having used it only during a couple-days hackaton.
muloka 11y ago
If you had to do it all over again what would have been your choice(s)?
mrcwinn 11y ago
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.
- keithwhor 11y ago
  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/ http://nodaljs.com/ 2. https://medium.com/@keithwhor/hello-nodal-why-we-re-building-node-js-servers-for-everybody-dce14b27a233#.q3nogd5qg https://medium.com/@keithwhor/hello-nodal-why-we-re-building...
- ThrustVectoring 11y ago
  >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.

by magicmu 11y ago

marknutter 11y ago

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

magicmu 11y ago
Yep, lesson learned big time :)
ams6110 11y ago
It's why PHP still thrives.
- explorer666 11y ago
  Or because it's a mature language, with a robust, very rich and up-to-date ecosystem.
  - bpicolo 11y ago
    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
    - explorer666 11y ago
      > 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.

scient 11y ago

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)?

magicmu 11y ago
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.
- spdionis 11y ago
  Don't evaluate a technology after having used it only during a couple-days hackaton.

muloka 11y ago

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

mrcwinn 11y ago

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.

keithwhor 11y ago
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/ http://nodaljs.com/ 2. https://medium.com/@keithwhor/hello-nodal-why-we-re-building-node-js-servers-for-everybody-dce14b27a233#.q3nogd5qg https://medium.com/@keithwhor/hello-nodal-why-we-re-building...
ThrustVectoring 11y ago
>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.