Why the web lately is all about JavaScript?

I feel like many people completely forgot about how simple and fast apps can be if there aren't tons of layers put on top of one another.

Like you have drupal with bunch of modules, it's slow as hell so you put redis caching. It's faster but not as fast, so you add varnish on top, so you don't even have to touch the php code unless you make a change.

But then you've never solved the problem, you just hide it two layers deep.

And same with javascript - 85% of sites are visit would work perfectly fine without any javascript. Loading would've been instant, and you don't even need ajax if you can spit html document fast enough - the browser makes it seamless anyways. But no, instead, we do animations and slow down the time to interaction because it's fine sitting on 1Gbit connection waiting for your slow backend part that's not cacheable.

JS isn't bad, it just feels like people think it can solve anything while not seeing issues it adds.

Fully agreed. Two aspects that I don't see acknowledged often enough: (1) Not everyone has fast internet. This is particularly the case in rural locations and developing nations. We're witnessing internet inequality and heavy websites are fuelling it. (2) Information transfer requires fuel and burning fuel is destroying our habitat. It might seem trivial to shave kB off download sizes, but the cumulative effect of large sites doing this should be acknowledged and encouraged.

My reaction to this ridiculous situation:

Use Preact instead of React -- I'm planning to switch to Svelte next -- and using minimal dependencies and writing my own minimalist implementations where feasible. I need to get better at this.

Use code-splitting and lazy loading to keep gzipped download under 100k for all content per "page".

Avoid web fonts, images, tracking, 3rd party crap, cookies, advertising, etc etc etc. I'm lucky enough to be in a position where nobody is telling me to put this stuff in.

Tree-shake, minify, compress (brotli if possible). Sure, it takes processing power to decompress at the other end, but my suspicion is overall compression wins. Happy to be proven wrong.

User-test everything on a throttled connection at 3G speeds. Or "poor 3G" or whatever the browser dev tools have. This is subjective, of course, but gives me a good sense of user experience.

It's not a perfect recipe, but downloading megs of crap for a web page is totally unacceptable.

(Obviously all the above side-steps the "no JS" perspective.)

Dunno. But i think JS has actively harmed software development in the past 10 years. It's a bad language, designed and patched hastily that does not work well with humans nor machines. It took 10 years to allow having some form of synchronicity with promises, and that's just disguised callback hell. Callback depth is an inherent human limitation, because our working memory is very limited , so I consider JS a language that s unfit for humans and unfit for big projects.

Silicon valley adopted JS probably because of ease of access to cheap developers. Pity there is not a serious competitor from another Valley because i think they could beat them with superior performance in just about anything.

I have learned all the frontend frameworks (though my React is pretty shitty) and have come to the conclusion that I much prefer just rendering HTML with html/template.

The thing that led me to using the SSA style initially was that it seemed easy to write a backend and then bolt on a frontend. But there isn't actually a good transport layer for that, and the API for your web app and the API for API users usually end up being quite different. I think that GraphQL is intending to be the transport layer that just works (and since it's a graph you can query, theoretically means you don't have to write an API for your web app, teach your web app how to incrementally request things, cache things, invalidate that cache, etc.). I have found that ... it's not that great. The Go libraries for a server are terrible. There are no debugging tools. You send gigabytes of JSON for no reason.

My personal favorite API is gRPC-Web, but I guess browsers never added the hooks necessary for bidi streaming, and the "tree shaken" protos + gRPC-Web runtime are HUGE, so I've decided it's not worth being excited about anymore. I typically stick grpc-gateway in front of my gRPC services and get normal RESTful JSON. And then I'm at square one where there isn't any magic in React to make that particularly useful.

Anyway, yeah... just printing out HTML. Not that bad. Use fly.io and put the server close to your user and they won't even notice that it's slightly higher latency than caching everything in your SPA. And it sure is easy to debug when something goes wrong.

I think this is largely because people are writing JS on the frontend, and it's easier to do SSR with the code you've already got, i.e. render JS on the backend too.

That said there is a movement for a more flexible style, e.g. https://htmx.org/

The term "Server Side Rendering" generally refers to client-side frameworks which have been adapted to server-side. These have been nearly entirely JavaScript for obvious reasons.

Frameworks that generate HTML on the server side have been around a long time, but are mostly not considered in this category. I would say though there are a decent number of modern ones in the "static site generator" category that exist in many languages.

It makes sense to me that in the current iteration of web tech that the client code and the server code be mostly in JavaScript since it allows for a single code base between the front and backend. There is definitely hope for other languages in this space though as WebAssembly gains more traction.

As for the bundle size of an app, it's not too surprising that a bespoke app would be smaller than a modest framework. Choosing a framework will always be a trade-off of size, complexity and whatever features the framework offers.

I think wether you see it as "suck" depends on how much you love or hate JavaScript and how tolerant you are to using modestly large frameworks. Mostly, I see the modern crop of JS frameworks as a breath of fresh air compared to what precedes them, though the complexity of what is imported when running an `npm install` is enough to give me pause and a wish for something more minimal.

I am a front-end developer and a Javascript veteran. While I do hate the "hate" against JS, even I think using JS on the server for rendering to HTML is a terrible idea. It doesn't scale, it isn't natural; it's just convenient and taxes the end users.

My solution for that is to liberate UI programming out of a single language, using WASM as the abstraction layer. For more information https://github.com/joelewis/kwasm

My vanilla JS app is way smaller than your fat app. JS doesn't automatically mean massive frameworks and libraries. Just write vanilla from-scratch JS like I do and life is fun and happy.

The obvious reason is that Javascript is the only language that runs on most browsers (outside of Webassembly, which has its own limitations). If you want to do anything interesting on web browsers, you will have to deal with Javascript.

A more interesting question is, why is Javascript the language that all browsers support? Go back 20 years, and it wasn't actually obvious that Javascript would beat out Flash, or Java applets, or even VBScript to be the main way to get interactivity on websites.

there is a growing reaction against the JS-everywhere situation, using hypermedia & HTML over the wire rather than JSON data APIs

I am calling these applications Hypermedia Driven Applications or Hypermedia Oriented Libraries:

https://htmx.org/essays/hypermedia-driven-applications/

libs like unpoly, hotwire or my own htmx are all hypermedia oriented, recentering HTML and hypermedia as the core application architecture for your app

some other related essays:

https://htmx.org/essays/spa-alternative/

https://htmx.org/essays/a-response-to-rich-harris/

the really nice thing about the hypermedia approach is that it takes pressure off adopting JS/TS on the backend, since you no longer have a massive front end codebase already in JS/TS and it can be hard to justify having two different languages, models, etc. With hypermedia, you don't have this situation. I jokingly call this "stack" the HOWL stack: Hypermedia On Whatever you'd Like.

To your second question about the app size vs. framework/library sizes:

Frameworks and libraries provide generalised solutions to some common problems. In react and react-dom's case it's defining a ui in a declarative and more or less performant(wihtout making the dev think too much about it) way. The downside is; it includes lots of things your app doesn't need but other apps do.

The alternative is to roll your own but if your solution did all the things that the X framework did; then you'd end up with a similar size/complexity. You can build the features only needed by your app; but then I can't imagine the amount of engineering hours wasted for every apps custom framework.

And nowadays ~110kb is not that big of an application really. It might be really complex in terms of concepts and what it does but current day apps are a lot bigger than that in terms of size. So the size of frameworks doesn't make that much of a difference in most cases. For example the app I'm working on in my job has a total bundle size of ~15mb minified excluding any third party code. This is just the code written and being actively used by us. We don't serve it all at once and load as needed but still.

One of the core propositions of Javascript SSR is that you can write everything in the same way. If you have your data at compile-time, great, it can get prerendered and bundled. If not, it can be rendered on the client, the code you use it the same. You can share the logic for both, same components, same layouts, same business logic etc. You can have initial data rendered on the server and then live updates one the client side without any additional work around templating and business logic.

Obviously, there are ways to write the same page and end up with a smaller bundle size, but size is only one dimension. Javascript SSR offers (arguably) less development time and less maintenance (as there's simply less code since you handle both the same way) at the expense of other things, such as bundle size etc. As with any other tradeoff, you can't only look at one parameter and say a thing is good or bad, you need to look at the whole package and figure out whether it makes sense in the given context or not.

1. Only JS is already in the browsers. 2. JS is simple.

These are the big killer features and selling points for it's crazy adoption.

But fortunately with the raise of TypeScript, which solved many of JS original traumas and made it team-scalable, it's not that of a big deal.

In the end it's not about "trying-to-be-innovation", it's about money.

Yes, it may be much faster and more appropriate to run some code on Go or Java. But often the difference in salaries and time to market (see selling points above) can't justify that decision.

I personally witnessed the benefits of migrating from Scala to Nodejs in a big company, and I'll definitely vote for Nodejs next time in similar conditions.

It is the present. We try to maximise the features and reduce the cost. For example, no one develops apps in assembly by hand anymore, it’s not productive.

130kB minified is nothing unless you make an app for people in Africa or very remote parts of the world. It is cached and is loads instantly on most connections. Check the network speeds of your users, it’s very likely more than fast enough to load a 130kB file once.

https://en.m.wikipedia.org/wiki/List_of_countries_by_Interne...

Rails is sort of fighting against this. It's trying to hide or remove as much JS as it can, with http over the wire. Still some JS, but not visible to the dev (unless they go after it)

Been doing web development for 25 years, I am currently learning Rust in hope that I can compile to Web Assembly and build SPAs that way. The JavaScript ecosystem is a mess of module systems, type systems, layers upon layers of libraries and build tools and building a web app that is actually maintainable, consistent and extensible is difficult to impossible. We need better tooling than what is currently considered standard.

everything is fine. i’ve gone full spa[1]. i don’t think i could go back.

my starter project is here[2]. backend is go on lambda. frontend is clojurescript with react and mui, compiled down to a single html file with js inlined, and pre-gzipped.

lambda zip contains two files:

- ./main

- ./index.html.gzip

the backend returns the index for any route not beginning with /api/.

websockets and http ferry information between frontend and backend. s3 and dynamo persist data. ops are easy. sdlc is fast.

frontend runs local and instantly reloads. backend reloads in 1s. if you have bad upload bandwidth, do backend builds on an ec2 relay for $5/month! or just tolerate 10-20s backend reloads depending on your bandwidth.

sure the index is a bit heavy, but if it’s not annoying to use on a phone over cellular, it’s probably fine.

have most react devs seen the regeant[3] interface that clojurescript devs use with react? it’s so simple and hasn’t changed in a decade!

i start all my projects this way now, and am so happy. i can’t imagine a better workflow.

1. https://gocljs.nathants.com

2. https://github.com/nathants/new-gocljs

3. https://reagent-project.github.io/

I’m kinda done with the JS-heavy frontends. I started my career as a nodejs developer, and spent a lot of time in SPAs in the backbone/angularjs days. The current template at my work for creating a new typescript/react UI is ridiculously heavy (to me).

I’m working on a new project that is using F#/Giraffe, with the Giraffe view engine. It’s using htmx to update content without a full page reload. I love it. It’s been the most fun I’ve had developing a web app in quite a while.

Though we had that discussion recently, I will again point out that, from how I see it, the term "SSR" does not include/refer to classic server-side applications like PHP, Django, ASP, whatever. Instead, it is used specifically to refer to single-page applications, rendered on the server. Nothing else.

If you search for SSR, you will not find PHP, Django, ASP.

Yeah, that sucks. So much that there are people building tools to avoid that approach. Take a look at these:

- https://htms.org - https://unpoly.com - https://hotwired.dev

There’s a lot of discussion about developers and business drivers. But remember things like React and Angular hsve been around for a decade or maybe a little more.

At that time flash was on the road to sunset (but still a thing - YouTube was flash then), and mobile devices were still in hyper growth mode. Browser makers (well Google and Apple) were investing alot of resources into making JavaScript more performant.

In my mind, it’s a no brainer. You want to deliver rich client experiences without proprietary hooks like Flash and Silverlight. The most heavily resources engineering orgs on the planet are focused on making JS fast… the smart strategic bet bet is to bet on them!

> Is it just me that interpret this situation as "suck", or this is the future

First, there's room for everyone. Plenty of other trchnologies have are & will happen. But JS has by far the biggest, most boisterous & complete web ecosystem. By far. And a huge amount of the ecosystem works just as well front end, back end, and thanks to AssemblyScript, both at once (portability: a huge advantage).

As for "just me" / "suck"... other people also turn up their noses. But largely these are legacy preconceptions. JS didnt used to have robust serverside stories (altough I did write some JScript a long long time ago...), didnt have fast runtimes, didnt have a package ecosystem, and so yeah JS didnt fit. But it's grown evolved & gotten fast.

Much of NodeJS's history stems directly from Ryan Dahl comparing python web framework's performance,... and finding them wanting, thinking he could do better. With a performant async server, with Isaacs developing npm packages, things quikcly took off.

Some poeple dont like JS the language. I have less clear ways to refute this, since it's almost entirely ill defined bias & personal opinion: you cant really argue with someome who says "i dont like bananas" & thats about as far as these discussions tend to go. JS ticks all the boxes for a great & capable way to write server side code. It's still the way to write front end code (although wasm Component Model (nee interface-types) is finslly happening & will make other languages much more viable).

> when I look at react-dom it's 130kB minified which sounds CRAZY to me

As for react-dom, well, it's magically good stuff. It's worth it. Having immediate mode style rendering, having deep deep control over the front end, but not having to swizzle dom: it's a huge accelerant. There's preact & other "lite" takes that work similarly. I suspect react-dom might tree shake & get smaller for many deployments: bundlephobia can mever detect or understand how much code you will end up not shipping.

Also, this only really should affect first load & occasional library updates. clapping: it. just. doesnt. matter.

Simple: ads and personal data collection. The more developers get convinced they need JavaScript everywhere, the more these companies benefit from accrued data collection opportunities.

You don’t have to like it.

I do a lot of data science in C#, and absolutely loathe Python.

I am not the only one who thinks that the ubiquity of Python sucks but I am certainly in the minority.

I’ve stopped caring.

For me at least its due to JavaScript having more mindshare so it’s easier to hire people to work on both the front and backend if they’re both written in JS.

I keep using JavaScript on the back-end because my projects all need rich front-ends and switching between + keeping my skills fresh in two separate languages is an awful lot of friction.

I anticipate that the WASM ecosystem will mature enough that non-JS front-ends will become standard fare, and then I'll be delighted to pick a back-end language where stack traces actually include lines for code I wrote.

What did you write your SPA app in if you dont mind my asking.

Web apps and "full-stack" is not my area. Based on what I have read online I was under the impression that it is all Javascript and ver had a motivation to learn it. I would love to know how to create a web app - user interface to back end server code - without node.js, React, Angular etc

I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.

There are upsides to both approaches. I joined my company, which uses react, and I was productive within a few days because I know react well. Would I have the same easy onboarding experience in your hand rolled app? Maybe. Maybe not.

What's your testing story like in your hand rolled app? Do you have test for your atoms, molecules and organisms?

How well does your tooling support your code? Popping into a framework means you get to benefit from all the productivity tools that have been built around that framework. Rolling your own anything always means forgoing many conveniences to the developer and possibly the user.

The vast majority of people who use the internet don't know what JavaScript is, and especially in the US, most have no reason to really care about bundle size. No company is going to optimize for the very small group of people who browse with JavaScript turned off. Instead companies want to optimize for speed of development, testability, stability, ease of onboarding, etc.

The business reason is to simplify candidate selection to a narrow common criteria and never invest in training. Developers are typically viewed as a disloyal disposable commodity. From a business perspective developers are a cost center, not a revenue generator.

Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else. The developer counter argument is to just raise salaries, but over that past 2 years salaries have exploded and yet businesses have doubled down on this idea of prioritizing candidate selection and no training.

To your point about code quality I agree. I have an OS frontend written in JavaScript that fully loads (completes page render with state restoration) in under 200ms according to Chrome’s performance tool. The code is about 340kb unminified. You won’t that with React.

As the client gets more computing power relative to the server, you would want to harness that. Hence more programming is moving client side and JavaScript is the dominating language / platform there.

Actually the delight of it is most of our developer tools now are powered with go-based and rust-based binaries that speed up our iteration processes. For example, esbuild, typesense, etc.

There's probably multiple factors at play, but one small factor I'd like to introduce is how there's way more tutorials for learning Javascript than say Rust.

Economical reasons come into play with software engineering.

CSR rendering is fundamentally great. when done right, it enables complete separation of concerns between the frontend and the backend, and it will vastly outperform the SSR approach in terms of performance

>react-dom is 130kB

the goal of these tools is not building performant applications. the goal is enabling barely skilled laborers to churn out disposable shit as quickly and cheaply as possible

>I'm on twitter reading web stuff

do yourself a favor and don't.

it's cheaper to run your app on the client than the server i guess.

the reason why i have 3 tabs open using 3gb of ram.

Look at .Net Blazor for a non JavaScript solution.

java / javascrip is a hell its starts as fun until you do it a few years. there is a wow factor in all web tech its best to choose something stable and less wow, stick to proven reliable maintainable and proper coding design.