[Jcampuzano2]

I never really understood this argument:

> Currently, we live in the JavaScript-heavy reality, where browser runtime looks completely different from source code files we work on.

Okay, in the article they wrote a Spring Boot server application. Does Spring Boot look anything like what actually gets run under the hood? Why did they not choose just plain Java, or hell just write the bytecode for the JVM himself - or write the actual machine code.

Of all the arguments, that one is probably the worst of them all against the current frontend complexity because we abstract literally every language in common use today for the sake of DX.

And note as complexity on the server side of applications have grown, so has the level of abstraction. The difference being backend applications had a hell of a head start.

[tshaddox]

I don't like this argument either, but in its defense, it's presumably comparing modern web page source code not to Java, but to historical web page source code.

[JodieBenitez]

> we abstract literally every language in common use today for the sake of DX

The fact that the Javascript ecosystem is not any different than the others is a huge missed opportunity.

[coffeeindex]

(Did not read the article, can’t speak to the exact argument the OP made)

I like this argument in the sense that JavaScript & HTML were/are awesome because you can learn from websites that you like the look of. You can just pop open inspect and directly see how to do something.

Modern frameworks have largely broken this to the point that it’s pretty difficult to understand what’s going on on a lot of pages

[YmiYugy]

Yes, but it's not the fault of these frameworks. If people wanted to they could ship source maps on purpose and not just accidentally. Not exposing source code was one of the early drivers for tooling.