Here's a random idea that might have more potential: create an adblocker browser plugin that also colors URLs based on how slow they are expected to load, e.g., smoothly from blue to red. The scores could be centrally calculated for the top N URLs on the web (or perhaps, an estimate based on the top M domain names and other signals) and downloaded to the client (so no privacy issues). People will very quickly learn to associate red URLs with the feeling "ugh, this page is taking forever". So long as the metric was reasonably robust to gaming, websites would face a greater pressure to cut the bloat. And yet, it's still ultimately feedback determined by a user's revealed preferences, based on what they think is worth waiting how long for, rather than a developer's guess about what's reasonable.
Edit: Joking aside, that throttling feature is a nice easy way to let a dev team, or business counterpart, see what their site is like for say, a customer with a low-end DSL connection: https://developers.google.com/web/tools/chrome-devtools/prof...
# Bandwidth trottling, enabling 150kB/s on port 80
sudo ipfw pipe 1 config bw 15KByte/s
sudo ipfw add 1 pipe 1 src-port 80
# Bandwidth trottling, disable
sudo ipfw delete 1
More useful stuff here as well, please star the repo :) https://github.com/logotype/useful-unix-stuff/blob/master/us...
Web browsers have more or less become mini operating systems, running elaborate virtual machines. There's way too much complexity for everyone involved — from web devs and browser devs to the users and the people who maintain the standards, then there's the devs who have to make native clients for the web apps — just to deliver products that don't have half the power of OS-native software. Everyone has to keep reinventing the wheel, like with WebAssembly, to fix problems that don't have to be there in the first place, not anymore:
Thanks to smartphones, people are already familiar with the modern concept of the standalone app; why not just make downloading an OS-native binary as easy as typing in a web address, on every OS?
Say if I press Cmd+Space on a Mac and type "Facebook" in Spotlight, it immediately begins downloading the native OS X Facebook app. The UI would be described in a format that can be incrementally downloaded, so the experience remains identical to browsing the web, except with full access to the OS's features, like an icon in the Dock and notifications and everything.
TL;DR: Instead of investing resources in browser development, Android/iOS/OSX/Windows should just work on a better standard mechanism to deliver native apps instead.
This is a backward-looking argument which ignores the unique benefits of the web which made it inevitable that it would evolve into an application platform, regardless of how tortured the results may feel.
The web is the first truly cross-platform development environment. It is not controlled by a single vendor, and anyone implementing a new computing device must support the web (just stop for a second and consider from a historical perspective what a monumental accomplishment that is). Furthermore, it allows casual access of content and applications without any installation requirement. It comes with a reasonable security model baked-in, which, while imperfect, gets far more attention than most OS vendor sandboxing schemes. Last but not least, the web's primitive is a simple page, which is far more useful than an app as a primitive—for every app someone installs they probably visit 100 web pages for information that they would never consider installing an app for.
I agree that the web is sort of abused as an application platform, the problem is there is no central planning method which will achieve its benefits in more app-oriented fashion. No company has the power to create a standard for binary app deliverables that will have anywhere near the reach of the web. And even if one could consolidate the power and mastermind such a thing, I feel like it would run squarely into Gall's Law and have twice as many warts as the web.
one might imagine that after these competing and incompatible native apps become a headache for crossplatform pursuits, a new platform will emerge that provides a uniform toolset for developing (mostly) native-platform independent applications.
perhaps this toolset will utilize a declarative system for specifying the user interface, and a scripting system that is JIT'd on each platform.
When Lars Bak and Kasper Lund launched Dart [2], I found it sad that they weren't more bold - left CSS and the DOM alone, and created an alternative Content-Type. So you can choose to Accept 'application/magic-bytecode' [3] before text/html, if your client supports so. Sadly, we ended up with Web Assembly, which by the few talks I've seen, appears to only cater to that of graphic/game developers, with no support for dynamic or OO languages.
[1] https://www.youtube.com/watch?v=FvmTSpJU-Xc [2] https://www.dartlang.org [3] Or in Dart lingo, a VM snapshot.
I wish. No, web browsers have become massively bloated operating systems. And since they didn't intend to, they are terrible at it. You have little to no control over anything.
We're either looking at making individual pages maintain binaries for the platforms they support (implying support of only those platforms that make sense to the site) or some kind of compilation framework running on the local machine.
For example there has been so many things for powerful layouts whereas everyone knew 10 years ago we need powerful layout solutions (flexbox or whatver) and now we have grid frameworks and years of craft on older css enhancement that has to be supported. They keep adding features here and there to sort of address lots of problems where individually those features might be cheaper but the overall cost of implementing both by browsers and the us regular developers is much higher.
Here are couple of the things I want from the web and quite a few of them are there already if not in super ideal forms. Powerful layout thats simple enough to use, concept of webpage, a bundle (http2? all your resource together), making the whole partial rendering (ajaxified page) a natural concept. Even making the UI/markup delivery being made separate from content (you can do that with all sorts of library but I think it should be at the core). Security concepts that are easier to implement (CSRF, url tampering etc.).
One of the idea I had is that browsers make a new engine that does the right things from the start and hopefully thats a much lighter engine and if you serve new pages they are really fast and if you serve old pages there is an optional transpoiler kind of thing that translates to the new version of the fly. Now it won't be terribly good to start with so its optional but essentially the old version is frozen and the more people start to only use the new engine (with transpoiler).
Perhaps rather than native apps what we need is the return of gopher. I think that's what Apple's trying to do with Apple News.
That's exactly what Windows 10 does.
When it comes down to it, for so long many front-end guys only cared about how it looked, and backend guys didn't care at all, because it's just the ui, not the real code.
We're finally at a point where real front end development is starting to matter. I honestly haven't seen this much before about 3-5 years ago... which coincides with node and npm taking over a lot of mindshare. There's still a lot of bad, but as the graph show, there's room to make it better.
I think that is orthogonal to bloat. Sure, a complex app will always have more to load and compute than a static page with one blog post on it, but that doesn't mean an app can't be bloated on top of that, just like pages with just a single blog post on them can be bloated.
Congratulations, you've invented ActiveX.
Epic malware vector.
Web technologies can already do most of what you are proposing, including notifications. There are some performance issues, but they are well on their way to being fixed.
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 link is right on their site) then requiring jQuery will be effectively free because it will be in everyone's cache.
Also the cache is supported by all browsers with an elegant fallback. Instead of having to manually having to check if your user's browser has the resource you want preloaded you just like the URL and the best option will automatically be used.
TL;DR Rather then turning this into a political issue stop bundling resources, modern protocols and intelligent parallel loading allow using the cache to stove this problem.
There's a firefox plugin that does just that! DecentralEyes - https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
Although mostly for privacy reasons, so google doesn't know all the sites you visit.
jquery-2.2.3.min.js is only 86KB for me. For the amount of functionality it adds, sure seems like a sweet deal.
Part of the problem (IMHO) is the growing requirement for larger, alpha-channel-using image formats like PNG, that then need to be expressed in a Retina format - I mean, shit looks terrible on my retina MacBook Pro that isn't properly Retina formatted. (Here's looking at you, Unity3D...even the current beta which supports Retina displays is extremely unstable and half the graphics (even stupid buttons on the UI) are still SD...)
With bandwidth costs declining [1] and basic RAM increasing [2] is there a particular reason a Web application should be much smaller than a typical desktop application? We have caches for a reason.
[1] http://www.networkworld.com/article/2187538/tech-primers/exp...
[2] http://en.yibada.com/articles/118394/20160422/macbook-air-is...
What if browsers shipped with a repository instead of a cache? Download once, stay forever.
If any browser vendor implemented my proposal, their users would switch to another browser. If it was an addon, only a handful of people would use it so there would be no impact. If it was done on the network level of a corporate business, users would complain. Still, one can dream :)
It's often suggested that we'll solve poverty by providing education and given the internet provides a unique opportunity to learn then surely we benefit as a species by ensuring there isn't a rich web and a poor web? This risk is compounded by rich people being in a better position to create better learning opportunities.
Much like there's a drive toward being aware of the accessibility of your website (colour blind-check tools, facebooks image analysis for alt text tags, etc, etc) we should be thinking about delivery into slower networks in poorer countries.
Give some kind of reminder to both users and developers about how slow their sites are. Those with the slowest websites probably won't like it too much initially, but it's going to be better for all of us in the long term.
http://www.opera.com/blogs/desktop/2016/03/native-ad-blockin...
Also, browsers could default to http://downforeveryoneorjustme.com/ for sites that loaded too slowly. AdBlock Plus and NoScript speed loads greatly. Maybe browsers could do triage on sites that load too slowly. Perhaps switch to reader mode or whatever.
Also, it doesn't work other places.
Users already respond to page load time. There's extensive evidence to support this.
Oh, and you need a loop? \adds underscore.js\
To this day, you still can't enumerate an object literal, yielding each key/value pair. You still can't properly enumerate a NodeList and Object.values is still "experimental technology".
I understand that people just abuse libraries in and out, but come on, let's not forget the reason those humongous libraries exist in the first place (and why they're having success success), it's because JS has long been crippled in terms of abstractions and people needed something to alleviate the pain.
EDIT #1: Regarding enumeration of object literals, it turns out it's actually possible, though Object.entries is still marked as "experimental" and returns an array of [key, value] pairs, as arrays, which doesn't exactly scream great design. I just wish I could do something like someObject.forEach(function(key, value) {}) (and same for map, reduce, filter, some, every, etc).
EDIT #2: The latter in my previous edit is actually possible if you're willing to create a Map from Object.entries, which you can call forEach on. Quite convoluted, but possible, so my bad.
for (let [key, value] of Object.entries({a: 1})) { console.log(key, value); }
// native JavaScript
Object.keys(obj).forEach(function(key){ console.log('obj.', key, ' = ', obj[key]) })
// Lodash
_.forEach(obj, function(value, key) { console.log('obj.', key, ' = ', value) })
Object.keys(obj) creates an array that contains the keys of the object, which makes it pretty trivial to call filter, map, reduce, etc. And getting the value from an object's key is also pretty straightforward...
Array.forEach doesn't work in IE8 or below.
Fetch API for ajax isn't in any version of IE or Safari, or any mobile browser apart from Chrome for Android.
And so on.
It's not so much that front end devs are lazy, but more a case that building a set of polyfills for each and every browser support problem is actually hard. "just use jQuery" gets around the problem. I think most developers want to write better code, but most projects don't have the development bandwidth for them to do things better.
I recently tried to force myself not to use any libraries for a simple site. After a while I realised I had so much re-invention of stuff (AJAX in particular is madness without a library) that I ended up adding Zepto
With all the crap they're adding in ES6 you would have hoped they would add an ajax function at least
I hoped with page performance becoming a ranking factor, this would change, if only for a tiny bit. But I see very slow brand websites still ranked higher then the highly optimized indie website, so that didn't work.
> "How do you do something in javascript?"
> "With jQuery you do it like this..."
I had the worst time ever when I had to work with jscript. I really wonder if my dislike of the language comes from the language itself or the community around it.
In IE6, you do it like this.
In IE8, you do it like this.
In Firefox, you do it like this.
Then jQuery came along. And it was like 'Now you do it like this, and jQuery handles it for all browsers perfectly'.
Just because some tasks are now performed easily in native javascript on all browsers, doesn't mean it was always that way.
I'd argue that jQuery was great, but now most (if not all) of it can be replaced by native javascript features (e.g. document.querySelector). Today I wouldn't recommend jQuery to anyone.
I suggest learning a functional language (in my case it was Haskell) in parallel, as it opens up new ways of thinking about javascript and problem solving.
I think SO has gotten a little better about this, but not much, IME
Wanting to use a framework shouldn't be discouraged. The issue here isn't developers trying to save time, the issue is the shitty tools.
Eventually you'll have to track every minor version of every library when not every site stays up to date. At that point it's (almost) effectively a CDN.
- element.classList is relatively recent
- NodeLists still don't have .forEach()
- string.includes() and array.includes() was only added in ES6 and ES7
- As of a Chrome 50 a few weeks ago you can now see the values inside FormData.
If your playing with larger and less 'standard' library's then that's a different story.
On the framework end of the spectrum, we have efforts like Mithril.js that try to provide a minimalist set of tools for more ambitious web applications.
So all is not lost :)
Thirty-five times! Apollo software got us to the moon. Doom wasted millions of man-hours on a video game.
My point of course is that these comparisons are not actually that illuminating.
Are web pages much heavier than they need to be? Yes. This presentation very capably talks about that problem:
http://idlewords.com/talks/website_obesity.htm
Does comparing web pages to Doom help understand or improve the situation? No, not any more than comparing Doom to Apollo memory size helps us understand the difference between a video game and a history-altering exploration.
What about the question "do web pages work any better than they did in 2007?" when we were using full page reloads and server side logic instead of Javascipt tricks.
I see so much basic brokenness on the web today from the back button not working to horribly overloaded news websites with mystery-meat mobile navigation I find myself wondering what have we really achieved in the last 9 years? This stuff used to work
client-side logic, done right is much improved over a server-side solution.
Well, to be honest, Episode 1 and Episode 2 of Doom takes place on Phobos and Deimos, so you could say Apollo software got us to the moon but Doom got us to Mars :)
[1] http://www.doomarchive.com/ListFiles.asp?FolderId=216&Conten...
One Hundred Years of Solitude
The Count of Monte Cristo
Anna Karenina
Don Quixote
Amazon.com: Online Shopping for Electronics, Apparel, Computers, Books, DVDs & more
Keep in mind that the AGC was a necessary but not sufficient piece of hardware for navigating to the moon, and was extremely special-purpose. NASA had several big (for the time) mainframes that
1) calculated the approximation tables that were stored in AGC ROM (each mission required a new table because the relative positions of the earth, sun and moon was different)
2) reduced soundings from earth-based radars to periodically update the AGC's concept of its position.
3) other things that I've forgotten
In other words, the AGC required the assistance of a ground-based computer with dozens of megabytes of RAM and hundreds of megabytes of storage. That will fit on your phone quite easily, but let's not minimize the requirements for celestial navigation.
What the shuttle did was much more complex because it was an unstable aircraft that required many "frames per second" applied to the control surfaces to keep it stable during reentry and landing.
Back around 2006 or so I wrote a simple software 3-d rendering engine in Javascript that was 8k in size without much effort towards minimizing size other being (a) maybe the only AJAX application that actually used XML (to represent 3d models) and (b) using XML element and attribute names that were just one character long.
Not long after that, libraries such as Prototype and JQuery were becoming popular and these were all many times bigger than my 3d engine before you even started coding the app.
IMO, Doom and Web pages are remarkably close in terms of purpose and required assets, and the comparison is apt. Especially when you can play Doom on a web page...
How many millions of man-hours Apollo project wasted for a PR stunt?
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 weight.
EDIT: I have a guide to setup a similar blog/site here[0]
Note: Might try it with NoScript later. Always a good indicator of... something...
1. The size of their js is ~170kb roughly 17 times larger than most of my pages.
2. It loads from a 3d party domain which means that NoScript/uBlock Origin users will see a blank white page.
The project does impose some constraints that will help reduce page weight and increase page speed, but for my page sizes it's ridiculous to use their JS.
Apparently that's "legible" and "looks the same in all... browsers".
I certainly agree that BMFW has less contrast than the MFW; so little that it's difficult to read!
For comparison, here's how MFW looks: https://imagebin.ca/v/2eeVa5QksF6e
White text on a black background, exactly as I asked for when I configured Firefox. Content taking up my whole widescreen monitor, exactly as I asked for when I made the Firefox window that size.
The only thing BMFW seems to have correct is using sans-serif font; which I expect is because I unticked Firefox's "allow pages to override these fonts" option. Other than that, it looks like a me-too cargo-cult of MFW which completely misses the point.
Presumably the creators of BMFW are using, and only ever test anything with, a black-on-white style which is, let me guess, the browser's default? What would that make them, in their own (jokingly "quoted") words?
My user experience was great, I have to agree.
If you want your page to load fast, the overall "size" of the page shouldn't be at the top of your list of concerns. Try reducing the # of requests, first. Combine and minify your javascript, use image sprites, etc.
Has everyone gone insane? The web is absolutely incredible and JavaScript is absolutely killing it as a portable application language. Remember the dark days of flash? Stop complaining.
(but the different domains actually helps speed up loading with http because it helps parallelise transfers.)
https://github.com/filamentgroup/loadCSS#recommended-usage-p... has a rather nice way to load CSS asynchronously in browsers which support rel=preload.
Now, if a webpage were to approach the size of a contemporary game...
A single good quality jpeg is around 1MB. If you have 2 nice pictures on your web page, suddenly it's bigger than doom.
Other bugs with the modern web authoring style:
1. broken back/forward functionality
2. broken scroll bars
3. broken accessibility
4. broken memory of where the page was at when closed, leading to a fresh load of the page on Re-Open-Closed-Tab
5. infinite scroll being highly unnatural
One of the places I worked at had a computer hooked up to a ~800 kbps modem, and would test all their web-pages on that. It was really eye-opening, and I wish more companies would benchmark like that
1) This is an irrelevant statistic.
2) Even if this were true it's not that big of a deal.
This is irrelevant because most people don't browse the average web page. They browse the top few sites on the internet and that's it. A more relevant statistic would be what have the sizes of the top 50 sites been over the last 15 years. I imagine they still may have grown on average, but download speeds have also grown over that time. Especially on mobile.
Even if we accept the premise that web sites as a whole, including the most popular ones are all growing and are now an average of 2.2MB each. Who cares? 2.2MB is nothing in 2016. Even on an LTE connection that's probably between 4 and 1.5 seconds to download the full page. And a lot of that size is probably in ads, which nobody minds if they load last or not at all.
Lastly, this is a self fixing problem. If a site is too bloated, users will stop going to it.
But I would propose that a lot of this increase in size is due to users (especially mobile) having higher and higher resolution displays, which necessitates higher resolution content, which of course is bigger.
Besides, 2.2 MiB for a page is pure bloat. Unless the page is heavy on images, you can usually fit all of the content that matters in a tenth of the size. In 300 KiB you can fit a 500-word article with 160 KiB picture, a few webfonts, headers/footers and stylesheets. Using a factor ten more is just ridiculous.
It's a ridiculous amount of data needed to display sites that don't have any special media or functionality and it burns up battery life and data plans for most mobile users.
Also latency is a far bigger effect than bandwidth when interacting with sites so I would say even with bandwidth going up, the actual experience of loading a site has gone down considerably over the last few years.
> Who cares? 2.2MB is nothing in 2016.
Multiply that by the amount of internet users, and now try to imagine all the hardware running this.
It's also about having a format that discourage bloat so that the web can be faster on a large scale.
So on the fastest mobile connection type available it's a magnitude or more to slow to feel fast, and that's a good state of things?
It's not really surprising in a world where a graphical driver is > 100 MB (Nvidia driver for Windows).
Try visiting Apple's website for example. I can't see how you can have a small page weight if your page includes several images that are meant to look good on high quality screens. You're not going to convince marketing and page designers to go with imageless pages.
Doom's original resolution was 320x200 = 64K pixels in 8-bit colour mode. Even an Apple Watch has 92K pixels and 24-bit colour (three times more space per pixel) now, and a 15" MacBook display shows 5.2M pixels. The space used for high quality images on newer displays is order of magnitudes higher to what Doom hardware had to show.
Indeed, right now on mobile the biggest asset on apple.com is a 1.7 MB picture.
http://images.apple.com/v/home/cm/images/heros/environment_e...
The total size of the webpage being 2.5 MB.
I suggest that at the moment, we have basically two camps of website, with rough, fuzzy boundaries.
1. A place where someone sticks up an insight, or posts a wiki page, or whatever, to share some thought to others (if anyone actually cares). The blogs of many users of HN. Hacker News itself. Wikipedia. The Arch Linux Wiki. lwn.net. Etc. The sites are very roughly concerned with 'this is what I care about, if you do, great, this is useful to you'.
2. Commercial web sites that employ sophisticated means to try and enlarge market share and retain users. AB testing. 'Seamless' experiences which are aimed at getting more views, with user experience as an afterthought (a sort of evolutionary pressure, but not the only one).
Complaining that camp #2 exists is strange. It's a bit like lamenting the fact that chocolate bars aren't just chocolate bars, they have flashy wrappers, clever ingredients, optimized sugar ratio, crunchy bit and non crunchy bit, etc.
It works! A snickers bar is a global blockbuster, and 'Tesco chocolate bar' is the functional chocolate bar that just does the job, but will never attain that level of commercial success, it serves a different role.
-----
My personal view:
Fundamentally what I want when we click a link from an aggregator, is an 'article.txt' with perhaps a relevant image or two. Something like http://motherfuckingwebsite.com/ maybe.
But if a site actually does that, a website like The Guardian, I'd fire up wget, strip all the advertising, strip the fact it's even The Guardian, and read it like a book. If everyone does it then no-one makes any money, site dies.
So what we actually have is this constant DRM-style race to try and fight for our brains to get us to look at adverts. It's not about jQuery, it's about advertising, branding, 'self vs other' (the integrity of a company as a coherent thing), etc.
I don't know what the answer is here. I think this is why I find concepts like UBI so appealing - I find it kind of alarming that we seem doomed to infect more and more of the commons with commercialization because we haven't found a solution to keep each other alive otherwise.
I think we have a real issue at the moment with people funneling their efforts into ways of dealing with issues at the micro level, rather than the macro level. Local optima. Something like that.
It makes me happy to see the sort of political revolutions that the Internet can bring about, but sad to see that we're still thinking so small. e.g. "Get x into tech" rather than "Make it so that you don't need to be in tech to live a decent life". That sort of thing.
Although I get really annoyed when I visit a blog post whose page is 100x larger than Dostoevsky's novels in .txt format. On my blog (https://pljns.com/blog/), JQuery and genericons are often my largest file transfers, but I still clock under 500kb.
> 40-pound jQuery file and 83 polyfills give IE7 a boner because it finally has box-shadow
[x] check
> You loaded all 7 fontfaces of a shitty webfont just so you could say "Hi." at 100px height at the beginning of your site?
[x] assuming 404'ed fontawesome as shitty webfont, check
> You thought you needed media queries to be responsive, but no
[x] check
> Your site has three bylines and link to your dribbble account, but you spread it over 7 full screens and make me click some bobbing button to show me how cool the jQuery ScrollTo plugin is
[x] check
Still pretty good site, but it's funny how accurately creator of http://motherfuckingwebsite.com/ has described the situation with the modern web :)
1) How do the numbers come out when you exclude images?
It's valid and good to know the total sizes, including images, but that can hide huge discrepancies in the experienced performance of a site.
For example, a page with 150KB of HTML/CSS/JS and a single 2.1MB hero image can feel very different from a page with 2MB of HTML/CSS/JS and a few 50KB images.
If we're just interested in total bandwidth consumption, then sure, total size is a good metric. If we're interested in how a user experiences the web, there's a lot of variability and nuance buried in that.
2) What device and methodology were used to take the measurements?
In this age of responsive design, CSS media queries, and infinite scrolling/deferred loading, it really matters how you measure and what you use to measure.
For example, if I load a page on my large retina screen and scroll to the bottom, many sites will send far more data than if I load them on my phone and don't scroll past the fold.
I only skimmed the article and didn't dig in to the references. These questions may be answered elsewhere.
https://binarypassion.net/digital-decadence-6ea59251d64d
and the video it refers to https://vimeo.com/147806338
Every discussion about the web will continue to be a mess until we clarify what we're talking about.
Let's try rephrasing the title a couple times.
Rephrase 1: "The average size of a webapp is now the average size of a Doom install".
Response: Interesting, but not bad! Heck, some webapps are games. "The average size of a web game is now the average size of Doom" isn't a sentence that damns the web, it's a sentence that complements the web! (or would if it was true, and it might be for all I know)
Rephrase 2: "The average size of web document is now the average size of a Doom install".
Response: Well this sucks (or would if it was true -- still we don't know). Simple documents should be a few KB, not the size of a game.
Basically our terminology is shot to crap. Imagine if 19th century engineers used the same word for "hand crank" and "steam engine". "Hand crank prices are skyrocketing! What's causing this massive bloat!" Whelp, that could mean anything.
The best solution: web browsers should enforce a clear distinction between "web documents" and "web apps". These are two different things and should be treated separately. This won't happen though, which leaves us (the rest of the tech community) to explore other options . . .
Doom isn't in true 3D, its an advanced raycasting engine. The levels are all 2D, there are no polygons, you can't look up and down. Doom has been ported to a TI Calculator. Lets maintain some perspective here.
I see what you did here.
Wow. That's nice to see actually.
I kept looking for a "minimal" blogging platform, but they all had too much bloat/JS/etc. I guess minimal means different things to different people. I ended up just writing my own. The biggest post I have is 7.41 KB.
I used to be interested in front-end design, but since it's the industry standard to use $latest_framework, instead of tried and proven practices, I've given up on that idea.
I feel like investing a few hundred extra bytes on some styling might be worth it, a la http://bettermotherfuckingwebsite.com/ vs http://motherfuckingwebsite.com/
Isn't that that the top websites have a lot more ressources available to improve asset management, cleanup and refactor?
http://www.dynatrace.com/en/benchmarks/united-states/
Particularly the "last mile" or "Chrome Homepage" tabs.
They cover the top websites, grouped into categories like "Retail", "Travel", "Media", etc.
The disparity across competitors is pretty stunning, with some websites getting close to 1 second to download/render a page, and others taking 6, 7, 8 , even 10 seconds. And these are all big, well known, companies.
And, for the most part, it all correlates very well to total page weight, and total number of artifacts on the page (js/css/images/etc). There are some exceptions, but it's a pretty strong correlation.
Sure, if man hours were free, we could trim it all down to (my rough guess) about 1/10th the size. But at $100 or even $10 an hour its just not worth it. Pay the GBs to your carrier, spend $50 more on a better phone.
Bundlers like Webpack already import JS in a modular structure. I'm wondering if we could do some profiling into popular npm module combinations (I know many people using React + Lodash + Redux Router, etc), bundle them up, and have Webpack load in those combos from a CDN via <script>?
Now this would probably require some work on webpack's end (the __webpack_require__(n) would have to be some sort of consistent hash), but at least everyone who blindly require('lodash') will see an improvement?
Web apps are another deal though.
Everything is sales.
If cleaner, 'purer' sites made more money you bet the average web page would be 10kb.
It's all about what translates to more sales. As such, you won't ever see a return to more traditional websites. Look at Amazon with it's virtual dress models, heavy as hell, but they most certainly land more sales.
Times change, and 20 years in tech is equivalent to several geological ages.
If anything, it cannot really be underestimated how some developers were able to craft such compelling gaming experiences, with the limited resources available at the time.
My personal favorite as "most impressive game for its size":
The Website Obesity Crisis
http://idlewords.com/talks/website_obesity.htm
Here’s the video of the talk if you prefer to hear him speak: https://vimeo.com/147806338
1,000,000 * 10 / 2250 = 4444 web pages a month
4444 / 31 = 143 web pages a day at most on mobile.
While it is somehow acceptable, I don't see data plans getting cheaper yet the size of the average webpage is raising fast.
It doesn't seem like most websites have heavily invested in using HTML5 offline capabilities or actual mobile first design either, something easy to check with chrome dev tools.
Also let's talk about ads : Polygon.com a site I visit often , first article on the homepage with an Iphone 5 :
- with ads/trackers 1.5mb - without ads 623kb
More than half of the load is ad/tracking related. This isn't normal.
Groove Basin [1] is an open source music player server. It has a sophisticated web-based client with the ability to retag, label, create playlists, stream, browse the library, chat with other users, upload new music, and import music by URL.
I just checked the payload size of a cold load, and it's 68 KB.
I'll just keep doing my thing over here.
I wonder how much of the problem is due to bloated templates.
Minifying JS and CSS, compression, CDNs and caching won't keep your browser from having to render all the stuff.
---
The stewardess on a new jet airliner:
- Ladies and gentlemen, welcome aboard of our new airplane. On the second deck you'll find a couple of bars and a restaurant. The golf course is on the third deck. You're also welcome to visit the swimming pool on the fourth deck. Now - ladies and gentlemen - please fasten your seatbelts. With all this sh*t we'll try to take off.
http://www.doomarchive.com/ListFiles.asp?FolderId=216&Conten...
This video shows how we do it: https://www.youtube.com/watch?v=S4LbUv5FsGQ
This document gives some results (like a GMail client that is 100X smaller): https://docs.google.com/a/google.com/document/d/1Kuw6_sMCKE7...
So indeed, there is a huge optimization opportunity of having a stricter error model.
Also, I'm really wondering how much battery could be saved when surfing such pages.
Also I'm sure there is a lot of potential going in the pre-parsed document model. But that's a next level kind of engineering I guess.
Locally I see so many companies building good looking but horrendously optimized websites for their clientele who don't know enough to ask for it.
The last company I worked at were building a local search engine and were displaying thumbnails whilst loading full size pictures which were hot linked from businesses websites. With an auto loading feature at the bottom of the page by the php backend, an initial 5-6 Mb page load could turn into 30+ Mb within a few seconds of scrolling. Add to this no gzipping and caching was not properly configured either.
I tried my best to get some changes going but the senior (and only other) dev wouldn't allow any modifications to the current system "for the moment". It was a bit frustrating to see so many easy fixes ignored.
Also: You can't use average page weight when you are just looking at the top ten. That downturn could represent a single website; all others could be increasing in size.
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.
"This new re-design gets us down to 0.4 Doom installs without sacrificing any of the visual elements."
It's actually better to show the user some progress bar, than the standard browser's "Waiting for yoursite.com".
You can get away with a lot without jQuery, while still having clean-ish code.
