8 ms·

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever

by dpweb 11y ago

If you have an engineering mind and care about such things - you care about complexity. Even if you don't - user experience matters to everyone. Have you ever seen something completely insane and everyone around doesn't seem to recognize how awful it really is. That is the web of today. 60-80 requests? 1MB+ single pages? Your functionality, I don't care if its Facebook - does not need that much. It is not necessary. When broadband came on the scene, everyone started to ignore it, just like GBs of memory made people forget about conservation. The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me.

jkaptur 11y ago
Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.
- draw_down 11y ago
  Jeez, you aren't kidding. It's as though, if we bitch enough about the technical deficiencies, the economic and social circumstances that cause them will, I dunno, vanish into thin air I guess. This topic is pretty much just red meat here
  - Kluny 11y ago
    Well, bitching isn't that great. But as a web developer myself, it has affected the way I work. Like, there was an article just the other day about how to achieve "lightning fast page loads". I shared it around the office and as a result, 4 people have added new steps to their workflow to help reduce page load latency on our client sites. The author knew the article would get good reception here, because of how much people complain about page latency, and I knew that page latency is a thing that's important to more people than just me, for the same reason. (My clients mostly don't seem to care, for some reason, but I bet their customers do). So yeah, having these public conversations can make a difference. We just have to stay positive and constructive.
    - sanderjd 11y ago
      This is a great point. As much as it can be a bit annoying to see the same conversations over and over again, and as much as we make fun of supposed groupthink, it's all a long slow process of consensus building and idea dissemination. Thanks for reminding me of that; I was previously sitting here thinking, "oh geez, here we go again!".
- pikzen 11y ago
  Thankfully web developers are sharing the goodness and distributing 100MB+ executables using NodeJS & CEF so desktop applications can be insanely large too :^)
- kragen 11y ago
  What would be super awesome would be a daily drumbeat about how to slim down and simplify applications, with working, open-sourced code. Here, I'll beat a drum a little. Maybe it will inspire somebody. I just wrote this tiny text-rendering engine, mostly yesterday at lunch. On one core of my laptop, it seems able to render 60 megabytes per second of text into pixels in a small proportional pixel font, with greedy-algorithm word wrap. That means it should be able to render all the comments on this Hacker News comment page in 500 microseconds. (I haven't yet written box-model layout for it yet, but I think that will take less time to run, just because there are so many fewer layout boxes than there are pixel slices of glyphs.) http://canonical.org/~kragen/sw/dev3/propfont.c http://canonical.org/~kragen/sw/dev3/propfont.c The executable, including the font, is a bit under 6 kilobytes, or 3 kilobytes gzipped.
  - titzer 11y ago
    Impressive!
    - kragen 11y ago
      Thank you, but I don't think it's impressive! It's still nearly an order of magnitude slower than memcpy(). But if we want simpler systems, I think doing experiments like this is a big part of how to get there.
dustingetz 11y ago
> baffles me IMO pretty clear why, winner-takes-most economics emphasizes dev speed over quality, and then we need to maintain compat with it
RyJones 11y ago
We AABN tested injecting delay into rendering the MSN home page and found a direct correlation between amount of delay and the abandon rate. People are not tolerant of delay. Here is the team I worked on: http://www.exp-platform.com/Pages/default.aspx http://www.exp-platform.com/Pages/default.aspx
- QuavMo 11y ago
  "people"? What people? This OP's experience seems to indicate that there is a lot of patience in "Southeast Asia, South America, Africa, and even remote regions of Siberia".
  - MereInterest 11y ago
    It sounded more like patience was relative to expected wait time. If you expect something to take 20 minutes, then a 2 minute wait isn't much at all. If you expect something to take 2 seconds, then a 10 second wait is quite irritating.
    - RyJones 11y ago
      I'm certain you're right but we need to test that :) the way I read OP was the abandon rate was ~100% previously in areas with high latency/low bandwidth, and his experiment had a non-zero abandon rate that was shrinking as word spread. Perhaps I need to read it more carefully.
thewarrior 11y ago
Well damn. I'm in Bangalore and being forced to use mobile 3G for now. The data charges are atrocious and each page load saps an MB.
- coldpie 11y ago
  Maybe you have taken these steps already, but uBlock Origin works great, and NoScript works okay, in Firefox for Android. They may get your page size down by significant fractions.
elorant 11y ago
The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me Well there is, or at least there used to be. The reason native apps in mobile became so popular is exactly because web sites are bloated. It might not matter in the PC but in a device running on batteries it matters a lot. The real problem of web development is JavaScript. It’s a relic of the past that hasn’t caught up with times and we end up with half-assed hacks that don’t address the real problem. We need something faster and way more elegant.
- untog 11y ago
  The real problem of web development is JavaScript. It’s a relic of the past that hasn’t caught up with times and we end up with half-assed hacks that don’t address the real problem. We need something faster and way more elegant. I absolutely disagree. JS is plenty fast for >99% of the things being done with it. The DOM, and manipulations of it, is the slow part.
- spion 11y ago
  JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with those 60-80 requests mentioned above. We could be sending a single request for some of them (e.g. GraphQL) or we could get HTTP 2 multiplexing and server push which completely fix that problem. * JSON. Its simple but woefully inadequate. Has no built in mechanisms for encoding multiple references to the same object or for cyclic references. Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON) * The DOM. Its slow and full of old cruft that takes up memory and increases execution time.
  - phamilton 11y ago
coldpie 11y ago
I took this screenshot yesterday. This was a page showing a news article (text). http://i.imgur.com/hmFaW3M.png http://i.imgur.com/hmFaW3M.png
- dredmorbius 11y ago
  Most of those are on my /etc/hosts blocklist. Or would be were I aware of them. Worthless crap. BTW: /etc/hosts + dnsmasq, for Linux, is amazing. (dnsmasq reads /etc/hosts and will block entire domains if listed as same).
  - coldpie 11y ago
    For Firefox users, is this better than NoScript for any reason?
    - burkaman 11y ago
      I think it could make pages load marginally faster, because NoScript only stops scripts from executing, where a hosts blocklist would stop the scripts from ever being downloaded. I think, not totally sure how NoScript works.
      - coldpie 11y ago
        Nah, NoScript blocks them at load-time, too.
    - romland 11y ago
      I can't say whether it's better or worse. It's different. With NoScript you still hit "remote" servers when it comes to other resources, like images.
    - keeperofdakeys 11y ago
      For Firefox, the real comparisons are Request Policy and ublock (origin) in advanced mode (for chrome, umatrix). These do full third-party host whitelisting per domain. So every time you visit a website on a new domain, by default all requests to third parties are blocked. Then you spend a few minutes working out which ones are required. By comparison, noscript simply blocks javascript from third parties. It does include a number of anti-xss heuristics though.
petercooper 11y ago
The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me. I feel Jakob Nielsen used to majorly play this role amongst Web developers back in the day, but for some reason I haven't seen him come across my radar for many years now. The Web performance experts now are better than ever but I don't get the sense of the majority of the industry hanging off their every word as seemed to happen with Jakob 10+ years ago.
- gopowerranger 11y ago
  I get weekly newsletters from him. Still good stuff.
wtetzner 11y ago
There are reasons for it: it takes more work to write an efficient, simpler application with the same functionality. Developer time is expensive.
JustSomeNobody 11y ago
Unfortunately, computing has always been that way. Remember the mantra "Intel giveth, Microsoft taketh away?". Developers quickly get spoiled with faster hardware, more bandwidth, more RAM, etc. I'm not saying it's right. In fact, I would prefer if everyone took a look at their apps much like the author of the article. I'm just saying, this isn't a new phenomenon.

by dpweb 11y ago

jkaptur 11y ago

Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote connection to web technologies.

draw_down 11y ago
Jeez, you aren't kidding. It's as though, if we bitch enough about the technical deficiencies, the economic and social circumstances that cause them will, I dunno, vanish into thin air I guess. This topic is pretty much just red meat here
- Kluny 11y ago
  Well, bitching isn't that great. But as a web developer myself, it has affected the way I work. Like, there was an article just the other day about how to achieve "lightning fast page loads". I shared it around the office and as a result, 4 people have added new steps to their workflow to help reduce page load latency on our client sites. The author knew the article would get good reception here, because of how much people complain about page latency, and I knew that page latency is a thing that's important to more people than just me, for the same reason. (My clients mostly don't seem to care, for some reason, but I bet their customers do). So yeah, having these public conversations can make a difference. We just have to stay positive and constructive.
  - sanderjd 11y ago
    This is a great point. As much as it can be a bit annoying to see the same conversations over and over again, and as much as we make fun of supposed groupthink, it's all a long slow process of consensus building and idea dissemination. Thanks for reminding me of that; I was previously sitting here thinking, "oh geez, here we go again!".
pikzen 11y ago
Thankfully web developers are sharing the goodness and distributing 100MB+ executables using NodeJS & CEF so desktop applications can be insanely large too :^)
kragen 11y ago
What would be super awesome would be a daily drumbeat about how to slim down and simplify applications, with working, open-sourced code. Here, I'll beat a drum a little. Maybe it will inspire somebody. I just wrote this tiny text-rendering engine, mostly yesterday at lunch. On one core of my laptop, it seems able to render 60 megabytes per second of text into pixels in a small proportional pixel font, with greedy-algorithm word wrap. That means it should be able to render all the comments on this Hacker News comment page in 500 microseconds. (I haven't yet written box-model layout for it yet, but I think that will take less time to run, just because there are so many fewer layout boxes than there are pixel slices of glyphs.) http://canonical.org/~kragen/sw/dev3/propfont.c http://canonical.org/~kragen/sw/dev3/propfont.c The executable, including the font, is a bit under 6 kilobytes, or 3 kilobytes gzipped.
- titzer 11y ago
  Impressive!
  - kragen 11y ago
    Thank you, but I don't think it's impressive! It's still nearly an order of magnitude slower than memcpy(). But if we want simpler systems, I think doing experiments like this is a big part of how to get there.

dustingetz 11y ago

> baffles me IMO pretty clear why, winner-takes-most economics emphasizes dev speed over quality, and then we need to maintain compat with it

RyJones 11y ago

We AABN tested injecting delay into rendering the MSN home page and found a direct correlation between amount of delay and the abandon rate. People are not tolerant of delay. Here is the team I worked on: http://www.exp-platform.com/Pages/default.aspx http://www.exp-platform.com/Pages/default.aspx

QuavMo 11y ago
"people"? What people? This OP's experience seems to indicate that there is a lot of patience in "Southeast Asia, South America, Africa, and even remote regions of Siberia".
- MereInterest 11y ago
  It sounded more like patience was relative to expected wait time. If you expect something to take 20 minutes, then a 2 minute wait isn't much at all. If you expect something to take 2 seconds, then a 10 second wait is quite irritating.
  - RyJones 11y ago
    I'm certain you're right but we need to test that :) the way I read OP was the abandon rate was ~100% previously in areas with high latency/low bandwidth, and his experiment had a non-zero abandon rate that was shrinking as word spread. Perhaps I need to read it more carefully.

thewarrior 11y ago

Well damn. I'm in Bangalore and being forced to use mobile 3G for now. The data charges are atrocious and each page load saps an MB.

coldpie 11y ago
Maybe you have taken these steps already, but uBlock Origin works great, and NoScript works okay, in Firefox for Android. They may get your page size down by significant fractions.

elorant 11y ago

The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me Well there is, or at least there used to be. The reason native apps in mobile became so popular is exactly because web sites are bloated. It might not matter in the PC but in a device running on batteries it matters a lot. The real problem of web development is JavaScript. It’s a relic of the past that hasn’t caught up with times and we end up with half-assed hacks that don’t address the real problem. We need something faster and way more elegant.

untog 11y ago
The real problem of web development is JavaScript. It’s a relic of the past that hasn’t caught up with times and we end up with half-assed hacks that don’t address the real problem. We need something faster and way more elegant. I absolutely disagree. JS is plenty fast for >99% of the things being done with it. The DOM, and manipulations of it, is the slow part.
spion 11y ago
JavaScript isn't the problem, but it seems to always take the blame. And its not even slow. Here are a couple of real culprits: * Advertising / analytics / social sharing companies. They deliver a boatload of code that does very little for the end-user. * REST and HTTP 1 in combination. A page needs many different types of data. REST makes us send multiple requests for different kinds of data, often resulting with those 60-80 requests mentioned above. We could be sending a single request for some of them (e.g. GraphQL) or we could get HTTP 2 multiplexing and server push which completely fix that problem. * JSON. Its simple but woefully inadequate. Has no built in mechanisms for encoding multiple references to the same object or for cyclic references. Want to download all the comments with the user info for every user? You have a choice between repeating the user info per comment, requesting the comments first then the users by id (two requests) or using a serialisation mechanism that supports object references (isn't pure JSON) * The DOM. Its slow and full of old cruft that takes up memory and increases execution time.
- phamilton 11y ago

coldpie 11y ago

I took this screenshot yesterday. This was a page showing a news article (text). http://i.imgur.com/hmFaW3M.png http://i.imgur.com/hmFaW3M.png

dredmorbius 11y ago
Most of those are on my /etc/hosts blocklist. Or would be were I aware of them. Worthless crap. BTW: /etc/hosts + dnsmasq, for Linux, is amazing. (dnsmasq reads /etc/hosts and will block entire domains if listed as same).
- coldpie 11y ago
  For Firefox users, is this better than NoScript for any reason?
  - burkaman 11y ago
    I think it could make pages load marginally faster, because NoScript only stops scripts from executing, where a hosts blocklist would stop the scripts from ever being downloaded. I think, not totally sure how NoScript works.
    - coldpie 11y ago
      Nah, NoScript blocks them at load-time, too.
  - romland 11y ago
    I can't say whether it's better or worse. It's different. With NoScript you still hit "remote" servers when it comes to other resources, like images.
  - keeperofdakeys 11y ago
    For Firefox, the real comparisons are Request Policy and ublock (origin) in advanced mode (for chrome, umatrix). These do full third-party host whitelisting per domain. So every time you visit a website on a new domain, by default all requests to third parties are blocked. Then you spend a few minutes working out which ones are required. By comparison, noscript simply blocks javascript from third parties. It does include a number of anti-xss heuristics though.

petercooper 11y ago

The fact that there isn't a daily drumbeat about how bloated, how needlessly complex, how ridicuous most of the world's web appliactions of today really are - baffles me. I feel Jakob Nielsen used to majorly play this role amongst Web developers back in the day, but for some reason I haven't seen him come across my radar for many years now. The Web performance experts now are better than ever but I don't get the sense of the majority of the industry hanging off their every word as seemed to happen with Jakob 10+ years ago.

gopowerranger 11y ago
I get weekly newsletters from him. Still good stuff.

wtetzner 11y ago

There are reasons for it: it takes more work to write an efficient, simpler application with the same functionality. Developer time is expensive.

JustSomeNobody 11y ago

Unfortunately, computing has always been that way. Remember the mantra "Intel giveth, Microsoft taketh away?". Developers quickly get spoiled with faster hardware, more bandwidth, more RAM, etc. I'm not saying it's right. In fact, I would prefer if everyone took a look at their apps much like the author of the article. I'm just saying, this isn't a new phenomenon.