Ask HN: Why the web lately is all about JavaScript? | Hacker News Reader

Ask HN: Why the web lately is all about JavaScript?

I read https://news.ycombinator.com/item?id=31341083 recently and feel quite frustrated because now everyone is rendering html using javascript. I'm on twitter reading web stuff, when they talk about "SSR" (server-sided rendering), 99% of the time it means javascript based server. Why these trying-to-be-innovation lately aren't not working with backend languages like python, ruby, elixir, go, rust etc?

I have an SPA app that is quite sophisticated whose WHOLE app size is ~110kB minified, and when I look at react-dom on https://bundlephobia.com/package/react-dom@18.1.0 it's 130kB minified which sounds CREAZY to me compared to my whole app (no, it's not a todo app, it's an editor app)

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

View on HN

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.

Yeah, an html attribute on <head> or <body> for not having full page reload would make a big impact.

Like htmx[0]'s boost attribute?

I've been building a webapp with Python/Django and HTMX, it works like a charm.

[0] - https://htmx.org

Sorry, I mean it should be in html spec.

I find Hotwire/Turbo/Stimulus in Rails to be a perfect low-JS approach.

That JavaScript for loading contents and images is probably an effect of Google's changes a few years ago where it was all about the load time of the main page.

So to rise up a few steps on the Google results page, people turned to serving empty pages with a small JavaScript (which finished loading fast - so bonus points from Google) which then starts pulling in the actual content.

This is a nice insight.

Dear Big-G: Thanks a lot for your hard work, you've really done something.

I was under the impression that, because Google would have to execute all of that logic in order to even get the content people are searching for -- as I can't imagine an empty page would actually rank highly for anything ;P -- that they weren't using the time of the first request but the time it took to get the content that they decided was the page.

> i feel like many people completely forgot about how simple and fast apps can be

Most web apps dont have pretenses of being simple. They want to use tools that have room for growth, that have deep capabilities.

And they want to use the really good tools & libraries & technologies that will be used on more complex efforts. Specializing in being lightweight, narrowing the scope of your skills & capabilities is less attractive than getting good at something that works & ideally will also be fast in all cases.

I think it's good to reflect nack to 2014, when React was coming out, & think of what rapid development looked like. Hand manipulating dom trees, course grained re-rendering by setting el.innerHTML,... React and the virtual dom were a huge huge performance win. Some up-front load price, but an amazing boon to rapid rapid developmemt, grossly reducing the scope of concerns one had to think about in webdev, & massively speeding up rendering/updates at the same time.

React isnt the smallest but holy shit it propelled us into a massively massively faster world. Where development is just so stinking much faster/easier, where there are so mamy less bugs & memory leaks. Thanks react.

So why focus on a niche, special purpose skill set? Why go back to hard mode? Is a 30kB preact bundle actually any kind of problem? Is a 100kB react bundle really a problem?

> 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 javascript we can often run the same code on the backend, & store & cache our documents or if it's light weight enough just render it (with already started/initialized workers). Hence: server side rendering (ssr).

SSR is very prevalent, actively supported out of the box in newer JS libraries/frameworks like Next. React has had support for "hydrating" a SSR page on the front end for a while, but required some investmemt & didnt just work out of the box.

Im very mixed here, about performance in general. On the one hand I want us chasing technical excellence, being fast. But I also see two things, one, that waiting for a second isnt the worst. Second, a huge amount of the slowness is ads and trackers, is shitty other people prpolems that businesses just accept, and developers at a company dont get much say in. Why would we spend iterations dropping load times from 2s to 0.4s when the damned trackers are still gonna make the site take 5s to load anyways?

How is developing with react quicker than jQuery for most websites?

React never made development faster.. easier to manage complex state but not faster development.

With jQuery you are working with existing state & ongoingly trying to update it. In some cases you just need to turn on and off a class, but once you start making significant modifications, things get complex. Oops, you just replaced some DOM with some other DOM that's mostly the same, but now all your event handlers are lost- so now you've got to go add yet more band-aids to re-build event handlers. There's constant inter-dependencies when you try to keep working with one piece of state.

React hides all that away. The virtual-dom just works. Event handlers all get faithfully reconnected. You never end up accidentally having multiple copies of content or having deleted too much content. As opposed to the DOM's native retained mode rendering, React gives a much simpler immediate mode rendering.

And it's often faster. It's easy to do too much work, to end up replacing more than you need to when you are hand-working the DOM. React's diffing algorithm is quite effective at doing just what updates actually needed be done, where-as before I as tech lead would have to go re-walk through my teammates code & tune & optimize it, fix some of the gross inefficiencies.

Working the DOM used to be a complex & subtle art. A lot of simple stuff you could just do & it was ok. The API was never delightful, even with jQuery. But there was so much latent knowledge, so many particulars, so many hazards. It, in my view, made even simple things much faster to develop.

If your website isn't managing complex state then jQuery will be quicker and easier. If you are making hundreds of dom changes react will be quicker.. but the average website isn't doing this. There should be complexity minimum reached before react can be used.

This is a gross over-simplification of a much harder decision to make. It depends. State can be simple & small, but it can still be hard to update your page accurately & quickly without tripping on side effects. For some tasks, this isn't a risk. For others, it's a headache.

There is no hard fast & easy rule to tell how problematic managing the DOM yourself will be. It's not about state size. It's about how much work you're going to have to do to maintain the dom, & the risk of one interaction jamming up something else. Knowing you can safely work the dom requires a blend of careful analysis & general intuition, to feel out where different concerns might collide, and you can be wrong. And adding just one more feature down the road can cause significant nightmares, blow up these assumptions. For someone else who comes along to do some work & who doesn't understand every assumption you've made about interactions, the risk compounds.

Moving from a retained mode DOM-manipulating view of the page to a immediate mode v-dom backed view such as react can save a huge amount of trouble. That just deciding & justifying your decision that only a small tool is required is complex that I'm more in favor of using React everywhere than I was before you posted: this oversimplification & overreduction emphasizes to me how particular & careful you have to be about justifying picking a less-safe tool. Simply tallying up the state you need is far beside the point. The DOM's risk has always been more about compound interactions. If you have completely isolated things on the page that only need a couple fixed features, and you never plan to grow the capabilities, maybe conventional DOM swizzling is ok. I still find it hard to recommend.

"Most web apps dont have pretenses of being simple. They want to use tools that have room for growth, that have deep capabilities."

No, that's completely false.

Most web "apps" are just text and images, and would better be thought of as documents, which after all is what the web is for. Re-inventing that out of massive piles of JS is strictly worse than what we already had, and in fact still have if only we would choose to use it.

Yeah, sure, there are definitely real app-y things on the web, and here on HN we're biased towards those as mental reference points because they're cutting edge and exciting. But those things are emphatically NOT "most" of what the web is.

I suspect (from my experience developing them) that most web apps are internal business tools that are hosted inside private networks or locked down behind login forms. Most people will never interact with them. I think these sorts of tools are the ones that the previous poster was referring to. (And they are rarely so simple as just text and images.)

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

There is a trend in OSS SW development to "continously improve " programs. This means that the program stays mostly the same but it gets over time a "gui improvement" which brings almost nothing new but a lot of libraries and bloat. Two programs that stroke me were Xaos ( which got a QT dependency) and Xsnow. Maybe jwz was right that every program evolves until it can send email.

Honestly I think a lot of what you're noticing is the product of junior frontend devs. The nice thing about HTML is that it's really hard to write code that won't load fast, but you can write SPA which load fast, you just need to be more deliberate about how you load things and what you're loading. The problem with SPAs it's easy to create huge bundles pulling in numerous large packages then loading it all in the head where it will block page render. Layer that with some poorly designed APIs and slow JS animations and you have what you're describing.

I'm not saying SPAs should always be used because in most cases they shouldn't, but a well optimised SPA should in theory be quicker and provide UX improvements to the user.

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

Yep, anything else works, they are mostly sub 10kB view lib. It's fascinating that the current situation is widely acceptable.

Solid.js may change all this.

Solid is great, and its focus on performance definitely helps. But for now I think a couple of other tools are better positioned here, as they already focus on shipping less JS to the client in the first place. For instance Astro (“islands architecture”/“partial hydration”; it supports Solid islands however!) and Qwik (“resumability”/on demand loading of interactive JS as it’s needed). In a lot of cases, just shipping less JS in the first place is going to perform better for resource constrained usage.

Solid is currently more oriented towards fully interactive SPA use cases, but they do have partial hydration (or something like it) on the roadmap.

> This is particularly the case in rural locations and developing nations.

Also in a conference / the train / the beach / driving / any crowded place / in space

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

No. This is cached if the devs aren't incompetent, the lion's share of information transfer is video streaming, not large JS files.

Data still has to get to the cache, get stored, and sent to clients. More data = more energy, cache or no.

Your point about video streaming being a far larger amount of data is of course fully valid. But I was replying to a thread about JavaScript.

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 think the problem is that javascript has stopped being one language of many and has become the language.

There are hundreds of thousands of developers now who only know javascript. They have no perception of the parts of javascript that are badly designed because they don't know any other language. They think that computers taking 500ms to render a webpage is just how slow computers are because that's how it is with javascript. They think desktop applications that use 400MB of memory on startup are normal.

People no longer weigh up the pros and cons of javascript and decide it is the best option for a certain project. Javascript is all they know, and it shapes their entire view of programming.

The kinds of devs who don’t regularly learn new languages are generally the ones you don’t want to hire.

Learning new languages is a different thing than crunching into the next JavaScript fud.

The great thing about learning more languages is that you tend to gain new skills to take back to your old projects. This is especially true for languages meaningfully different than those you know.

The same can be true of frameworks, databases and other tools.

Oh, come on. JavaScript doesn’t mean pages take 500ms to load. On my Node.js-powered server [1], pages take a handful of ms, and they only take that long because I’m doing a lot of sophisticated content management.

JavaScript has got some rough spots, but it’s a fine language these days, with a nice multi paradigm support.

[1] jamesshore.com or letscodejavascript.com — they both run on the same servers.

I'm pretty sure they're talking about client side JS bundles, not a NodeJS server that renders HTML.

Heh, good point. It’s still a silly language-wars comment, but it makes more sense.

I can stand yet another javascript critic(just boring nonsense) but, “cheap developers” ?! that’s unfair to the many brilliant people out there, people that build new stuff and create value making the best with what they have and mastering the art without being chic. And Callback hell it’s just an old argument that’s been solved many times even before promises

OP didn't say all JS developers are cheap. They just said there's plenty cheap JS devs around, since everybody and their dog these days are doing frontend dev. Some, like you say, are brilliant.

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.

The tricky part of edge compute though is write operation and where the data store is.

Never roll your own GraphQL server on core libraries. There are existing implementations with good practices and debugging tools.

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/

> 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

That and those writing JS on the frontend are, among all the devs out there, those the more likely to be working on SSR pages.

Correct. Most backend engineers today do only the APIs to be consumed by the frontend.

And there always was some sort of a separation in the industry: I remember when in some enterprisey places there was the strange role of "webdesigner" or some other (often incorrect) term that was half-designer half-programmer that only took care of HTML/CSS. Javascript was used very sparsely. There were several frameworks whose whole spiel was to allow people not to write HTML/CSS/JS.

Anyone doing both the backend and the HTML/CSS part was considered a bit of a unicorn, even back then. For a lot of self-taught people doing "everything" was the norm, but in the industry it wasn't.

Then came Bootstrap etc and sorta equalised everything. Then came Angular and React and we needed a name for people doing the HTML/CSS/JS work.

When rendering on the server became a focus again, the responsibility of writing the markup once again fell on people able to do HTML/CSS. Which means frontend developers. Which means JS.

Yeah and there also just aren't any good server side component libraries as far as I can tell - everyone is still just using fairly dumb templating engines like Handlebars and the like. At least as far as I can tell.

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.

It's "client-server" architecture for reasons though. Client and server mean to have completely different roles, architecture, languages. However, browsers just happened to support one language. There are also protocols between that.

I don't hate javascript as I write it too, but I also write many other languages. And I also think more of the web generally.

That’s not quite the right way to put it. Client and Server have different roles, yes. That does not mean they have to be written using different languages. JavaScript on the server (in Node or Deno) is perfectly fine and scales reasonably well.

If we take a step back from the most well-known client-server system (the World Wide Web) and look at other examples, we’ll find that client and server are often developed together, in a single language and similar architecture.

The point is javascript-only obsession/perspective. Javascript should be fine as well as other languages.

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

I think I get why people like it. (I am starting to like it and am falling down the NextJS Tailwind SSR rabbithole)

React is a decent framework conceptually and more importantly it has become a defacto standard for UI development in JS. On top of that the sheer amount of React support in terms of components, tooling and learning resources is immense.

NextJS says “use what you already know and use on the backend (React), and not only that we will make it seemless to use the exact same code to render an initial paint for time to render/seo as you do for live updates, and we will chuck in static site generation for free”.

Tailwind is another thing that seems really really odd, until you use it and then it seems brilliant. In a nutshell it is css classes like “m-1” for a small margin.

It would be awful for a handcrafted static site, but it works great with React because it plays well with componentizing code. If skeptical read their site where they address the obvious reasons for being skeptical.

The thing with react SSR (or SPA) is it's easier to manage layout, styles and shared components since it's all react, as opposed to html / template rendering and using react / others in places / pages where it's needed.

I love that even my email templates are now just tsx files and rendered on the server with ReactDOMServer.renderToString(). No more context switching, everything is TypeScript / React and refactoring is an absolute joy.

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.

DOM manipulation in vanilla JS is an enormous pain in the ass. You need a framework, or at least something like jQuery, to be productive,

You think? FastComments doesn't use any DOM manipulation frameworks.

Umm no?! Maybe 20 years ago. But it's trivial today

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.

wasn’t obvious? I’m not sure, thanks god flash was killed, it was a security nightmare. java applets were a heavyweight punch in the face and vbscript… well is was vbscript. not even mentioning accessibility issues of the aforementioned. with javascript the open web won luckily for us

I just had a terrifying vision of the alternate universe where VBScript became the lingua franca of the web.

JavaScript isn’t perfect, but standardizing on VBScript would’ve been a catastrophic mistake.

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.

Solid.js is very small (sub 7-8kB IIRC), very similar to React.

Yes, and I think Solid and Svelte's approaches of moving complexity out of runtime and into build time will be the most popular one very soon. But this also comes with its downsides. It complicates the build process, obviously. Debugging is harder since what you code is not what is being run at all. And they usually come with some catches like "if you use this javascript thing, your reactivity will break" kinda stuff - at least for now, but I think it can and will be solved.

The gist is; there are options and there are tradeoffs.

That's the only aspect of complaining. Size is one thing, it's also javascript for everything.

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.

I fully agree and would add: Component-oriented frameworks like React/Angular/Vue/… give you the ability to easily test your components individually (in the sense of unit tests or integration tests or manual tests / storybooks). Most classic templating languages for the backend don't offer anything similar and doing that would also be quite challenging: Most of the time the backend controller rendering/populating a given template is deeply entwined with business logic and database calls – good luck separating those concerns after the fact.

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

There is a javascript size usage graph yearly .. I don't have a link bookmarked but it's getting insane. Note that 130kB is without starting writing any application.

Yes no one cares about the JavaScript bundle size until it becomes a problem.

I prefer not to create problems for myself.

Sure, but it’s more challenging to keep the bundle size very low for no reasons if you want to use modern tooling and work in a team. It’s fine for your personal hobby website, but people at work shouldn’t waste times and create problems to avoid a small and rare problem.

The amount of friction a designer gets for adding several multi MB images to a page, in every organization I've worked for, is very little.

2 MB minified, compressed, ball of js is nothing. I've even seen companies accidentally put their debug builds in production (>15MB js ball) with without noticing or getting complaints.

I'm much more sensitive to page weight than most, and every sizable dev shop should have someone who is. But even I realize that current business reality is it didn't matter nearly as much as sensitive tech people think.

You not just count the js framework. All parts of a website contribute to the bloat. Things get exponentially slower for each thing added.

I will for example "excessively" test how many images in what resolution I can get away with. Is my json to big? Can I use a custom font? Do I need to start the "infinite" scrolling fiasco? In what order are things loaded? Are we requesting a html document that when parsed has us request a js file? Is its execution delayed by the dom state? Then it parses out html? And then that html requests media that loads lazy?

If I would find myself there the 130 kb (and its overhead) would persistently bother me. When I get to it it will get ripped out and replaced with inline vanilla js.

It's not just that I want my application to be snappy and appear instantly. I also want to see instant results when testing it. There is no build time. It doesn't exist.

Are you implying that it's okay for a web app to be unusable by people in remote areas unless it's specifically designed for them?

It’s not unusable, just a bit slow to load.

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)

Phoenix as well with LiveController. It’s impressive what can be built with minimal JS while being pretty responsive and snappy.

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.

True, start innovation with javascript will not lead us to anywhere because the design is not going to be generic enough to form an innovative pattern that can be used everywhere. It's called "client-server" arch for reasons.

We could do client-client

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.

Which is funny because I recall SSR was how one referred to non-SPA websites. Anyway, the new term seems to be server side generated SSG.

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

I think you meant https://htmx.org

Reading over the Hotwired homepage, I honestly thought it was a funny parody like http://vanilla-js.com Turns out it's an actual framework!

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.

react-dom is pretty much a sole purpose, there is no subpackage or its form of plugin. So shaking out unused functions isn't doing much since it's supposed to be * imported anyway.

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.

So do I. But ... at home for my own projects I use language and tools I like (Common Lisp, Clojure...) At work I use whatever I get paid for. I recently left Java job in favour of a Python one because they paid me more. You know, Python hackers hacked together something then left and they realized they need software engineers, not hackers.

Python is not a bad language (compared to JavaScript). Python interpreter is a piece of shite and the culture and common practicies is what sucks the most. People praise NumPy, Pandas, Flask etc. because they don't know anything else. Anything better. At least they don't have to pay for this.

I dislike Python too. But I use it because I have to - a lot of the stuff at work is in Python.

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.

Literally break the mantra "the right tools for the job". Now it's everything is a nail.

Nailed it!

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

All you need is a tiny view lib like lit-html/uhtml, and event dipatcher (DOM element can do that, or use bare EventTarget), now you get a MVC pattern loop; event fired -> state changed (+ optional effect) -> re-render.

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

I used Liveview before (on very early version), now I use PhoenixChannel and javascript, it's great balance.

Same here. Mixing ui and data logic layer was not pretty. Alpine js didn't cut it for me.

Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.

The rather massive weakness of that approach is that it requires a functioning internet connection to do anything, and is badly affected by latency. If you lived on the other side of the world from the server and had a sometimes-unreliable or -unavailable internet connection, you would not sing LiveView’s praises so loudly.

You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1] if Phoenix.LiveView.JS [2] is not enough)

[1] https://alpinejs.dev/

[2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...

The problem is that LiveView forces synchronous operation, whereas a significant fraction of things that would require a server trip anyway could actually be done asynchronously—that is, as far as the UI is concerned, they actually don’t require a server trip; not immediately, anyway, and the UI should only care about the immediate.

When you control server interactions on the client side, you can do things like optimistic editing, where the UI assumes the action will succeed and then does it in the background, and then handles the exceptional case where something goes wrong, most likely by returning you to a form; or things like queuing actions up when there’s no internet connection, and performing them when you get a connection again.

I want to emphasise again the importance of latency. I live in Australia. Most of the web is much slower in Australia than it is in the USA, not because of bandwidth, but because of latency.

The LiveView approach is convenient, but it’s technically not a good solution for most applications. It’s excellent for things like chat systems where being bound to synchronous operation and requiring a network connection to do things isn’t an issue, but I honestly don’t think it’s the best solution (technically, again; socially it may be) for much else.

How many apps have you written that should work offline? Because in my career it might have been less than 5% of projects. It's fine to optimize for the remaining 95%. My client's CRUD app doesn't need an offline mode. It would be nice, sure, for that one time the boss is using the app on a plane, but it's towards the bottom of the priority list.

95% of projects, I'd pick productivity over working offline, especially these days when being truly offline is more and more rare.

And lastly, even in JS, offline support is a pain in the arse, not a given. You have to design your entire app around it, it's not something you can add 2 days before shipping.

The trouble with the thin client approach is that fundamentally no control is possible on the client-side. Since the connection from client to server is unreliable, this renders such pages unnecessarily fragile, considerably more fragile than traditional server-generated pages with conventional navigation by link and form. Really, I’d say that in most places where people are inclined to use the thin client approach, they’d be better served by traditional server-generated pages with no overriding of client-side routing or other such fancy scripting.

Have you experienced this type of thin client when you have half a second’s latency, or a connection that keeps dropping out, or moderately high packet loss? I don’t think I’ve actually encountered a full thin client in the wild, but from my experiences with other poorly-done (very common) network-bound web apps in such circumstances, I can report that things are considerably worse than one would expect—that half a second’s latency inexplicably leads to things taking several seconds instead of fifty milliseconds a lot of the time (though I will admit that a pure thin client is less likely to find this so); and that very brief dropout manages to lock the page up for ten or thirty seconds until it manages to (or decides to) reconnect, or just breaks your page completely so that you have to restart and lose progress.

I have worked on apps that work offline or partially-offline, but the problems of the thin client approach are so much more than that—which is why I didn’t use the word “offline” in my earlier comment. Prefetching. Caching accessed entities so that you can revisit them without talking to the server. The bfcache, once you’re talking about simple pages rather than apps. And various more things, some of which I spoke of in my other comment here.

The thin client approach is a nice idea. It can be suitable for tightly controlled deployments. It can be suitable for a very restricted set of apps. It can be a pragmatic choice sometimes. It will tend to be better than a badly-done client-side-rendered app. But I am convinced that it is not very often the best choice, taking into account both user and business considerations; and that for consumer systems, it’s rarely a good choice.

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.

Wouldn't companies doing government-related work have minimum accessibility requirements ?

And wouldn't it be hard to deal with all of them (starting with the quite common eyesight problems, though I guess browser zoom is mostly JavaScript-compatible, and red/green color blindness) without ensuring that the core website functionality works without JavaScript ?

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

It's enough for them to know that https://twitter.com/POTUS loads in half a minute, while https://nitter.net/POTUS loads almost instantly. Despite both being the exact same content!

I doubt that, for example, my parents would know that, or care. My wife definitely wouldn't.

Honestly I use Twitter occasionally enough that I've never even considered going to Nitter.

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.

> From a business perspective developers are a cost center, not a revenue generator.

If you work at a company where the software you write isn't what generates revenue, you're going to have a bad time.

There are plenty of companies where developers are the profit centre.

Agreed, it is unfortunate because there is some cool prolems to solve in places where software is the cost centre but it has never been worth it. In my experience, the irony is that places where software is a cost centre often run really inefficiently from a software developmemt point of view. So it's more costly and less funded, it can be difficult to pull even the simplest projects off in that environment. I am sure there are places that run well though, you just have to have the right people up the chain.

I had seen a lot of devrels meme pre-covid, now they seem to come back.

> Developers are typically viewed as a disloyal disposable commodity [...] Financially that reasoning makes sense but economically it’s stupid because you will end up with the same shitty uncompetitive product as everyone else.

Which has always been my answer to over aggressive management strategies for "replaceable devs": If your product is fundamentally software, it will be as replaceable and disposable as your developers; Show some commitment instead and you will get it in return from worthwhile devs.

I mean, you can’t close your eyes and spit anywhere on HN without someone chastising someone else for sticking with the same company for more than two years. Disposable developer culture is perpetuated by all sides.

I absolutely hate it, why do that?

Moving can double or triple your paycheck overnight. If you're not learning, networking, or growing, fire your employer.

I think this behaviour can also be inline with the other side of the problem though:

Employees perception of growth: it's easy to feel like you are learning more when it's something brand new because of how easy any topic is at the beginning, and you inevitably get more new things when moving; whereas pushing your existing abilities and strengths into incrementally more advanced areas is harder won and requires more fortitude. Also focus on short term financial gains over long term career growth: Although jumping ship has a tendency to force a re-align of financial reward with ability, it also resets your progress reducing your experience on long term project and denying yourself to opportunity to learn from the long term consequences of your decisions, which in turn can affect your long term prospects and financial rewards. (I am suspicious of candidates with a employment history of a series of short stints for this reason, because they did not have to live with the results of their output).

It's subjective, sometimes it's truly not worth staying, sometimes it is... but I suspect many people confuse short term gains with reasons to move, when their current job may in-fact be of more mutual benefit long term.

Right but the reason for that culture is because businesses refuse to give competitive raises. I actually tried to stay with my last company but after my two year mark I was way more valuable than my current salary. I told my manager that, they agreed, said they wanted to keep me and asked for a number. I said what would have been a 60% raise and they literally laughed in my face. So I quit and in a month I got a 100% raise. Like it’s not like I had some inflated ego, over the next 6 months my entire team except for the guy on a work visa did the same thing.

340kb is quite impressive for an OS, it seems browser/web has a lot of great apis that are underused.

> Financially that reasoning makes sense but economically it’s stupid

What’s the distinction you’re making here? To me it looks like you’re contradicting yourself, but I’m happy to admit I might be ignorant.

They mean short term financial gains vs long term economic success

The solution is to separate creators from maintainers. You don't pay your janitors the same as your architects. The way we get there - standardization.

An interesting thought - it is so much easier to learn to contribute good code to an area you’re unfamiliar with when the codebase is already beautifully designed.

It’s a teaching tool in itself. You can essentially hire a janitor and make them an architect when everything just makes sense already and guides them in the right direction.

Agree 100% though also sadly, I wonder if in practice website quality matters. Consumers are used to laggy shitty UIs and assume the problem is their 8-month old hardware.

Of course eventually poor products are unusable, but I wonder if position on the barely-usable-to-snappy generates much revenue differentiation.

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.

Does that mean abstraction leak from inside out? (No, not outside in)

Easy to find javascript programmers for common tasks.

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.

Exactly.

And if one really needs a slimmer version of React, there's always Preact [1] which is 3k-4k gzipped and has pretty much the same API.

Of course, in real life the 130k of React is far from a problem. The React code is (more often than not) dwarfed by the application code itself.

[1] http://preactjs.com

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.

Reply on news.ycombinator.com