3 ms·

What the browser giveth, the web developer taketh away. I tremendously hate it and it’s not like developers are incapable of building performant software, quit

What the browser giveth, the web developer taketh away. I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.

wahern 5y ago
Recent exceptions: 1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history. 2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc. Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from. Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.
hazz99 5y ago
I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today. I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though. But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.
- fouric 5y ago
  It's not just memory efficiency - webtech applications are significantly more CPU-hungry than desktop applications. > It makes it much easier to develop software I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications. The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
  - hazz99 5y ago
    I think that is the wrong question to ask. Web apps are more productive, almost by default, because you don’t need to rewrite the application for each distribution target. I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing. Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt. It also means companies don’t have to hire multiple product teams. They can hire one team. So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short. Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring. This is why I think webtech almost always makes more business sense. At least for your typical SaaS product. This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.
fy20 5y ago
IMO the frontend JavaScript ecosystem is a complete mess. Nobody cares about maintaining things properly or backwards compatibility. I mostly do backend, but occasionally do frontend work, and whenever I do I feel like bashing my head against a wall. Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app which at the time was the most popular way to... create React apps. This year I updated all the deps and something in the build broke meaning it no longer produces something runnable on the old version of Android we need. There's been an open issue on create-react-app for nearly a year, however it seems Facebook have abadoned that project and everyone has switched to Vite/Rollup now. I spend half a day switching to that which mostly works, except as it doesn't actually bundle, the dev build no longer works on the Android webview - but that's not such a deal breaker. However in the production build treeshaking seems to be completely broken, so the resulting build is a few mb instead of a few hundred kb.
- tashoecraft 5y ago
  So you took something you don't understand, pushed it up, then complain when it doesn't update correctly and something goes wrong. Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development. Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices. Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.
  - fy20 5y ago
kayodelycaon 5y ago
Even if the developers working on a website care about performance, the company’s marketing department won’t. Unless the manager in charge of the developers is particularly good, marketing will be better at convincing management to do things their way than the developers.

wahern 5y ago

Recent exceptions: 1) Chrome in Android has recently begun to hang when trying to go back to a previous page. It's gotten so bad that I end up clicking multiple times, which all register in rapid succession. If I click more times than the history depth for the tab (say 3 or 4), I end up back on the home screen and a lost tab with lost (or at least not conveniently recoverable) history. 2) AMP. When Google began pushing AMP my objections were mostly based on principle; performance was mostly a wash for me. Now the AMP viewer is so slow and so crash prone that I'm conflicted. On the one hand, I'm glad to see that AMP is clearly failing. On the other hand, Android and Chrome still strongly favor AMP, and I'm too lazy to wrestle with Google over default settings, so when I don't have the presence of mind to explicitly open a web site (e.g. when using Google News) I'm left to suffer the poor performance and bugginess in addition to other intentional AMP headaches--lack of copy+paste, less scrolling and zooming control, etc. Not quite the same thing, but related, technologies like QUIC are really only beneficial in the context of a web ecosystem built by Google. QUIC shines on websites pulling in many resources from disparate hosts, which in most cases is a situation created by advertising and analytics services. IOW, these days much of the benefits of Google's work simply pays down the debts Google itself created or advocated. And while Google still stands out for the amount of labor it invests in open source security and performance, it's just a matter of time before we pass break even into negative return territory. That happened long ago with Google Search itself; Google Search results are as slow, irrelevant, and obscured by obnoxious and misleading advertising as the competitors it originally, rapidly displaced. Heck, when Google began those investments (Android, Chrome, OS security, etc) they were crystal clear why they were making them--to nurture and grow an ecosystem into which they could grow their advertising business, same as their rationale for making a snappy search service and a non-intrusive advertising network. There's a limit to how well they can improve that ecosystem, but the limit for exploiting that ecosystem can easily result into a situation far worse than the one Google originally saved us all from. Consider why rendering work is even relevant in 2021. It's not for the benefit of services like Netflix or YouTube, which already enjoy low-power hardware acceleration, and arguably not for games or similar interactive content. It's so they can continue shifting their advertising ecosystem from minimalistic text-focused display boxes to animations and videos peppered up, down, over, and under content views. They can't do that if advertising-laden web pages drain your battery in 15 minutes, as notorious Flash-based ads once did. Steve Jobs' famously removed Flash from mobile; Google, for obvious reasons, is taking the alternative path.

hazz99 5y ago

I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today. I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though. But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.

fouric 5y ago
It's not just memory efficiency - webtech applications are significantly more CPU-hungry than desktop applications. > It makes it much easier to develop software I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications. The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
- hazz99 5y ago
  I think that is the wrong question to ask. Web apps are more productive, almost by default, because you don’t need to rewrite the application for each distribution target. I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing. Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt. It also means companies don’t have to hire multiple product teams. They can hire one team. So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short. Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring. This is why I think webtech almost always makes more business sense. At least for your typical SaaS product. This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.

fy20 5y ago

IMO the frontend JavaScript ecosystem is a complete mess. Nobody cares about maintaining things properly or backwards compatibility. I mostly do backend, but occasionally do frontend work, and whenever I do I feel like bashing my head against a wall. Case in point: Early last year I created a proof of concept web app that needs to run in the browser and a webview on an old version of Android. I used create-react-app which at the time was the most popular way to... create React apps. This year I updated all the deps and something in the build broke meaning it no longer produces something runnable on the old version of Android we need. There's been an open issue on create-react-app for nearly a year, however it seems Facebook have abadoned that project and everyone has switched to Vite/Rollup now. I spend half a day switching to that which mostly works, except as it doesn't actually bundle, the dev build no longer works on the Android webview - but that's not such a deal breaker. However in the production build treeshaking seems to be completely broken, so the resulting build is a few mb instead of a few hundred kb.

tashoecraft 5y ago
So you took something you don't understand, pushed it up, then complain when it doesn't update correctly and something goes wrong. Do you not see that you are the problem in this scenario? Facebook has not abandoned the project and very very few people have switched to Vite/Rollup. You're doing hype driven development. Now I get this is how a lot of these front end tech are portrayed, and that a lot of these projects could be better in terms of defaults, but what has to be accomplished in front end tech is very difficult. It has to run across so many different browsers, on different operating systems, with different engines across who knows how many devices. Part of the reason front end development is a mess is because people like you come in, think you don't have to spend any time learning it, and can just put something up because "it's just javascript, it's a toy language". Learn the platform and develop for it. You reached for the biggest hammer you could find when you probably could have used something much smaller and easier to use. You chose the wrong tool, and it's probably because you didn't bother putting in the time to actually figure out what you know and how it would be maintained.
- fy20 5y ago

kayodelycaon 5y ago

Even if the developers working on a website care about performance, the company’s marketing department won’t. Unless the manager in charge of the developers is particularly good, marketing will be better at convincing management to do things their way than the developers.