Hacker News Reader

Comment by lmm | Hacker News Reader

Why do you think an all-in-one framework is an advantage? As soon as you want to switch something out you end up fighting the framework and the tutorials. Better to start with dedicated libraries that each do one thing - it's inevitably where you're going to end up.

(Not that I'd consider an untyped ecosystem in the first place, especially one as fond of "magic" (e.g. monkeypatching) as rails. I have sympathy for just getting something working as quickly as possible, but there comes a point where you're storing up too much trouble even for the short term)

View on HN

> it's inevitably where you're going to end up

If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".

For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.

If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.

It's great if you have unlimited resources to spend the time setting up the perfect tech base for a project for if it does eventually require scaling above what, Basecamp for example, can handle - but that seems like wasted resources for a great deal of orgs that don't have that level of backing.

Of course, if you truly need something novel, then it's a moot point, if you can't achieve what you need to with a stack, then just don't use it.

> If the project's successful. The chance that most of what we're building with Rails hits the required escape velocity to require something other than Rails is a "Nice Problem".

> For the vast majority of things people are building for the web, "CRUD+Auth+Billing" is all that's needed, maybe with a few API hooks into something more novel running on different infra.

> If you then need it, then you can just build out a few more services with a few more API hooks, and then transition to a non-Rails stack as required.

True as far as it goes. But if we're just talking about a prototype for validating product/market fit, with the intent to transition to a more maintainable stack as and when that becomes necessary, what's the problem with "list of 30 random npm packages" as a starting point?

Rails can take you much further than MVP though, as evidenced by all of the companies that reach breaking point with it. Basecamp, Github, Shopify - all reached proper business status on Rails (arguably Twitter too, although business is a bit of a stretch...).

We can argue it from both ends, but I see Rails as the middle ground, and allows you to go from MVP to $XXm ARR on the same stack. A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes, and a custom architecture is useless if you don't get any users.

> A hacky MVP with 30 npm packages doesn't have a clear path up the tree to grow without serious changes

I see it as the opposite: it's clear which functions are the responsibility of which library, and it's easy to replace the ones that are becoming blockers and leave the ones that aren't. Whereas with Rails if you keep it monolithic then upgrades always become a huge pain point, but if you try to cut out pieces of it you're going against the grain.

(I used to love TurboGears nearly a decade ago, because you could use it like a monolithic framework to start with but it was explicitly a collection of standalone libraries underneath, and so once you started needing to do different things to individual pieces it was easy to. The modern web ecosystem could do with something like that, IMO (though personally I'm sticking to ScalaJS for the type safety))

> what's the problem with "list of 30 random npm packages" as a starting point?

The dude starting with rails will probably be done with the MVP before you decide _which_ 30 random npm packages to use.

I'd probably just copy/paste from my current project TBH, which takes all of 5 seconds.

I think the types argument is bullshit but it's just my opinion. Do python or ruby devs really feel they are less productive than java devs because they have no types? What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

I'm absolutely terrified of refactoring in big python, ruby, or javascript codebases, because there's less chance that I'll be able to find all the side effects of changing something. Tests help, but maintaining high-enough test coverage over possible code paths can be harder and less useful than working with a type system and writing fewer tests.

> What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

I agree that that's what's going to happen in the short term, but var doesn't mean becoming dynamic; type inference doesn't compromise soundness at all. I think it's going to be much easier for sound type systems to get good-enough inference (indeed Hindley–Milner already offers "perfect" inference: you don't need to write any explicit types if you don't want to) than for dynamic languages to retrofit soundness. And while one can live with a few unsound constructs as long as it's locally clear when unsoundness is happening, as soon as you have pervasive soundness issues with action-at-a-distance your type system becomes almost useless.

> Do python or ruby devs really feel they are less productive than java devs because they have no types?

Yes, I do.

OK, it's a fair opinion to have. But that's all it is, an opinion. Also - what makes you stick to python/ruby then?

I don't know about ruby and python but in JS there a significant number of projects that aim at adding a type system on top of the launguage

I don't think it's such a huge trend, if it was Python wouldn't be one of the top 3 most popular languages in the world. Yes, there is typescript for Angular. Outside of that how often is it used? Pure JS is still used tons.

It may not be a "huge trend", but those investing into static typing reap the rewads. Facebook rewrote messenger in ReasoML, bugs reported by users went from hundreds a year to less then ten. Fearless refactoring is another plus, the compiler will find everything you need to change to make the program run correctly.

Python 3 has type annotations and there are static type analyzers for it.

Var is hardly more dynamic. Type inference is comes from statically type functional languages.

Java's var is only for type inference so nothing to do with dynamic typing.

> Why do you think an all-in-one framework is an advantage?

Because it has allowed the community to develop a whole lot of well-integrated, batteries-included libraries that span the from the model layer to the frontend.

I hate to break it to you, but Rails doesn’t span the frontend. Hell, the frontend isn’t even written in the same language.

Of course it does. Not in SPA-javascript, but there's a ton of support for erb views:

https://guides.rubyonrails.org/action_view_overview.html

I’m aware of this; I did Rails development for like five years. Server-side HTML templating isn’t a complete “batteries included” frontend solution anymore. In fact, it’s usually the first part that gets thrown away.

What makes you think Ruby is untyped?

I think they meant “dynamically typed”.

Reply on news.ycombinator.com