6 ms·
Wikipedia's JavaScript Initialisation on a Budget
- scarmig 7y agoThis is the kind of Javascript work I love. All too often we see terrible, overly-engineered Javascript monstrosities that actively make the web worse for everyone, and that can make some of us anti-JS zealots. But JS can improve users' experiences as well, and the folks at Wikipedia are good at it.
- bo1024 7y agoTangential, but wikipedia without javascript enabled is a great experience.
- penagwin 7y agoGiven that encyclopedias work without javascript enabled I would hope that's the case.
- jspash 7y agoI have to admit, I couldn't name one javascript "feature" on the site other than one that incessantly pops up when you mouse-over links. Which I find highly irritating, but ultimately useful. I have a definite hate/love relationship with that thing. Maybe it just needs to wait a second before trying to stop me from reading the existing article.
- badrequest 7y agoKudos to the Wikipedia/Wikimedia teams for all this hard work!
- iforgotpassword 7y agoNot to abuse this post's comment section but I recently noticed that on IE11 mobile, image captions overlap with the article's text. I don't think this is relevant enough to formally file a bug report (browser seems to be grade c) but in case someone working on the site's CSS reads this and feels overly bored, well..... ;-)
- zcrackerz 7y agoIt may never be prioritized, but it's much better to have a bug report/ticket than to casually mention this in a comment no one will ever see.
- kick 7y agoThis is a great article. Wikipedia is the only site I have used in a long time that works better with Javascript turned off.
- swiley 7y agoReally? Most sites I go to other than ones like hackernews work way better without javascript. If you create an account on wikipedia you can tell them to serve you formulas using images or mathml but without doing that formulas stop working. Those hover previews hang midori though, I wouldn't mind losing those.
- ceejayoz 7y ago> Those hover previews hang midori though, I wouldn't mind losing those. On any preview, hit the gear icon in the bottom-right.
- evmar 7y agoI am surprised to discover that wikipedia appears to not use a standard minifier on their JS, but rather they have a custom one (written in PHP) that appears to just do whitespace-style removal, which they appear to run in part of the critical path of serving (?!) rather than as an offline build step. https://www.mediawiki.org/wiki/ResourceLoader/Architecture#Resource:_Scripts https://www.mediawiki.org/wiki/ResourceLoader/Architecture#R... You can 'view source' on a page to confirm that their JS doesn't even do "safe" transformations like local variable renaming.
- kevan 7y agoOne of the benefits mentioned is "a transparent "build"-free environment for the developer", so they don't have a build pipeline at all. Plus, with heavy caching thanks to Apache this would probably only get hit on server startup. Given the (self-imposed) design constraints it seems like a reasonable solution. Definitely some room for improvement on the minifier implementation.
- evmar 7y agoThey mention (in https://www.mediawiki.org/wiki/ResourceLoader/Architecture#JavaScriptMinifier https://www.mediawiki.org/wiki/ResourceLoader/Architecture#J... ) that even with the cache, they can't afford a stronger minifier. Don't get me wrong, I really like the "just ship less code" approach to making apps fast. I am just shocked that running a processor on the code that they do ship to make it smaller was not one of the first things they tried. (Disclaimer: I work in this space and have even tinkered with writing such a tool. http://neugierig.org/software/blog/2019/04/js-minifiers.html http://neugierig.org/software/blog/2019/04/js-minifiers.html )
- ryan_lane 7y agoWere you logged in? MediaWiki treats logged-in users completely differently. It's also possible that mediawiki.org doesn't minify at all purposely to make it easier to view the JS/CSS. There's definitely a minifier at work for anon users.
- hinkley 7y ago
- herpderperator 7y agoWhat is "the size of two 14 KB bursts of Internet packets"? MTU is 1500 bytes before overheard. How did they get 14 KB? What significance does that have? And what is "burst"?
- herpderperator 7y agoLooks like they referenced it later in the article: https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tcp-initial-window/ https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tc... > So why try to squeeze a website into ~14KB? Seems like you should be trying to squeeze it into 1432 bytes. > I found my answer in IETF RFC 6928 – a proposal to increase the TCP Initial Window to 10 segments. The Initial Congestion Window (cwnd) is the maximum number of bytes that a server can send without receiving any acknowledgement that the bytes were received via a client ACK packet. This maximum number of bytes to send is calculated by multiplying some number by MSS. As of RFC 6928 some number is equal to 10 (initially).
- deleted 7y ago[deleted]
- andrethegiant 7y agoThe "Startup manifest size" graph is misleading. The Y-axis doesn't start at zero, which makes the Sep 2019 size look like it is multiple times smaller than the Sep 2018 size. In reality, it's only ~22% smaller.
- xhgdvjky 7y agowho cares. look at the numbers. continue with your life... it's not like the text claims something that isn't true
- perilunar 7y agoI care. I hate misleading charts like this one.
- erydo 7y agoI care a bit. It's misleading by the standards of anyone who's used to reading graphs. Wikipedia is an organization I care about and trust and it sucks to skim a graph and realize that the axis was changed to mean something that the shape didn't convey. The entire value of graphs is using shapes to convey meaning.
- shanselman 7y agoDat Y-axis.
- pugio 7y ago> Wikipedia's startup payload now neatly fits into the target budget of 28 KB – chosen as the lowest multiple of 14KB we can fit within subsequent bursts of Internet packets to a web browser. But (according to their linked article) 14KB is only the max size of the _first_ burst of packets, after which TCP will usually double the size in each subsequent burst. So two bursts equal 14 + 28 = 42 KB, not 28. Are they doing this to assume a connection limited to only its initial burst size? I imagine this might be relevant in low-data areas (developing countries, etc.), but they don't go in to it.