Hacker News Reader

Comment by pvsukale3 | Hacker News Reader

I opened this game in an incognito tab. And started dev tools. The entire game is only 2.8 MB. It loads fast. Such graphics, much small. A lesson for modern web developers about website obesity and performance.

View on HN

Yes, also the immediacy of experience. No signup, no prompts or forms, no friction. Just one click and you’re immersed in the action.

When companies clutter first experience with legal disclaimers, signup offers, and every other thing, I wonder if they are always carefully balancing the competing interests of business and product design as a big picture weighing everything together.

To the extent they do that’s great, but it seems sometimes its a lawyer trying to do and think only of their job, a marketing person only thinking of their job, sales only thinking about revenue, rather than globally optimized decision.

And developers only thinking about the development experience. In my next project I'm going to monitor the gzipped size of my deployed site as part of continuous integration.

npm bundlesize might help you: https://github.com/siddharthkp/bundlesize

This is what gets me... here's a dependency to reduce the size of your dependencies. I understand that it's useful, but at what point enough?

It is a development dependency though. So it does not get included in the final bundle at all.

I mean this is nice but it's really not a lesson for web developers. The fact that this is 2.8mb doesn't really teach a web developer any lessons, unless you think that large website payloads exist because developers are literally too lazy or don't know how asset optimization works.

Instead, having worked in web development, I know that website payload size is often driven by having to include vendored javascript for business reasons (analytics and social are big culprits) or because your boss doesn't give you the time to focus on performance because for the business, it is good enough and they want to use their limited web development resources to do something other than shrinking javascript payloads.

Another thing, you're impressed by the graphics and how the developer was able to include them while keeping the payload small. It seems to be made using vectors and particle effects. Both of these techniques are not heavy in terms of payload. Shaders and particle effects are generally very small amounts of code. Think about how this is different for a website that heavily relies on all sorts of user-generated content: jpgs, mp4, gif, png, etc. Much larger assets than a few shaders and svg.

>unless you think that large website payloads exist because developers are literally too lazy or don't know how asset optimization works.

For what it's worth, I do think this. It's easy to just drag another JS library into your code without thinking of how long it's going to take to load.

I don't know what to tell you if you're convinced that's the problem. I know and work with many web developers who do care about performance. I follow the blogs of many web developers who write about performance.

I don't doubt that there are junior web developers who don't know much better. But I don't really meet anyone who says that they just don't care about performance.

Caring about performance means weighing the decision carefully when choosing vendor libraries that fill up your payload. You can consciously care about performance but still be negligent to the things that affect it.

I see competent devs reach for libraries all the time when a simple solution already exists within the language. It's easy to feel like you're doing the right thing by not reinventing the wheel.

Areas I see this happening a lot in are anything dealing with file systems, HTTP request/responses, database connections, DOM/string manipulation/parsing/validation. The common theme among all these things is usually a lack of understanding of what the library/package does well enough to implement the specific use case needed.

Let me just point out that you can care deeply about performance and still lack the skills to achieve it.

Yes, I agreed with you in my post.

> I don't doubt that there are junior web developers who don't know much better.

I just think it's very... puritanical the way that people bemoan the state of websites as a personal failing of web developers as a profession rather than the a result of what kind of deliverables their employers care about and are willing to pay for.

Whenever I see the term "web developers" in this context, I'm assuming it means all of the decisions they make given the requirements and inputs from others in the business.

I think the web is currently terrible and I think modern web-development is to blame, but that includes the people behind the web-devs making the decisions that are being pushed onto the web-devs.

There are a lot of things to blame for the current state of the web, but ultimately the current practice of web-development (and whatever behind-the-scenes processes that involves) is clearly the biggest reason why.

See in my mind that’s like blaming construction workers for condos built quickly with shoddy materials. I don’t choose the materials I work with most of the time. I have worked on maybe one greenfield application in my entire life. It was really small and performed well. Everything else has been making the best out of bad decisions made by other people.

I agree that it isn't fair, but that's also just how it goes. I get blamed all the time for poor decisions made by my group, even if I agree that they are poor decisions.

If you balance pay vs. skill and the rarity of such an incredible web game...things are quite the way they should be. Reality. No one is going to pay an average web developer to care that much because they themselves do not care enough to invest in the talent or the time involved.

Even if you're a great developer, you might not be getting paid to care about performance. If "loads fast" is not a deliverable your employer cares about, they are not going to give you the time or budget to care about performance. Think of how many websites, especially for marketing purposes, are built by contractors who are getting tasked with making shiny, asset heavy websites that look good on the nice macbooks of businesses paying them. I've never seen a heard a client say "oh and make sure the page loads in under 2s" to be honest.

facebook takes 25s to fully load

Not on any of my devices. And time until “fully loaded” is just one piece of the performance pie.

When you're talking about code written for hire, you have to separate the developer's priorities/cares from the company's. There are many, MANY companies that do not care about performance or quality, where good enough means "At least won't actively enrage customers." These companies sometimes hire individual developers who do care about performance and quality. But if you're Third Developer From The Left on Project 123, what you personally care about is irrelevant.

This is one of the reasons I got out of actually writing software as a profession. My interests as a developer rarely aligned with my employers' business goals. I got tired of the whole "Cram features as fast as you can, quality be damned" mode of development and bailed.

I'm increasingly feeling the same frustration with the industry. What do you do nowadays, if I may ask?

Still in software, but I've been bouncing back and forth between product management and project management. I feel these roles (esp. Product) better allow one to "set the tone" on the priorities, compared to the individual engineer role. I can focus on what is the business case for undertaking engineering activities, manage risk, and help management balance features vs. quality. Suits me better. If I want to code I do it at home on my personal projects 100% on my own terms.

Yes, thank you. I suspect all of these people complaining about the size of web pages don't actually work as web developers. Especially because they think the only aspect of performance that matters is payload size.

Website payload is easily measurable (it is probably the most easily measurable factor), and optimizing it is attractive to developers. That doesn't mean it is the most important factor, much less the only important aspect of development.

Rather than "lazy" or "don't know", how about:

- it's fast enough

- have other priorities (security, stability, usability, functionality)

- optimize developer time

...

> it's fast enough

It's fast enough for people with as good computers and Internet connections as me, who are also employed at the same company as I am, and so do not use anything but the product on their computer at the same time.

> optimize developer time

Saving 1h for a developer for each 30min wasted over the lifetime of the application * number of users. Yeah, that scales right. Electricity is free too.

So is there any situation where you would say that the gains from performance optimization are marginal?

Also, you fail to consider the opportunity cost of developer time. It's not free. Your business needs you to do other things. Also, like GP said, there are factors to performance beyond payload size. Do you actually develop web applications for a job where someone else decides the priorities?

> So is there any situation where you would say that the gains from performance optimization are marginal?

Yes! But the current trends around software - and in particular web stuff, both in-browser and in-browser-but-pretending-to-be-native - very, very far from that point.

Look, I know that business has its priorities. But I have a right to dislike a business based on its priorities, and I believe chasing ultra-short-term gains by resorting to shitty engineering is a bad thing, and I do avoid using products of such companies, and I do call it out when I see it. Ultimately, business priorities are determined by the market, and I'm doing what little I can to create market pressures towards user-respecting solutions.

And yes, I've been doing webdev as a regular employee, and I always pushed against both needless inefficiency and user-hostile "features", with quite a good success.

We're on the same side. The difference is that I see most developers to essentially be like me: wanting and knowing how to do the right thing, arguing with their Bosses and PMs, but still failing to get performance to be as big a priority as they'd like. You seem to think that since you care and have been able to deliver the kind of performance you want, that other people must not be trying hard enough or know how to write well-performing apps.

Maybe you can share some advice about how you get your boss or PM to care about performance. Because I've tried your arguments, and it's not like by explaining the amortized cost of performance I'll get an extra week or sprint to improve performance.

So you're writing all your web applications in hand-optimized assembly language? respect

If improving performance is not a significant concern to your customers or benefit to you, further optimizing performance should probably not be a significant concern for you.

Your time is the least scalable thing you've got - you're not getting any more of it.

No, of course not. I just try to write code in a performant way the first time around[0] - it's usually more than enough.

The problem here is lack of effective feedback on the market. You may be writing your application totally bloated, and due to the nature of software, you might not notice any significant impact on your business. It turns out that your application may be lagging just enough to make it unusable for the 1% of your userbase that has shitty connection... that's basically an accessibility problem.

But then that "accessibility problem" actually impacts your customers too, just not in a way most of them can tie back to you. It's your app, plus that other app, plus that third app, and suddenly their stupidly powerful[1] computer becomes sluggish, and they can't get any work done.

Performance is commons. Unless you're writing bare-metal embedded, your software is not running alone on the machine. By producing bloated code, you're implicitly taking away your users' productivity beyond what you could with little extra care. It's something that I try to keep in mind when writing software, too.

(Also, RE developer time tradeoff - people seem to not appreciate how software scales. If you save 100 man hours of development time at the expense of 1h per user over their whole use of the application, with 1M user you just wasted the world 1Mh - 100h = 999.9k man hours. Something to keep in mind, too.)

[0] - It's usually entirely possible to write code both fast and clean, if you don't overdo abstractions. As a bonus, the code is usually simple.

[1] - Compared to what they had 5 years ago. User-facing software seems to be not gaining useful features, but rather constantly losing them. And yet it becomes only ever slower, for no actually good reason, just accumulation of bloat at every level of the stack.

This is true for the sites, however then it's the vendors who are then lazy and put out bloated packages, which is much worse since they have an outsized impact on all the sites they're included on.

Yes. Not only that, it's the cumulative effect of having to include tags from so many vendors.

Am I horribly out of touch to think that 2.8 MB seems big for this level of complexity? I'm not saying every web game needs to be a js1k, but that's roughly the size of a well-above-average SNES or Genesis game (e.g. Super Metroid or Phantasy Star IV).

Yes, but that's what the world without Flash games looks like. :)

As an obesity geneticist, I fully approve of your invention of this term! LOL

Haha. This term is quite old actually.

http://idlewords.com/talks/website_obesity.htm

This is the kind of gaming experience I'm hoping webassembly will bring. No installation, just visit a website and play.

Why do you need webassembly for that, since this game already works great right now?

For more CPU demanding games, that is. Like AAA games.

So that you can write in something saner than JavaScript, for starters.

You can already compile C/C++ (and I think Rust) to JavaScript via Emscripten.

Yes, you can use Emscripten with Rust.

Isn't that the gaming experience Flash already brought?

You had to install Flash though.

It was really nice to see browsers simply incorporate slow but steadily all the APIs that made Flash worth its plugin install (canvas, opengl, webaudio, input devices, sockets). Instead of battling head on with it they simply made it pointless since you now have the same capabilities inside the engine.

> You had to install Flash

That's a choice by the browser, just like wasm.

> 2.8MB

> small

> website obesity

Phis is not a website, but my throttled phone connection disagrees either way.

Please have a look at js1k. Or go directly to size coding, e.g. .kkrieger, which is a FSP game techdemo in 96kb, see https://news.ycombinator.com/item?id=14409210

Reply on news.ycombinator.com