3 ms·

> that is more productive than Rails So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly? I mean, what

by pka 8y ago

> that is more productive than Rails So, spending a year and a half on a major version upgrade of your web framework is "productive" how exactly? I mean, whatever time you think you've saved by using Rails during the initial prototyping phase (and I don't think even that's true), you'll more than pay for in maintenance costs.

jimnotgym 8y ago
1) I think Github are a long way past prototyping... they just sold their rough sketch for $7.5b 2) A year and a half of how much effort?
- pka 8y ago
  > A year and a half of how much effort? > The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers. They had four full-time people working on upgrading Rails at some point!
hnzix 8y ago
So. What is your suggested alternative stack for rapid MVP prototyping? Personally I'm fascinated with Clojure but it doesn't yet have the ecosystem (for me as a Clojure noob) to easily punch out product prototypes. Likewise I've messed with JS frameworks and they're fun but they don't offer me proven established patterns; too many competing and fast-moving choices. I'd rather find my market fit first then worry about scaling / paying off tech debt. Again, what's your suggested model? To me Rails offers a semi-boring yet productive middleground between high and low ceremony. TAANSTAFL.
- pka 8y ago
  If you're talking about CRUD boilerplate apps, literally any modern web framework in a static language. Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not. So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.
  - hnzix 8y ago
    Honest engagement. > literally any modern web framework in a static language I was part of a SaaS startup using Java Spring and the verbosity and front-loaded design costs slowed our iteration enough that we couldn't respond to market input and stalled. My next SaaS engagement was with a language more maligned than Ruby - Perl - and while the codebase was mildly fugly we could move quickly and I tell you what the founders made serious bank. > you start paying back the price tenfold once your project becomes moderately complex This is a problem you want to have because you have skin in the game. Better to start paying back your debt than to never kick off. Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick? Elm is the only choice that comes to mind, and that's pretty niche. Ask yourself why. (I'm not dissing elm, it looks lovely) There's no definitive answer here. Rich Hickey makes some excellent talking points about static vs dynamic. I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone. TAANSTAFL. Pick the right tool for the job. I wouldn't use Rails to build whatsapp, but for many midsized SaaS products Rails is a cromulent choice.
    - pka 8y ago
      > I was part of a SaaS startup using Java Spring You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java anymore, but iirc Play [0] would be worth checking out. > This is a problem you want to have because you have skin in the game. I'm saying that this is a problem you don't have to have at all. > Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick? In the context of SPAs, I'd choose some of the Purescript React libraries and some generic Haskell REST/Websocket server, like Warp/Servant (this is a stack I've used in production). For a standard web app, I'd go with Yesod [0], which is a somewhat Rails-like framework, but it fully leverages the advantages of static types, i.e. it turns things like dead links, trying to inject user input into a DB query without escaping it first, invalid queries (i.e. querying a person by product id), and many more into compile-time type errors. > I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone. Still, to claim that the context of the current thread at least doesn't suggest that Rails is a maintenance nightmare would be disingenuous at best. > Pick the right tool for the job. That's what we're discussing here, right? I can't see when Rails would ever be the "right tool" for anything (except for the one use case I alluded to above) but that's obviously subjective, rendering that phrase utterly meaningless. [0] https://www.playframework.com https://www.playframework.com [1] https://www.yesodweb.com https://www.yesodweb.com
djur 8y ago
The time spent to upgrade a framework is at least partially compensated by the time you save not having to implement functionality provided by the framework. And that's not just overt features of the framework, but also security fixes, compatibility with a broader ecosystem of third-party tools and libraries, and often a less complicated dependency story (compared to cobbling together the features provided by a framework from a few dozen Node modules or the like). Obviously, there's a break-even point there that's different for every framework and every application. But I think the ongoing popularity of web app frameworks suggests that a lot of people find the tradeoff acceptable.

by pka 8y ago

jimnotgym 8y ago

1) I think Github are a long way past prototyping... they just sold their rough sketch for $7.5b 2) A year and a half of how much effort?

pka 8y ago
> A year and a half of how much effort? > The project originally began with 1 full-time engineer and a small army of volunteers. We grew that team to 4 full-time engineers plus the volunteers. They had four full-time people working on upgrading Rails at some point!

hnzix 8y ago

So. What is your suggested alternative stack for rapid MVP prototyping? Personally I'm fascinated with Clojure but it doesn't yet have the ecosystem (for me as a Clojure noob) to easily punch out product prototypes. Likewise I've messed with JS frameworks and they're fun but they don't offer me proven established patterns; too many competing and fast-moving choices. I'd rather find my market fit first then worry about scaling / paying off tech debt. Again, what's your suggested model? To me Rails offers a semi-boring yet productive middleground between high and low ceremony. TAANSTAFL.

pka 8y ago
If you're talking about CRUD boilerplate apps, literally any modern web framework in a static language. Again, even if "rapid prototyping" was a thing in Rails (i.e. rapid as opposed to what?) you start paying back the price tenfold once your project becomes moderately complex, test coverage or not. So if your question is specifically "What's a good stack for a blog I'll never touch again or maintain with X and Y integration, tomorrow", then ok, cool, Rails.
- hnzix 8y ago
  Honest engagement. > literally any modern web framework in a static language I was part of a SaaS startup using Java Spring and the verbosity and front-loaded design costs slowed our iteration enough that we couldn't respond to market input and stalled. My next SaaS engagement was with a language more maligned than Ruby - Perl - and while the codebase was mildly fugly we could move quickly and I tell you what the founders made serious bank. > you start paying back the price tenfold once your project becomes moderately complex This is a problem you want to have because you have skin in the game. Better to start paying back your debt than to never kick off. Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick? Elm is the only choice that comes to mind, and that's pretty niche. Ask yourself why. (I'm not dissing elm, it looks lovely) There's no definitive answer here. Rich Hickey makes some excellent talking points about static vs dynamic. I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone. TAANSTAFL. Pick the right tool for the job. I wouldn't use Rails to build whatsapp, but for many midsized SaaS products Rails is a cromulent choice.
  - pka 8y ago
    > I was part of a SaaS startup using Java Spring You may accuse me of shifting the goalposts, but do notice I said modern above. I'm not up-to-date with Java anymore, but iirc Play [0] would be worth checking out. > This is a problem you want to have because you have skin in the game. I'm saying that this is a problem you don't have to have at all. > Back to you - you didn't address my question - if you were to launch a product idea, what static stack would you pick? In the context of SPAs, I'd choose some of the Purescript React libraries and some generic Haskell REST/Websocket server, like Warp/Servant (this is a stack I've used in production). For a standard web app, I'd go with Yesod [0], which is a somewhat Rails-like framework, but it fully leverages the advantages of static types, i.e. it turns things like dead links, trying to inject user input into a DB query without escaping it first, invalid queries (i.e. querying a person by product id), and many more into compile-time type errors. > I'm not saying you're categorically wrong, but you haven't presented any science to support your dismissive tone. Still, to claim that the context of the current thread at least doesn't suggest that Rails is a maintenance nightmare would be disingenuous at best. > Pick the right tool for the job. That's what we're discussing here, right? I can't see when Rails would ever be the "right tool" for anything (except for the one use case I alluded to above) but that's obviously subjective, rendering that phrase utterly meaningless. [0] https://www.playframework.com https://www.playframework.com [1] https://www.yesodweb.com https://www.yesodweb.com

djur 8y ago

The time spent to upgrade a framework is at least partially compensated by the time you save not having to implement functionality provided by the framework. And that's not just overt features of the framework, but also security fixes, compatibility with a broader ecosystem of third-party tools and libraries, and often a less complicated dependency story (compared to cobbling together the features provided by a framework from a few dozen Node modules or the like). Obviously, there's a break-even point there that's different for every framework and every application. But I think the ongoing popularity of web app frameworks suggests that a lot of people find the tradeoff acceptable.