undefined | Better HN

0 pointsonion2k6y ago0 comments

Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem.

This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is completely insignificant compared to how good it is to work with in the long term.

Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.

0 comments

8 comments · 4 top-level

hombre_fatal6y ago· 4 in thread

I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django.

My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.

mastersummoner6y ago

I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.

onion2kOP6y ago

But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.

It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better.

All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.

2 more replies

KurtMueller6y ago

> My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.

You can view the source code of Devise any time you want on its github repo - it's not hiding anywhere.

I think that having authentication code vetted by 100s, if not 1000s of different developers is much better than rolling your own authentication code.

ljm6y ago

For me it's more nuanced, and I wish I saw more of it.

You make your prototype or fit your product with a rapid dev framework, Rails is pretty much built for that, it doesn't intend to scale beyond it (see Basecamp: they don't pile onto a monolith, they make fresh new versions).

One you get that product fit, your codebase should still be small enough to rebuild it quickly in a more stable language. Java, C#, Go, Rust, whatever... something that gives you better runtime guarantees without requiring bonkers amounts of language hacks so you can spend less time writing unit tests and stubs and mocks.

zachrose6y ago

I’m inclined to agree, but it seems fair to admit that there’s a survivorship bias going on here. My hypothesis is that projects that go on to require years of enhancement and maintenance have survived an initial window of people losing interest or getting distracted by another idea. Projects that demonstrate value within a very short time of their conception are likely to survive this early period.

Im not saying it’s rational to skip three days of early development for months of effort down the line, just that it happens.

KurtMueller6y ago

> Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.

I think being able to have a default toolbox that will allow you to get up and running quickly so you can find a proof of concept or really start to formalize the problem your app addresses and the solution it provides, along with a quick feedback loop, is very valuable.

larrywright6y ago

I disagree, at least in part.

“Time to Productivity” is a reasonable way to evaluate the overall complexity of a tool.

j / k navigate · click thread line to collapse

0 comments

8 comments · 4 top-level

hombre_fatal6y ago· 4 in thread

I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django.

mastersummoner6y ago

I think it's important to learn and understand, absolutely. But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.

onion2kOP6y ago

But a default installation/configuration which both works correctly and is easy to set up is pretty damn valuable.

2 more replies

KurtMueller6y ago

You can view the source code of Devise any time you want on its github repo - it's not hiding anywhere.

I think that having authentication code vetted by 100s, if not 1000s of different developers is much better than rolling your own authentication code.

ljm6y ago

For me it's more nuanced, and I wish I saw more of it.

zachrose6y ago

Im not saying it’s rational to skip three days of early development for months of effort down the line, just that it happens.

KurtMueller6y ago

> Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.

larrywright6y ago

I disagree, at least in part.

“Time to Productivity” is a reasonable way to evaluate the overall complexity of a tool.

j / k navigate · click thread line to collapse