Hacker News Reader

Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.

A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to).

Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.

To be fair, Rails now makes it much easier to swap libraries if you need to, compared to how it was at the beginning. I agree that that's something useful, but personally I still think that having a sane reference combination to start from is much better than having to choose everything yourself.

Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.

> I still think that having a sane reference combination to start from is much better than having to choose everything yourself.

That's why I'm such a fan of TurboGears - it's an easy starting point, but as soon as you want to step up to making your own library choices it's trivial to do so. I think the key insight is that no-one ever wants to go back to upgrading all of their different libraries in lockstep; a "platform" of libraries that are versioned together is a good starting point but at a certain point in the project lifecycle you want to unlock from that and after that trying to go back to the platform is only ever going to be pain.

You know that Rails is a collection of libraries that can pretty much all be replaced with the alternative of your choice, right?

Up to a point. In my experience there is limited support for e.g. using "mismatched" versions of different parts of it.

Isn't that the same with any collection of libraries? If you don't use a framework and just pick your libraries, you'll still need to ensure that their versions work fine together.

If you pick a bunch of standalone libraries you can be fairly confident they're not going to interfere with each other - which version of your web templating engine you use has nothing to do with which version of your ORM you use, and you can upgrade each independently. When they're both part of a big overarching framework it's more likely that a subtle interaction has slipped in and not been noticed.

Can you give an example of a collection of libraries that you would consider would compete with Rails?

On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.

> starting from scratch or from a minimal base is massively slower

This isn't the better alternative to frameworks.

The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch".

The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work.

Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.

> you tell the libraries how to work together

Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?

With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here.

If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).

Less than you'd think.

The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.

> > starting from scratch or from a minimal base is massively slower > This isn't the better alternative to frameworks.

I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.

I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.

It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team.

I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)

"more error prone and less safe"

right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.

CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default.

XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway.

This was a big reason to use frameworks in past days, though.

Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend.

In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.

> when creating web applications, starting from scratch or from a minimal base is massively slower

Because every web app is the same CRUD app, right?

Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.

> I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning.

I agree with this, but I end up at the opposite conclusion. This post about JavaScript frameworks [1] by Tom Dale puts it nicely:

> I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.

[1] https://tomdale.net/2015/11/javascript-frameworks-and-mobile...

I've found it kinda weird how Rack isn't emphasized in the Rails tutorials. It's really one of the crown jewels (heh) of the Ruby ecosystem. I suppose Rails wants to abstract away all the nitty gritty request based stuff but it's really powerful if you know how to use it.

You're absolutely right. Rack is incredibly powerful!

Might it be possible that there is a subtle catch in "if you know how to use it"? The more powerful a tool is, the more potent a temptation it can present to those who might understand what Rack can do but who could perhaps also stand to possess a greater degree of wisdom in considering what the right tool is. A small number of very experienced, wise, and deeply skilled developers can be trusted to use their tools well - yet this may not describe all possible scenarios.

Again, you're completely right. Rack is vastly powerful and immensely useful. Yet perhaps there might be good reasons for not quickly introducing people to all the glory and power of Rack.

Well framed and this is what we all learned and moved to: There are new paradigms out that just make so much more sense and which are followed by the majority. When I read the original submission, I mean just the title, I was facepalming in my mind.

Rails had its time and there were reasons why people liked it. But when I see that people post that Rails is still great in 2019, I'd like to stress following issue because those people might confuse newcomers who have to decide which ecosystem they gonna join.

The problem is that being in a big or biggest and still growing ecosystem makes life much easier. Once an ecosystem is on the decline you get less good libs or libs are not actively maintained anymore and the best people who shape tech are also moving to new ecosystems. I don't want to bash Rails but just an example, I didn't see any proper http/2 support in Rails-land. Now, you could say who needs http/2 (it makes a huge difference btw). But the point is that it arrived in one of the biggest ecosystem just recently and not every lib there supports it out of the box. And that's just one of many examples. People repeat that Rails has so mature 'gems' but I don't see a lot of new stuff or a big variety, tech moved on but without Rails. Just accept it.

The real problem behind all these discussions and threads. Imagine there was a time, where Rails-guys were rare and Rails was the biggest thing. I had to pay such guys $200,000/yr (8yrs ago and not in the valley), not because they were outstanding. Actually, there were average, they were ok in Rails but missed a lot of other checkboxes (often devops or SQL). But the market demand forced us to pay such salaries. Rails brought them a good life and imagine demand was declining, so they had to get into other tech, start again at zero or smaller salaries OR went to forums and rant/try to convince people why Rails is so great.

> proper http/2 support in Rails-land

Between early hints support in Rails 5.2, nginx proxying to HTTP2, and an http2 enabled CDN what's actually missing?

ngninx supporting http/2 != Rails supporting http/2

Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.

nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.

> In a standard setup

What is a standard setup in 2019, there is none? There is also no standard in using nginx as front facing entity.

In my prior comment I was friendly and gave an example why some might not have nginx in their stack and BTW the discussion is about Rails lacking http2 and you try to convince me that this is expected and right.

This is pure ignorance paired with incompetence, maybe in your small world things work this way. Let's just stop here and go back to your legacy stack.

Something using AWS or GCP LBs, nginx or Apache covers 99.99% of the modern web app hosting scenarios. All support HTTP2 to the client with HTTP1.1 to the server.

This is why nobody is rushing out to rewrite Rack to support HTTP2. Ruby web apps already benefit from almost all of the advantages of HTTP2.

Well, to take on the other side of the coin:

Would you like to work on a custom-built project of someone else, decent-sized, in a language you grasp poorly?

Because that's what your "small, light system, out of large frameworks" will look like to someone who dabbles in ruby/rails and looks for a job (most of the force never reaches mastery, let alone wants to).

That's not good even if somebody is very proficient in the language. Custom projects not founded on some fairly common framework are always a nightmare. Business owners should forbid developers to go that route unless they have a permanent in house development team. And still, it should be the exception, not the rule.

Did you try Rails API? It's usually a good replacement for Sinatra apps.

Which highlights one of the bigger problems with Rails, your app _is_ Rails. In frameworks like Phoenix your application is a separate entity, completely ignorant of whatever UI framework you're using to talk to users.