3 ms·

> JS was dog-slow at a point and was not really capable of doing the cool object oriented stuff you could do on desktop apps. Absolutely wrong, Javascript was

by Udik 7y ago

> JS was dog-slow at a point and was not really capable of doing the cool object oriented stuff you could do on desktop apps. Absolutely wrong, Javascript was always fast enough to make web applications that had the responsiveness of desktop apps. The problem is that nobody was writing desktop apps in the browser; they were writing server-generated web pages that offered the users some extra interactivity via js. So they had to look for elements in a static template, and hook into them or perform transformations on the fly, instead of generating everything programmatically as it's done now.

jchw 7y ago
You dismissed my claim without any numbers, so too shall I. Of course it was slow, extremely so. Pointedly, Objects were Especially slow, and even a performance cliff in V8 in many circumstances. Take a look at a React flamegraph, it’s incredible how deep and wide the callstacks are, for things that can easily run 60 times a second. You couldn’t do that years ago. IE6 and 7 were so slow in both JavaScript execution and DOM that it’s silly anyone would ever claim JS execution was “fast enough.” The art of fast JavaScript was once arcane, but its clear we’re so far into fast JS execution that nobody even remembers how awful it was. Especially when you had to support IE. Oh, and let’s not forget the incredible increases in CPU speed. Even a later Core 2 Duo machine I have is awful for browsing the web, basically unusable without uBlock Origin.
- Udik 7y ago
  Sorry, I dismissed your claims because I was developing javascript single page applications in 2005 on IE6 (and on IE5 at the beginning, I think). That was before XMLHttpRequest, I was retrieving data from an invisible iframe populated with arrays. I was able to develop crud applications and dashboards with hundreds of objects with (almost) desktop-like responsiveness. Of course there was no jQuery, elements were created programmatically and I kept a pointer to each of them, as it's normal in desktop apps. Never thought of this as arcane, it was actually very natural.
  - jchw 7y ago
    I don’t know why you assume I hadn’t been doing web development in 2005, but of course. I attempted SPAs and games in JS for a long time, and we have very different ideas about what performance means! I mean sure. Even pre-XHR you could write apps that were effectively SPAs, but manually manipulating HTML elements in your business logic isn’t exactly what I’d consider “modern.” Desktop apps at the time, even ones written on Win32, tended to put a couple layers of abstraction around the underlying resources, to say nothing of Qt and its entire programming model worth of abstractions. YUI, mentioned above, was already a significant step up from that. But those toys were nothing compared to what you can do today. Today you can literally compile the entire Qt libraries and a whole Qt app to JS and run it on Canvas and it’s usable on a fucking phone. Part of that is w3c typed arrays (and WASM, for extra perf,) but most of it is just years of raw optimization and CPU speed improvement. In 2009, I was still struggling to draw 60 frames per second (important to note: consistently. It was actually hard, at higher resolutions.) on canvas 2d. Just a few years later Unreal and Mozilla demoed Unreal Engine running at 60 fps in pure JS and WebGL. No reason to diminish what I’m sure you did accomplish in 2005 - it was probably amazing for 2005 - but I absolutely disagree that we didn’t experience life-changing performance improvements. The performance improvements we got enabled huge React and Angular apps to be possible. If you don’t believe me... again, try browsing the modern web on old machines. I've just recently set up a machine with an 800Mhz PowerPC from ~2004. Even with fairly modern Firefox, and adblocking, modern sites are basically unusable. Addendum: today’s bundle sizes also would not have worked too great on older internet. Another performance characteristic that is largely taken for granted today: parsing and network speed!
    - Udik 7y ago
      > I absolutely disagree that we didn’t experience life-changing performance improvements. Of course I don't disagree with this either. But this (as well as trying to run modern internet websites on older hardware) doesn't mean much- it's a fact that software always fills up all the capacity allowed by hardware, sometimes with features, but more often with frills and more layers of indirection. What I disagree with is that javascript (and browsers) were too slow to make interactive web applications: in fact they were possible, and the ones we still use were born around 2005: gmail (probably faster then than now), google spreadsheets, maps (I made a complex dashboard in 2005 incorporating microsoft maps, that became bing) etc. Programming was much more "close to the metal"- as much as this means anything in a web browser- but the results were usable- not as graphically fancy or feature rich as today's, but ok for many use cases. Bundle sizes also have exploded as a result of the complexity of the frameworks. But that doesn't mean the applications are more interactive or have more features, they're just fancier and, from the point of view of developers, more maintainable.

by Udik 7y ago

jchw 7y ago

You dismissed my claim without any numbers, so too shall I. Of course it was slow, extremely so. Pointedly, Objects were Especially slow, and even a performance cliff in V8 in many circumstances. Take a look at a React flamegraph, it’s incredible how deep and wide the callstacks are, for things that can easily run 60 times a second. You couldn’t do that years ago. IE6 and 7 were so slow in both JavaScript execution and DOM that it’s silly anyone would ever claim JS execution was “fast enough.” The art of fast JavaScript was once arcane, but its clear we’re so far into fast JS execution that nobody even remembers how awful it was. Especially when you had to support IE. Oh, and let’s not forget the incredible increases in CPU speed. Even a later Core 2 Duo machine I have is awful for browsing the web, basically unusable without uBlock Origin.

Udik 7y ago
Sorry, I dismissed your claims because I was developing javascript single page applications in 2005 on IE6 (and on IE5 at the beginning, I think). That was before XMLHttpRequest, I was retrieving data from an invisible iframe populated with arrays. I was able to develop crud applications and dashboards with hundreds of objects with (almost) desktop-like responsiveness. Of course there was no jQuery, elements were created programmatically and I kept a pointer to each of them, as it's normal in desktop apps. Never thought of this as arcane, it was actually very natural.
- jchw 7y ago
  I don’t know why you assume I hadn’t been doing web development in 2005, but of course. I attempted SPAs and games in JS for a long time, and we have very different ideas about what performance means! I mean sure. Even pre-XHR you could write apps that were effectively SPAs, but manually manipulating HTML elements in your business logic isn’t exactly what I’d consider “modern.” Desktop apps at the time, even ones written on Win32, tended to put a couple layers of abstraction around the underlying resources, to say nothing of Qt and its entire programming model worth of abstractions. YUI, mentioned above, was already a significant step up from that. But those toys were nothing compared to what you can do today. Today you can literally compile the entire Qt libraries and a whole Qt app to JS and run it on Canvas and it’s usable on a fucking phone. Part of that is w3c typed arrays (and WASM, for extra perf,) but most of it is just years of raw optimization and CPU speed improvement. In 2009, I was still struggling to draw 60 frames per second (important to note: consistently. It was actually hard, at higher resolutions.) on canvas 2d. Just a few years later Unreal and Mozilla demoed Unreal Engine running at 60 fps in pure JS and WebGL. No reason to diminish what I’m sure you did accomplish in 2005 - it was probably amazing for 2005 - but I absolutely disagree that we didn’t experience life-changing performance improvements. The performance improvements we got enabled huge React and Angular apps to be possible. If you don’t believe me... again, try browsing the modern web on old machines. I've just recently set up a machine with an 800Mhz PowerPC from ~2004. Even with fairly modern Firefox, and adblocking, modern sites are basically unusable. Addendum: today’s bundle sizes also would not have worked too great on older internet. Another performance characteristic that is largely taken for granted today: parsing and network speed!
  - Udik 7y ago
    > I absolutely disagree that we didn’t experience life-changing performance improvements. Of course I don't disagree with this either. But this (as well as trying to run modern internet websites on older hardware) doesn't mean much- it's a fact that software always fills up all the capacity allowed by hardware, sometimes with features, but more often with frills and more layers of indirection. What I disagree with is that javascript (and browsers) were too slow to make interactive web applications: in fact they were possible, and the ones we still use were born around 2005: gmail (probably faster then than now), google spreadsheets, maps (I made a complex dashboard in 2005 incorporating microsoft maps, that became bing) etc. Programming was much more "close to the metal"- as much as this means anything in a web browser- but the results were usable- not as graphically fancy or feature rich as today's, but ok for many use cases. Bundle sizes also have exploded as a result of the complexity of the frameworks. But that doesn't mean the applications are more interactive or have more features, they're just fancier and, from the point of view of developers, more maintainable.