3 ms·
They wouldn't, but they do. Frameworks upon frameworks upon frameworks, and nobody knows what happens underneath. If you are a gmail.com user, have you ever tri
by olau 9y ago
They wouldn't, but they do. Frameworks upon frameworks upon frameworks, and nobody knows what happens underneath. If you are a gmail.com user, have you ever tried the plain HTML version? The difference in speed is mind-boggling. Yes, the Javascript version is doing more, but it should also be able to be faster as it doesn't have to load the whole page each time.
- Groxx 9y agoSimilarly: running with e.g. noscript reminds you that internet speeds actually have improved over the years. Pages load in instants rather than seconds, it's wonderful.
- old-gregg 9y agoFun anecdote: I tried using newegg.com to build a PC based on these new processors. My 2 year old Macbook Pro almost melted, with only about 6-7 tabs (all pointing to different parts on newegg.com) open. This is kind of ironic: you need a really powerful PC to use a web site which sells powerful PCs. Catch-22. No. I do not want a web page to be able to eat up more than one core. Frankly, I feel like I want to try a browser extension that "locks" any web page within 20% of a core performance. These developments make me believe that browser-based apps, that were "around the corner" 10 years ago, is a lost cause. Despite numerous optimizations done to Javascript engines and despite tremendous performance of modern CPUs, browser-based apps continue to crawl at a speed of early IBM PCs of the 80s. Even a 286 circa 1992 running DOS apps felt faster than newegg.com in 2017 on a modern Intel i7. Sure its tempting to blame "lazy programmers" and bloated frameworks, but bad engineering, tight schedules and tech debut have always existed, for all platforms, all the time. There's just something fundamentally broken about apps built on asynchronous loading of dozens of UI components from a remote location and assembling them into a coherent UI screen as the pieces arrive.