4 ms·

Then Meteor does not meet your use case. Some people actually like opinionated, monolithic frameworks because it reduces decision fatigue and boilerplate codin

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 time savings earned now are worth the technical debt that I might face in the future.

debaserab2 11y ago
> 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.
- eterpstra 11y ago
  Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
- nostrademons 11y ago
  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.com/en//people/jeff/WSDM09-keynote.pdf http://static.googleusercontent.com/media/research.google.co...
  - debaserab2 11y ago
    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 always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.
    - nostrademons 11y ago
      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.
- krisdol 11y ago
  It's easier to rewrite something than it is to produce an MVP that consumers and investors want to buy into. I'm 150% into the anti-monolith approach for serious scale, but meteor is like Rails in the respect that small teams can accomplish rapid prototyping and fast iterations early on.
  - debaserab2 11y ago
    So why wouldn't you use rails and benefit from a matured platform and more proven scalability?

debaserab2 11y ago

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

eterpstra 11y ago
Yes. I'm replacing a legacy PHP app with Meteor right now. However, instead of building a huge, monolithic app, I'm replacing sections of it piecemeal with small Meteor apps that use npm modules (or meteor packages) for shared functionality. So if one app doesn't work out, then yes, it'll be more work to replace it with some new fancy future thing, but hopefully it'll have paid for itself by then.
nostrademons 11y ago
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.com/en//people/jeff/WSDM09-keynote.pdf http://static.googleusercontent.com/media/research.google.co...
- debaserab2 11y ago
  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 always true, but in the case of CRUD based web apps, it's a lot smoother in my experience.
  - nostrademons 11y ago
    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.
krisdol 11y ago
It's easier to rewrite something than it is to produce an MVP that consumers and investors want to buy into. I'm 150% into the anti-monolith approach for serious scale, but meteor is like Rails in the respect that small teams can accomplish rapid prototyping and fast iterations early on.
- debaserab2 11y ago
  So why wouldn't you use rails and benefit from a matured platform and more proven scalability?