Live data from Hacker News

I'm more proud of these 128 kilobytes than anything I've built since

medium.com

41–50 of 50 posts

Re: I'm more proud of these 128 kilobytes than anything I've built since

#41

Maybe i'm dumb, but I really don't understand the point of this post. Why even make it "reactive"? Just make your site static server-rendered pages? Or just static pages. Is it because additional-content-loading is something users expect? "Write your site in plain javascript and html. Don't use a framework. Write some minimal css. Bamo. Well under 128kb." ???

at least in this case one of the ideas seemed to be that if they did an ajax load of the middle section of the page, they could skip sending the fixed elements (header and footer) over the network repeatedly

Re: I'm more proud of these 128 kilobytes than anything I've built since

#42
post #29

I really enjoyed the article. I have to say, though: sorry, not sorry, but application size is a poor measure of performance. A 128KB size limit doesn't account for pictures, videos, tracking, ads, fonts, and interactivity. Just avoid them, is not a real world strategy. Suggesting that an application should stay within a 128KB limit is akin to saying I enjoy playing games in polygon mode. Battlezone was impressive in…

It's not about performance, it's about load time and the restrictions of your client apps.

Also, you're thinking way too much in a SPA architecture. Using just server side rendering with just a tiny bit of javascript like the article states removes most of the problems you describe like Initial load time and cross team collaboration. The load time of the described websites would be instant, and there is no front end team needed.

Re: I'm more proud of these 128 kilobytes than anything I've built since

#43
post #41

Maybe i'm dumb, but I really don't understand the point of this post. Why even make it "reactive"? Just make your site static server-rendered pages? Or just static pages. Is it because additional-content-loading is something users expect? "Write your site in plain javascript and html. Don't use a framework. Write some minimal css. Bamo. Well under 128kb." ???

at least in this case one of the ideas seemed to be that if they did an ajax load of the middle section of the page, they could skip sending the fixed elements (header and footer) over the network repeatedly

To be fair, an iframe would accomplish that too, but the loaded content would have its own html header that adds to the amount of kilobytes used. So maybe that's the reason.

Re: I'm more proud of these 128 kilobytes than anything I've built since

#44
post #29

I really enjoyed the article. I have to say, though: sorry, not sorry, but application size is a poor measure of performance. A 128KB size limit doesn't account for pictures, videos, tracking, ads, fonts, and interactivity. Just avoid them, is not a real world strategy. Suggesting that an application should stay within a 128KB limit is akin to saying I enjoy playing games in polygon mode. Battlezone was impressive in…

It's not about performance, it's about load time and the restrictions of your client apps. Also, you're thinking way too much in a SPA architecture. Using just server side rendering with just a tiny bit of javascript like the article states removes most of the problems you describe like Initial load time and cross team collaboration. The load time of the described websites would be instant, and there is no front end…

No, just no.

Re: I'm more proud of these 128 kilobytes than anything I've built since

#45

I don't do web stuff at all, but I really enjoyed this article. I am convinced that software engineers (not to mention others) have thrown the baby out with the bathwater in our brave new world of 32GB memories and fibre-optics. By all means the generous hardware capabilities let us do amazing things, like have a video library, or run massive climate computations, but mostly those resources are piddled away in giant…

> I really wonder whether we've lost something by not making more of an effort to use resources more frugally I'll bite. What do you think we've lost? What would the benefit be of using resources more frugally? Disclosure: I'm an embedded systems programmer. I frequently find myself in the position where I have to be very careful with my usage of CPU cycles and memory resources. I still think we'd all be better off w…

> austerity offers no benefit

Data centers use a lot of electricity. Even a 10% reduction would cause huge impact world wide

Re: I'm more proud of these 128 kilobytes than anything I've built since

#46
post #32

Earlier quoted context omitted.

Quick answer: is our software any more usable, any more reliable, than it was 50 years ago? The more code you write, the more dependencies you require, the more opportunity for bugs and design errors to creep in. I get the impression that many software projects have enough fixes and kludges slathered on them to make them work nowadays. (Remember Bill Atkinson's famous response, quoted here to how much code he'd writt…

It's much more capable, that's the main thing. Reliability and usability tend not to be valued in the market much, but being able to do more things is.

I’m not sure that is true, if anything I would say most of the software I use today has been dumbed down to cater for a mainstream audience.

Re: I'm more proud of these 128 kilobytes than anything I've built since

#47

I don't do web stuff at all, but I really enjoyed this article. I am convinced that software engineers (not to mention others) have thrown the baby out with the bathwater in our brave new world of 32GB memories and fibre-optics. By all means the generous hardware capabilities let us do amazing things, like have a video library, or run massive climate computations, but mostly those resources are piddled away in giant…

> I really wonder whether we've lost something by not making more of an effort to use resources more frugally I'll bite. What do you think we've lost? What would the benefit be of using resources more frugally? Disclosure: I'm an embedded systems programmer. I frequently find myself in the position where I have to be very careful with my usage of CPU cycles and memory resources. I still think we'd all be better off w…

In my embedded career I always assumed the value of a SW engineer was to cut costs, regardless of whether it was a few cents (and of course add to quality and reliability). It seems in embedded, it’s one of the only SW fields left where software can affect the cost of the system. By choosing a processor in a family with the least amount of memory and speed, you can achieve a lower system cost. In this world, the ability to write fast code in a minimal footprint matters. You still have to wrestle with development time/cost versus HW cost tradeoffs vs sales, but I think it still remains true that the coding practices we saw in 60s-80s are still valued in this space. My impression is these skills these days are being lost/ignored for the most part. When a HW limit is reached, the only way forward for quicker SW solution is optimization.

Re: I'm more proud of these 128 kilobytes than anything I've built since

#48
post #38

Earlier quoted context omitted.

> There used to be a contest to fit a good web page into 5kB ... In accordance with this philosophy, I worked on a project a couple years ago where the HTML home page uncompressed size was intentionally limited to 4k. The idea being a slow network connection (such as a mobile device using a limited cellular connection) would be able to render quickly and remaining content could load asynchronously.

I wish everyone would do the same!

[deleted]

Re: I'm more proud of these 128 kilobytes than anything I've built since

#49
post #38

Earlier quoted context omitted.

> There used to be a contest to fit a good web page into 5kB ... In accordance with this philosophy, I worked on a project a couple years ago where the HTML home page uncompressed size was intentionally limited to 4k. The idea being a slow network connection (such as a mobile device using a limited cellular connection) would be able to render quickly and remaining content could load asynchronously.

I wish everyone would do the same!

[deleted]

Re: I'm more proud of these 128 kilobytes than anything I've built since

#50
post #38

Earlier quoted context omitted.

> There used to be a contest to fit a good web page into 5kB ... In accordance with this philosophy, I worked on a project a couple years ago where the HTML home page uncompressed size was intentionally limited to 4k. The idea being a slow network connection (such as a mobile device using a limited cellular connection) would be able to render quickly and remaining content could load asynchronously.

I wish everyone would do the same!

How about having a page consisting of pure html, less than 0.5kb, with the server only providing content alone (simple, one mp4), but serving you none of the html?

So it even works when there is no page on the web at all :0

In that case your browser only needs to load 0kb of html from the web in order to successfully reach the page.

That can be pretty fast. Either way. 0.5kb is real small but 0kb is a bit smaller ;)

Fairly elementary, all you're wanting to do is access some media which is found on the web itself at a known address.

But there's a catch, you would have to supply the html "landing page" file yourself from your own PC if none of the html's going to be coming in from the web to your browser.

Here it is:

   
        
   body {background-color:#0000ff; color:#ffffff; font-size:28px; text-align:center;}
        

        
   Fuzzfactor Minimal Player
        

        
        

        
   big_buck_bunny_720p_surround.mp4
        

        
Copy and paste the code into a text editor, save file as fuzzplayer.txt into your favorite folder, then save it again as fuzzplayer.html, right there in the same folder. To edit in the future, double-click on the TXT version to edit, double save again as both file types when done. Double-click the identical html version (identical to txt except for file extension) to launch your browser and go to "my" page where you can play the media. Not much differently than the Mozilla example does.

"Header" (not formally), three "paragraphs" (without paragraph marks), EOF.

Backward indenting for me, old (without) school I guess.

Pretty straightforward

Almost everything indented except things that you might want to change more easily in the future. Then you can just go down the left margin and kill 'em all or take pot shots.

Page formatting is associated with a block of displayed text in preference to other objects. This is the indented html formatting which is quite likely to need some future editing, very often in concert with the text itself, so it's good to have it right there. Almost seems like some html belongs without indentation also but that kind of defeats the purpose of the "clean" look. You get used to it.

Editing 5kb or 10kb of this kind of stuff manually, covering all the bases in a couple minutes, and having it work the first time can make you smile more than a lot of things :)

Post reply on HN