5 ms·

Please, since someone from wikipedia is probably reading this: Keep the JavaScript to a minimum. The plans aren't clear to me, but given what sites like reddit/

Please, since someone from wikipedia is probably reading this: Keep the JavaScript to a minimum. The plans aren't clear to me, but given what sites like reddit/etc have done during their "updates" the new UI's are terrible on anything that isn't a top of the line device with a screaming fast internet connection. Wikipedia (and a few other "older" sites) is such a pleasure to use as is, don't ruin it. AKA round-tripping 1000 times sucks on high latency connections, and my little atom based tablets/a53 based phones/etc choke on those sites and its absolutely miserable trying to use them. So, put some effort into measuring the before/after and making sure that the download/render times remain in the same ballpark on older devices/connections.

ziftface 6y ago
The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like that will sometimes jump around and resize for no apparent reason. Making wikipedia noticeably js-heavy would definitely ruin the experience.
- tgsovlerkhgsel 6y ago
  The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters. The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially. If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached. If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.
  - capableweb 6y ago
    On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck. Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds. Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.
    - tgsovlerkhgsel 6y ago
      This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem. I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript. In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.
      - velosol 6y ago
        In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy. While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.
    - rocho 6y ago
      True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded. So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it? My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX. That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.
  - earthboundkid 6y ago
    1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.
toxik 6y ago
PSA: old.reddit.com is so much better in these regards. I use it on my phone too, with some custom css to make things bigger. There is also i.reddit.com.
- wishysgb 6y ago
  I only use old.reddit.com on phone and pc as it is much faster and much more intuitive , reddit has gone to hell in my opinion
  - gothroach 6y ago
    I'm already resigned to the fact that once old.reddit.com goes away I'm not going to be spending any more time on Reddit. Maybe that'll be a good thing.
    - unethical_ban 6y ago
      "reddit is fun" on Android is a great app for it. Staying away from reddit more is good for you, too.
      - the_cramer 6y ago
        "infinity" is also a great alternative for android.
        codq 6y ago
        Infinity looks great. Relay was my favorite while I was on Android. On iOS now, Narwhal is my go-to. old.reddit exclusively on the web, via 'Old Reddit Redirect' extension on Firefox.
- codeflo 6y ago
  I continue to be surprised that this still works, and wonder how long that'll last. It's pretty clear by this point that they're willing to try every dark UI pattern that they can think of to boost some silly engagement metrics. Community and long-term growth be damned.
swebs 6y ago
And for the love of god, don't add anything that will require a cookie pop up.
fralewsmi 6y ago
It's not even an issue with adding JS, they could build it entirely in React and not have it crawl along like new Reddit does. The issue is 'redesigns' which real purpose is to add extra layers of user engagement, ads and tracking.
alok-g 6y ago
Indeed. Most of the times, these dynamic things on web pages and elsewhere mispredict what I actually want. No Google, I did not want to zoom in on the map that you automatically did for me. Rather I unzoomed back and you automatically zoomed back in. No scroll bars, I don't want you to disappear or even thin down automatically. I personally don't like infinite scrolling as a solution either as it messes up scroll bar operation. And I want strictly none of the above if when clicking 'back', you don't take me to the exact same view I was on before, without the elements of page jumping for a few seconds. No my laptop and phone, I do not want you to wake up when I disconnect power, and especially so when I had just put you to sleep! Glad that Wikipedia is planning to show and hide the side panel on user instruction/click. Please keep it that way.
Cthulhu_ 6y ago
For sure; wikipedia is one of those sites that don't need any JS for their base functionality, and it will benefit greatly from it. They need to keep accessibility in the forefront for this redesign, and honestly, accessibility is easy if you just stick to the basics. They can embellish things with JS, but that has to be optional. Things like the article summary popup when you hover over a link. That can be deferred and left out completely. They have the opportunity to do great things with design and typography for clarity, I hope they take it.

ziftface 6y ago

The experience with js-heavy sites even on a very capable desktop is still negative. Too much js introduces bugs, latency, and lack of stability. A page like that will sometimes jump around and resize for no apparent reason. Making wikipedia noticeably js-heavy would definitely ruin the experience.

tgsovlerkhgsel 6y ago
The size and amount of JS doesn't really matter. Whether it's well written and integrated matters. How many round-trips it introduces matters. The stuff that gives JS a bad reputation is sites that slap together nested widgets that each load their resources sequentially. If you serve a 1 MB blob of all_the_things.min.js on the first page load, then gzip reduces that to ~300 KB, which will take ~2.5 seconds to load on a 1 Mbps connection, and then it will likely be cached. If you serve a widget that loads another widget that adds a third widget, on the other hand, elements will keep popping in and your user experience will suck.
- capableweb 6y ago
  On a US-normal laptop 1MB of JS might not matter too much. But for a world-normal laptop + smartphone, the size of the bundle does matter, not just for bandwidth but for performance as well. Larger JS scripts takes longer time to parse so if you have a lower power device, it still gonna suck. Everything around your program matters, but for different audiences. Wikipedias reach is huge, and getting it to work and work well, for the lowest common denominators (think ~10-40 USD smartphones) is a pretty big job which includes thinking about sizes of all kinds. Edit: Ignore me, seems you're not actually replying to anything specific in the comment before you, so this all seems off-topic now.
  - tgsovlerkhgsel 6y ago
    This is a valid argument, and you do need to benchmark on underpowered hardware. My gut feeling that a 1 MB blob of JS is not a huge problem even for a cheap smartphone nowadays, and if it is, the HTML/CSS can become the bigger problem. I remember doing really silly-sounding things (like shipping a web app + the entire database) with excellent results. Even if the initial load takes a while, you can't beat the instant responsiveness of already having the data when the user clicks on another piece of content. Hundreds of KB of JSON on a 2013 smartphone (probably Nexus 4 or 5) was still a pretty good experience IIRC, at least on par with a modern web site on a modern smartphone. On a PC, I've mercilessly thrown hundreds of MB of binary data at JavaScript. In my experience, aside from long network request chains, the biggest performance killer is e.g. having nested Angular elements that all refresh every time you touch anything on the page, not code size. If you know what you're doing and care (e.g. diligently mark immutable stuff as such), you get excellent performance. It's just that most don't care.
    - velosol 6y ago
      In addition to underpowered hardware there's underpowered connections (e.g. bad satellite connections and rural cellular) where things like being able to turn off images in a browser can come in handy. While wikipedia might not be the typical site there, there is something to be said that a site that deals in information (like a generator's manufacturers page) should at least have a low-bandwidth option so you can access the textual information you need without pulling in a presentation layer that isn't critical.
  - rocho 6y ago
    True, but for apps which are meant to be interactive you also need to take into account SPAs that might make very small requests for a good while once the main bundle has been downloaded. So, for a world-normal device which one is better? A site that downloads 1MB of Javascript and then makes data requests of a few KBs or a site that makes a 300KB request with a page reload every time you interact with it? My general rule is that if the application is interactive, meant to be used for long periods of time and SEO is not an issue, well-written SPAs result in better UX. That's not the case of Reddit for example. Most users spend the most time reading comments, and that requires very little interactivity. So old Reddit is miles ahead of the new slow and bloated one.
- earthboundkid 6y ago
  1MB of JS is bad, and you should feel bad for delivering it. A content focused website should fully render without caching in under one second on a normal desktop. That is not possible with a meg of JS.

toxik 6y ago

PSA: old.reddit.com is so much better in these regards. I use it on my phone too, with some custom css to make things bigger. There is also i.reddit.com.

wishysgb 6y ago
I only use old.reddit.com on phone and pc as it is much faster and much more intuitive , reddit has gone to hell in my opinion
- gothroach 6y ago
  I'm already resigned to the fact that once old.reddit.com goes away I'm not going to be spending any more time on Reddit. Maybe that'll be a good thing.
  - unethical_ban 6y ago
    "reddit is fun" on Android is a great app for it. Staying away from reddit more is good for you, too.
    - the_cramer 6y ago
      "infinity" is also a great alternative for android.
      - codq 6y ago
        Infinity looks great. Relay was my favorite while I was on Android. On iOS now, Narwhal is my go-to. old.reddit exclusively on the web, via 'Old Reddit Redirect' extension on Firefox.
codeflo 6y ago
I continue to be surprised that this still works, and wonder how long that'll last. It's pretty clear by this point that they're willing to try every dark UI pattern that they can think of to boost some silly engagement metrics. Community and long-term growth be damned.

swebs 6y ago

And for the love of god, don't add anything that will require a cookie pop up.

fralewsmi 6y ago

It's not even an issue with adding JS, they could build it entirely in React and not have it crawl along like new Reddit does. The issue is 'redesigns' which real purpose is to add extra layers of user engagement, ads and tracking.

alok-g 6y ago

Indeed. Most of the times, these dynamic things on web pages and elsewhere mispredict what I actually want. No Google, I did not want to zoom in on the map that you automatically did for me. Rather I unzoomed back and you automatically zoomed back in. No scroll bars, I don't want you to disappear or even thin down automatically. I personally don't like infinite scrolling as a solution either as it messes up scroll bar operation. And I want strictly none of the above if when clicking 'back', you don't take me to the exact same view I was on before, without the elements of page jumping for a few seconds. No my laptop and phone, I do not want you to wake up when I disconnect power, and especially so when I had just put you to sleep! Glad that Wikipedia is planning to show and hide the side panel on user instruction/click. Please keep it that way.

Cthulhu_ 6y ago

For sure; wikipedia is one of those sites that don't need any JS for their base functionality, and it will benefit greatly from it. They need to keep accessibility in the forefront for this redesign, and honestly, accessibility is easy if you just stick to the basics. They can embellish things with JS, but that has to be optional. Things like the article summary popup when you hover over a link. That can be deferred and left out completely. They have the opportunity to do great things with design and typography for clarity, I hope they take it.