Hacker News Reader

Comment by eplanit | Hacker News Reader

Stop including megabytes of javascript in every page, and composing pages from 100s of requests to microservices. In short, keep things simple.

View on HN

Maybe don't make autoplaying videos? Those must use up bandwidth, maybe more than javascript. They also use power to decompress on client side.

I find it disappointing that so many sites pull down so much JS that a video maybe uses more bandwith.

It’s a fascinating failure as an industry - there is a ton of infrastructure around media optimization but our attitude about adding JS dependencies has been “there’s always room for one more”. I’ve seen more than a few cases where someone loaded an image optimization library where the JavaScript used more transfer, CPU, and memory than the original images, as if this wasn’t one of the easiest things to measure.

Here are two utterly trivial examples of some JS;

    for (let x=0; x < 10000; x++) {
        if (x===0) console.log(x);
    }

versus

    for (let x=0; x < 10000; x++) {
        if (x===0) {
           console.log(x);
           break;
        }
    }

The second one is more code but much more efficient. Having a smaller amount of code doesn't translate in to having faster or more efficient code.

This is the basis of most optimization work - you're optimizing code to do the minimum amount of work, and very often that means writing more code. A moderately complex React/Vue/Svelte app will be much more energy efficient than a naive vanilla JS alternative because most frameworks to clever and hard things to reduce the amount of work that's done in order to increase performance, and a side effect of that is using less energy.

If you write it from scratch you could just get straight to the point with

    console.log(0);

It's an incredibly trivial example. With real world code you can't always do that. I hoped that would be obvious.

It was pretty obvious...

With the code above, an optimizing compiler might actually produce this line.

> A moderately complex React/Vue/Svelte app will be much more energy efficient than a naive vanilla JS alternative because most frameworks to clever and hard things to reduce the amount of work that's done in order to increase performance, and a side effect of that is using less energy.

I would debate this, the black box abstraction provided by react, et al. would probably wipe out any performance benefit.

It's all in how you write the code. I've (as an end user) muddled through tons of slow react apps, and used some highly performance vanilla js (or just "framework-less") apps.

React is not an abstraction, and to be honest the fact you are calling it that kind of makes it easy to dismiss your post here.

But you are right that it's mostly all down to how you write the code. But I'll gladly argue that it's a lot easier to write bad, inefficient UI code with vanilla JS than with React.

You don't really get to see the alternative because generally, react makes things so much easier and efficient that it opens a lot of doors and allows companies to go crazy with features and bloat. By being the beast it is, it puts a lot of power in the hands of developers, but equivalent UIs without react will most likely be 3 magnitudes worse. Keyword: equivalent.

Similarly, asymptotic complexity is not always an adequate approximation of energy consumption.

More code leads to more cache misses. More code leads to more energy consumed transmitting that data over the internet, and wireless radios are energy-expensive. More code leads to more time parsing, compiling, optimizing, and then JITing code, which can utterly dominate actual runtime energy cost if the program is not long-lived - which describes a lot of webpages.

Finally, very few webpages actually need to even be a "moderately complex React/Vue/Svelte app" - the essential complexity to the task being done is low, and webdevs add extra, unnecessary features for very poor reasons (showing off?). Take https://nabeelqu.co/understanding for example - 1.17M downloaded for 21K of text and two small images (one of which didn't load anyway). There's a 276K JavaScript file in there, among others - and the primary purpose of this page is to display a static document. Or, take any modern newspaper website you want - bloated with images, tracking, and JavaScript providing near-useless (and probably near-unused) features with a data-size:content-size ratio of over 100. If something is moderately complex, it would be much better as a native app in the majority of situations, which comes with significant performance improvements.

But the simplest thing to do would be return after logging 0 rather than loop thousands of times for no reason. By that I mean, the second example in my eyes is simpler.

The simplest code as you point out is often faster than the shortest.

But what should we do when things are actually complex?

There is a lot of negativity here on HN on the same things you mentioned, but I fail to see any viable alternatives.

Like what? Replace the MB of JS with plain Html and forms? It's not going to be simpler to code, and it's definitely not going to be simpler for the users. Or maybe use a native desktop app? Then it's even more complicated for the users, and coding it leads you in world of cross platform pain. And the closest thing there was to not using MB of Javascript and have decent UX was Java and applets/jlnp, but it somehow didn't manage to be widely adopted.

Shot in the dark here, but perhaps you could try leaving the functionality the same and just try taking out all that code that tracks every pixel the user looks at, for how long, and how they can better market porn to that user...seems like that stuff could be taken out...

I wonder what the economic impact of doing that would be.

If everyone did that? Probably very positive in terms of energy and resource use, positive in terms of less things to worry about for the businesses - and very negative for all the bullshit adtech jobs that wouldn't be needed anymore.

So strongly positive, in other words.

One has to remember that marketing and advertising have a big negative-sum-game component going on, where most or all of your marginal effort to promote your product serves only to cancel out the marginal effort of your competitors to promote their products.

>If everyone did that? Probably very positive in terms of energy and resource use, positive in terms of less things to worry about for the businesses - and very negative for all the bullshit adtech jobs that wouldn't be needed anymore.

It's not just the annoyance factor, it's the bloat from ads. In fact, something like 48% of retrieved data[0], on average is ad related.

Getting rid of those ads could cut client (and server and network) energy draws significantly. And we could further reduce energy usage by not needing add-ons like ad/tracking blockers and stuff like NoScript[1].

I browse with js disabled and, unless I need to visit a particular site, I'll just close the tab if js is required -- as the bloat, the security risks and the hubris of js overuse is just too much.

[0] https://www.nextpit.com/ads-consume-half-of-your-mobile-data

[1] https://noscript.net/

Edit: fixed spacing of referenced links.

What programmer wants to add those things? Ads have been the bane of the internet for 20 years, how many times has a developer excitedly clamored to ruin their performance metrics, layout, security, etc with more ads? How often are programmers arguing for incredibly complex UI elements over the native (and trivial to implement) alternatives?

Programmers don't choose these things, because programmers aren't the real decision makers, it's management and business that makes the web awful.

Are you saying that the executioner is not a murderer because he doesn't make decisions about who to execute and who to leave alive ?

"how many times has a developer excitedly clamored to ruin their performance metrics, layout, security, etc with more ads?"

Depends how much traffic they have I suppose. I'd be pretty excited if ads bought me a Lamborghini for every color of the week because Tuesdays right now are pretty boring.

> What programmer wants to add those things?

The one that wants to keep their job.

> How often are programmers arguing for incredibly complex UI elements over the native (and trivial to implement) alternatives?

The existence of Bootstrap and Semantic UI suggest that programmers are in fact often arguing for incredibly complex UI elements over the native alternatives.

Of course, I tottally agree. I am not talkng at all about tracking, and 3rd party services at all.

I was talking mostly about the actual application logic and presentation.

BTW tracking is hapening even w/o javascript.

Its not adds its shovelling massive amounts of bloated JavaScript frame works in and hoping for the best and in a lot of cases just not understanding how to structure a website.

Why wouldn’t it be simpler to code? When you do server side rendering with HTML forms you reduce complexity by having more pages.

It is somewhat more complex to handle more pages in your code base, but each page is short and simple.

State management is harder to do when running an app with a 50/50 split across browser and server.

You end up with a lot of complexity around cookies/local storage (and trying to persuade users that cookies are not bad and that their virus checker should not delete the cookies please ...) or encoding the session ID in the URL and hoping that users do not share links or bookmark pages, and then of course you end up with the "please only click once" links around buttons etc.

You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language (although could be nodejs of course). It is an extra interface that needs to be designed and maintained with all the opportunities for screwups that come with it.

Why would you need all that state management in the frontend if most of the rendering is on the backend?

We already have two teams today, one for the overly complex frontend and one for the backend. Solution to that is server side rendering and full stack developers.

>You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language

Or, you could hire some full-stack developers and let them split the work more efficiently.

I've written apps like this and have to wonder what on earth you're doing because this is very straight forward.

Put a session id in a cookie and use a relation table to point at the tables owned by the user. This takes very little code. The alternative is managing a distributed database, half of which has to run in the browser. That actually sounds much harder (although not surprising for a startup.)

If users are deleting first party cookies than it's their own fault. Tracking state on the website you've visited is the entire point of cookies. If the user throws their phone on the ground really hard your website also won't run on it.

Yes, lots off apps today have the entire schema replicated in the browser, which means that every schema change you do in the backend must be replicated in the frontend. Madness.

If your UI is a copy of the database why not just give the user a phpmyadmin login instead?

> why not just give the user a phpmyadmin login instead?

The guy at the previous company said we can't do that.

You can use one of the many servers that manage the users session for you and only override it if needed. Is there any real problem with a server that uses a cookie to only store the users session ID, storing the other data related to the session ID on the server? For most sites I wouldn't think there would be any issues with it.

Developer can stop using webpack to bundle 3rd party libraries. Let browser cache it.

+1. If you're only targeting evergreen browsers you can already use syntax like `import Library from './library.js'`, plus lots of modern ES6 features.

For IE11 just load polyfills and let the 2-10% of IE11 users pay the tax, instead of making all your users in modern browsers download giant bundles.

Cross origin browser cache is a no-go for Safari (and hopefully other browsers will follow suit), 3rd party scripts from a CDN are not cached across different domains. The only way to properly cache things longterm is with webpack records, but not many people can bear with the added complexity of maintaining them in their pipelines.

For almost every "web professional", the things they do are not complex. It follows then that the likelihood of this question (to a reader that doesn't know you) being asked by someone who simply doesn't understand what it means to be simple. The casual observer is further lured down this path of reasoning because of your implications that a plain form is somehow worse than something mediated by megabytes of javascript. In almost every case you'll find online, this isn't true.

You don’t avoid using JS at all but only use it where it benefits the user. For example, the users benefit from having those forms having nice validation, dynamic lookups, etc. but they don’t benefit from using a vDOM on top of the far more efficient browser DOM or loading an entire general purpose templating framework instead of just using the DOM to update an existing form.

Those are things which developers do because they think it’s easier than learning the web standards or looks better on their résumé and as long as you avoid measuring actual performance you can sustain these beliefs for a long time even while your users are seeing performance below the level of a 2000s Rails app with worse error handling.

> You don’t avoid using JS at all but only use it where it benefits the user. For example, the users benefit from having those forms having nice validation, dynamic lookups, etc. but they don’t benefit from using a vDOM on top of the far more efficient browser DOM or loading an entire general purpose templating framework instead of just using the DOM to update an existing form.

I am sorry, are you talking about example todo app ? because for most apps with complex navigation, data entry, and validation this is absolutely not true. Just use the DOM , might be somehow feasible with webcomponents, but they are years late to the game.

> most apps with complex navigation, data entry, and validation this is absolutely not true.

You mean we just imagined all of that existing? You could make an argument saying you personally haven’t learned how to do it but that’s a far cry from “absolutely not true”.

That's not a solution; making simple stuff is harder than doing complicated stuff, and it costs much, MUCH more.

This is a dangerous question but - why is that the case? Why is simple software so much more difficult to write?

Anyone can write a sequential .py file with redundant if/else statements. It takes more than 1 hour to learn how to refactor that into concice functions or objects. It takes more than 100 hours to learn how to golf that into 30 bytes.

"Simple software" does not mean "golfed". Quite the opposite, actually.

What the grandparent is suggesting is using simpler architectures, not necessarily smaller (in the code-golf sense) code.

Fair point, but at least part of golfing is cutting out anything redundant (although much more than that, which can get into obfuscation territory). Code I'm impressed with is generally when it gets the job done in the most concise/simple (while readable) manner. That is by rule done by the most experienced programmers.

To paraphrase Pascal:

> I would have written a shorter letter, but I did not have the time.

Reply on news.ycombinator.com