231–240 of 467 posts
Earlier quoted context omitted.
>make sure our computer was set to 800x600 Thaaaaaaaat's nonsense. I had relatively high-res CRTs (1600x1200) in the late 90s and early 2000s. My father and I were able to get by with Netscape Navigator and Firefox for quite awhile as well.
Firefox was released in November 2004.
Earlier quoted context omitted.
We absolutely, most certainly, should NOT ship libraries with browsers. This is a horrible idea. Browser vendors would then have too much influence on development libraries.
“We absolutely, most certainly, should NOT ship libraries with operating systems.”
Earlier quoted context omitted.
network latency still fails to catch up to human awareness' time resolution. client-side logic, done right is much improved over a server-side solution.
Which network and which latency? My local network runs audio way below the Haas limit - I can record over the network without incurring any latency penalty.
If you're drugged up on benadryl, then I'd say yes,
Quite happy with my own web page/blog. Pages hover at around 10kb, 30kb if I include some images. I think the page size can be attributed a lot to there being no JS except for GA. I have taken a lot of inspiration from http://motherfuckingwebsite.com/ and http://bettermotherfuckingwebsite.com/ Of course the size will differ depending on the site's purpose, but I feel like most web pages could stand to loose a lot of…
Earlier quoted context omitted.
Which network and which latency? My local network runs audio way below the Haas limit - I can record over the network without incurring any latency penalty.
are you serious? Are you saying the delay between a full req/res round trip + page redraw is indistinguishable from dynamically updating page elements? If you're drugged up on benadryl, then I'd say yes,
I said audio. I provided this as a counterexample to the stated thesis of your post. There exist things that can be done over a network such that latency is not an issue. I am obviously not pulling data over a cross-continental link.
FWIW, the protocols I write at work can do a full data pull - a couple thousand elements and growing - in under a half second end to end. I don't know of any HTML/Web based protocols that can even get close to that over localhost.
So yeah - we know the Web is an utter pig. My point is that it probably doesn't have to be.
As for why it's getting so insane, probably either:
1. Frameworks, since most people don't remove the code they're not using. For Bootstrap or Foundation, that can be a lot of extra code.
2. Content Management Systems, since stuff like WordPress, Drupal, Joomla, any forum or social network script, tend to add a lot of extra code (more so if you've added plugins).
3. The aforementioned tracking codes, ads, etc.
Earlier quoted context omitted.
network latency still fails to catch up to human awareness' time resolution. client-side logic, done right is much improved over a server-side solution.
Which network and which latency? My local network runs audio way below the Haas limit - I can record over the network without incurring any latency penalty.
My wired desktop gets DNS responses from 8.8.8.8 nearly as if it were in my network, in way under 10 ms, ping responses in 2 ms or so. Accessing websites hosted in e.g. Korea takes >100 ms.
Add a congested wireless connection somewhere (WLAN or mobile network) and you can add another few hundred ms. And neither cross-continent nor congested wireless latency is going to go away.
Earlier quoted context omitted.
I hear this argument a lot, and I very much disagree. Now you have browser vendors having to device which libraries are "popular" and shipping them in the initial download of the browser. It turns out that this technology already exists in a much better form. It's called cache. The problem is that almost everyone hosts their own version of jQuery. If everyone simply linked the "canonical" version of jQuery (the CDN l…
The problem with hosting JS libraries on CDNs is that the cache has a network effect. You only gain performance if the browser already has a cached version of this specific version on this specific CDN. If you don't - you end up losing performance, because now an additional DNS lookup needs to be performed, and an additional TCP connection needs to be opened. Here are a few reasons people choose to avoid CDNized vers…
And really if you are using one of the major libraries and a major CDN (Google, JQuery, etc.) over time your users will end up having the stuff in the cache, either from you or from others having used the same library version and cdn.
I suppose someone has done a study on CDN spreading of libraries and CDNS among users, so that you could figure out what the chance is that a user coming to your site will have a specific library cached - there's this http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu... but it is 3 years ago, really this information would need to be maintained at least annually to tell you what your top cdn would be for a library.