And the result, of course, is an unmaintainable stack of dependencies and inefficiencies. Any time anything changes, anywhere, the whole thing falls apart again.

Security folks talk about "threat surface" - I wonder if it would help to have an idea of "development surface" to signify the risks of bloat and dependency chaining?

Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack allows modules to specify their styles in JavaScript to allow compossible CSS for each given page.

Yes this is still using a couple of frameworks, but I personally prefer the approach of a lightweight standard library to the everything-and-the-kitchen-sink approach that other languages have.

That comes at a cost, namely when someone has a special requirement, then that person has to dig very deep into your framework.

It's almost the same like Java GWT or Vaddin. If you stick to the recommended way, everything is just fine, but don't ever try to solve some exceptional problem because then you are in a world of pain where it's just smarter to embrace JS and CSS.

The problem is, abstracting things away doesn't make them disappear, because WEB DEVELOPMENT IS BROKEN BY DESIGN.

I never used your app nor do I know how it behaves, this is just general speaking about the scenario when people try to 'abstract' things away, I hope you understand that I'm not speaking about your app but the idea of hiding things.

The sames goes for all those frameworks who tried to hide HTTP ( I'm looking at you asp.net and some older Java frameworks ), this lead to a pile of shit, newer frameworks accept the fact that we use HTTP and we got less problems by doing that.

Since you mentioned ORM's, it's called the Vietnam of computer science[0], everyone tries to hide SQL, if you are doing some basic CRUD applications everything is fine but if you need more sophisticated queries you are already fighting the ORM which is supposed to help you and not making you developer life miserable, we don't need another DSL for databases, SQL is already the best language to make queries.

I guess, what I'm trying to point out here is that I use those simple tools because I know my way around, I know how to debug it which wouldn't be possible with some abstraction.

[0] https://blog.codinghorror.com/object-relational-mapping-is-t...

I haven't done it myself, but you could try to replace most of your stack from the database up, with a single language:

http://www.swi-prolog.org/FAQ/PrologLAMP.txt

You'll still need the three stooges but at least you'll have a single language behind them.

If you're going to call HTML a programming language than when you talk about server-side work you must include XML as a programming language (I see markup far different, more simplistic than a programming language). CSS is simply properties applied to the same markup but I digress; I could see the argument argued either way.

Regardless, you can minimize what you're saying down to just HTML, CSS and a server-side language. You can make good applications without a single line of JavaScript and depending on your purpose you may not need persistent storage in the backend. In fact you can write an entire web application with just HTML, CSS and JS if you want and have no backend (beyond a CDN unless you want to be super pedantic and call that a "backend" but I think that would exceptionally overstate what it does).

> And then come the (leaky) abstractions on top of them:

God, you don't need any of these. JS isn't that bad anymore. It's actually kinda nice in some ways. Same with CSS it's rather easy and there are far lighter projects than bootstrap if you want to do minimal stuff, quickly (but there isn't any reason you can't look at tutorials if you're new and get a CSS layout working pretty quickly sans framework).

For server side this depends on your language. Node has a great built in http capability that many seem to ignore (it's quite easy to write your own web server using it; in fact it doesn't take much more code than plugging into express or hapi). Alternatively other languages have even better, built-in ways of handling server-side logic.

> ...and often...

Ugh, SQL is so easy I don't understand why people even bother with these. Every single time I've been involved in a team that used these abstractions it worked great initially and then steered us off a cliff in the end.

Just don't. RDMS is easy.

five languages in 7 lines of code -- how now to do web development : https://news.ycombinator.com/item?id=492321

We might need less abstraction, and let the engineers work that out.

Front-end on the other end is a mess. JS/HTML/CSS as tools are clearly unfit for the current needs.

    * JavaScript (client and server)
    * Redux (state management)
    * React (UI Control framework)
    * MaterialUI Controls (toolkit, one of many)
    * JS Friendly DB

Five or six competing frameworks that do the same thing in different, incompatible ways, because either the guy who understood EXT-JS left the company or one group like jQuery better than DOJO and they both went off to do their own things only to be brought back together later.