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.

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

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.

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.

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

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

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.

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 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 ;-)

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.

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.

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

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

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.

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.

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

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.

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.

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.

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