A day without JavaScript
sonniesedge.co.uk
sonniesedge.co.uk
The CSS file is also nearly 1 Mb.
It's just a simple website with some forms.
They have 2 developers working on the site, a scrum master, a project manager and 2 testers but somehow they can't find the time to find out which legacy code they can remove.
It's only after I pointed out that they have an exceptionally high bouncerate on their (expensive) Adwords traffic and the slowest pageload time of all their main competitors that I managed to get some priority to optimize their site.
Serious question: are there any tools that can scan a full website for unused code and unused CSS?
I am a little surprised to find such an issue in Google software as it is a topic for first semester CS undergraduates ;-)
Since it's accessibility based, it's more laudable than teaching CS students how to center a div, but it's not like it really requires a mentor of some sort to express the nuances of, right? Or even if it does, it's still design.
A good CS degree definitely has the space to teach some basics in that area. To mention Gestaltgesetze, to explain human perception a bit, and give an introduction into usability. You do not get a useful developer in the end otherwise
Not all developers do stuff with UI, and of those that do not all do anything with a UI that is actually graphical beyond a terminal.
> since you need to understand basics of human perception to understand compression in that area (jpg, mp3), they talked about stuff like that.
That is a good reason to teach it, and counters my overly assertive original comment.
> Full-page screenshots. Take a screenshot of the entire page, from the top of the viewport to the bottom.
I'm surprised to see the Chrome developers not know what 'viewport' means.
Hardware (laptops, phones), and browsers js and rendering engines, are all 10x faster than they were 10 years ago, giving 100x to 1000x overall speedup. Think about that, it is truly incredible. But web pages are also 100x larger and less efficient than 10 years ago. This is absolutely not justified by productivity increases. This is just how the world / humans seem to work.
Remember when Emacs meant Eight Megabytes And Constantly Swapping?
... and daily standups? so busy working that there is no time to do the job
From my limited knowledge of your situation this seems like the last move to take. I would try the following, in roughly this order:
Serve libraries (Angular, jQuery) from a CDN to at least have the chance of hitting a browser cache on a visitor's first encounter with your site.
Use a minifier to strip all the unnecessary comments and whitespace (in addition to other benefits from minimization).
use gzip to compress the remaining minified files.
Those alone will likely significantly impact your load times. At this point, the remaining dead code should be relatively small and you can look into tools for surgically removing it.
This part is more of a shameless plug, but I believe public/industry/developers should be aware of what tools & techniques academia develops so that the researcher's efforts can be more useful. There are some static analyzers for JavaScript such as JSAI, SAFE, and TAJS (disclaimer: I'm working on a project related to JSAI on the lab which developed it). These static analyzers can discover the dead code if given all the entry points however:
- They don't have facilities to report the dead-code AFAIK (this is a trivial thing to add _in theory_, if there are parts of the program _unvisited_ by any of these, that part of the program is guaranteed to be dead). If somebody wants to add such a facility to any of the tools they are welcome. In case of JSAI, I'm willing to provide them all the information I can.
- They are conservative (e.g. sound) tools and may find too few dead code results.
- They don't play well with `eval` & friends in general although they try their best[0], the web frameworks rely on eval-like highly-dynamic approaches a lot to be generic enough and that hurts precision of such analyses dramatically.
[0]: https://pdfs.semanticscholar.org/8140/feec021818815c55a43b54...
[1]: https://www.cs.purdue.edu/sss/projects/dynjs/eval-TR.pdf
We're starting to get there.
JS Modules gives us static exports/imports, so we can statically analytics the dependency graph and identify functions that aren't used and do tree-shaking to remove them. Rollup and Webpack2 already does this, but there's more to go.
CSS Modules creates a contract between the your CSS and what uses it. As you have to import it, and exports are static, you can understand which style files are imported where. Next step would be to understand which classes are used inside that module and strip those that remain unused. This is theoretically possible (providing you use a more 'statically safe' syntax), but tooling hasn't yet popped up to do this.
[1] http://blog.mgechev.com/2016/06/26/tree-shaking-angular2-pro...
Ah, so this is how front-end got the way it is.
Plus for the time you spend chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site. For less than 40ko.
People are not blinking at including react ecosysteme, which is huge. But attack jQuery ? Seriously ?
I don't know about you, but usually my projects last longer than a week, so those sorts of savings don't represent a significant chunk of my overall development time. Also, I'm not a shit programmer, so I can actually write a for loop that does what I want on the first try. I've spent more time trying to figure out jQuery's goofy syntax and what the hell it's doing with AJAX queries than it has ever saved me in development.
Event the damn native APP for hackernews, using only JSON, is not usable in 2G.
Why doesn't fetch and its polyfill cut it?
And even then. You need to encode params manually.
And of course no middleware, so for special decoding or repeating headers, you end up writting a wrapper.
Just by making a function you're not creating a library. Sometimes I find DOM API verbose too. Nevertheless the fix does not need to be a interface like jQuery to completely hide DOM API under another interface. It may be enough to extend the HTMLElement prototype a bit or write a function to "compress" the code a bit and make it more readable.
Have you seen what passes for a library on npm?
You lost me here. Anybody extending standard objects cannot be taken seriously.
Also, to be clear, I'm suggesting adding new methods to DOM object prototypes, not changing behavior of existing methods.
So, you don't like the polyfill, created to the specification. Fine, but depending who you target, you might not need it. Plenty of modern browsers have good support.
> And even then. You need to encode params manually.
Or use the Request constructor.
> And of course no middleware, so for special decoding or repeating headers, you end up writing a wrapper.
Request constructor will let you handle the headers quite nicely.
Yes, it is.
> It's a dozen lines, not a thousand
A polyfill can be any size, but there's no size minimum to be a library.
A polyfill is a short snippet to implement a missing feature. Notably almost all recent additions to JS and DOM have been designed to be polyfillable where possible. Generally that means under a thousand lines, by the way.
A library in this context means a set of functionality built on top of the platform, like jQuery, with its own API, etc. "Use a library" and "use a polyfill" are not the same advice.
A polyfill is not a library.
Um what? jQuery is huge. You won't possibly use everything in it.
curious as to why you think this? fetch is pretty convenient to use. We created our own wrappers around it, but that basically just consists of ajax = (url) => fetch(url).then(res => res.json())
Or you can use the few ko of jQuery.
Now bundling it with the rest of your JS, that's indeed a mistake.
- NoScript, which blocks execution of scripts save for those you whitelist. This means sites that reasonably require JS (e.g. YouTube, Google Maps) can remain functional.
- A bookmarklet that redirects you to the Google text-only cache of the current page, which is great for text-based articles that inexplicably require JS to show content.
javascript:(function()%7Bvar%20loc%3Dwindow.location%3Bif%20(window.location.protocol%20!%3D%20%22https%3A%22)%7Bloc%3Dwindow.location.toString().replace(%2F%5Ehttp%3A%5C%2F%5C%2F%2F%2C'http%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3A')%3B%7Delse%7Bloc%3Dwindow.location.toString().replace(%2F%5Ehttps%3A%5C%2F%5C%2F%2F%2C'https%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3A')%3B%7Dwindow.location.replace(loc%20%2B%20'%26num%3D1%26strip%3D1%26vwsrc%3D0')%7D)()
You gave them permission. Actually, you asked them to do it when you sent that GET request to their servers that returned a bunch of HTML that included script tags.
And what if the user does not download the .js file?
And what if the user downloads the .js file but does not run it in an interpreter?
What if the browser authors refuse to process what is enclosed in script tags and to run Javascript?
Maybe they believe it consumes too much memory.
Based on your comment (trolling?), I think maybe Javascript is not the problem. It is developers with thinking such as yours.
If we put inline js or links to .js files in files requested via HTTP, then we cannot claim that users "chose" or gave "permission" to fetch these .js files or to run them. As another commenter stated, those requests were not initiated by the user, but by the browser.
The selection of browsers is small, and made smaller by web developers who promote use of certain browsers i.e., big fat intepreters that will run their needless Javascript. (The keyword is "needless". Almost always users can get the data they seek without running Javascript.)
These "favored" browsers present a massive memory hog and attack surface compared to the minimal tcp client required to retrieve text via HTTP.
If you dislike HTML, then don't use it. Use another format that serves your text-only needs. Gopher is a possibility, just don't click on any HTML files if you're using a web browser though.
I know! Laborious, but it must be done.
I got into this habit because of the insane number of websites that have gotten into autoplay which essentially eats up all my mobile bundles. I love forbes for instance but it's essentially unreadable when on bundles.
Just wish there was a way to install Opera Mini on Windows tablets...
Plus it wasn't very good on mobile, even when it was supported (ie - on Android it was still bad and never got out of beta anyhow)
People always complained about how Flash "drained batteries" / "crashed browser" / "allows all this intrusive advertising". A case of blaming the technology for the way it was being used. People would say "I can't wait until Flash dies and we have the open web standards instead so we don't have these problems any more".
So, fast forward a decade or so, Flash has been replaced by open web standards and ... guess what? We still have those problems...
1) Javascript is bad (vs. Javascript is good and variations thereof)
2) The use a lot of websites make of Javascript is overcomplex, gratuitious, uncalled for, intrusive, etc.
3) Sites should provide some (even minimal) functionality to people browsing them without Javascript
#1 is largely a matter of personal opinions
#2 is a known, undeniable fact
#3 is where everyone could contribute
Personally I browse normally with javascript turned off since years (and I use another browser with the capapbility to display the site "fully" when really-really needed).
Particularly when browsing HN, I follow given links and often avoid a lot of pop-ups, ads, and what not, and from time to time, when I find a site that won't load AND I really think that the linked to site is worth it, I use the "other" browser.
What is curious is that most "new" products, Saas, whatever simply fail, showing just a blank page, that is exactly what the site shouldn't do.
I would gladly accept a "You need Javascript enabled in order to fully appreciate the site" kind of message, but only if some (basic, simplified how much you want it, even text only, etc.) content is shown nonetheless.
I simply cannot bear the "blank page" or the "Your browser is not supported, please download Chrome, Firefox, Internet Explorer and try again".
This makes me sure that the people behind the site in the best case have not understood the "showcase" nature of a website and in the worst case care nothing about user (please read as customer) experience.
So, if you create a site, consider how a part (even small) of the visitors may have not javascript enabled but they are anyway potential customers, they are somehow anyway interested in your site contents, by making their no-javascript experience so miserable you are turning them away from your site, sometimes forever, which is the perfect negation of the reason why you put the site together in first instance (to make your whatever content visible to the world).
For example, imagine a forum where clicking the "edit post" button turns your post into a <textarea> editor and saves with AJAX so that you can continue scrolling once you make your edit.
To build the JS-free version, you typically need a separate endpoint, a new template, a redirect, and a less empowering editor. And all this for UI that 99% of your users won't see.
It just doesn't seem like a opportunity cost savvy way to build a website.
Then there are the UIs that take some real backsplits to accomplish without Javascript like a table that lets you mass-modify the rows with checkboxes and a <select> at the top that lets you choose options like Move | Archive | Delete.
You can wrap the entire <table> with a <form> such that all of your checkboxes submit to your mass-modify endpoint. That works without JS.
But since you can't nest <form> within other <form>, your <form method="DELETE" action="/things/{id}"> delete buttons can't appear in each row.
I have a hard time understanding how so many people in these threads can suggest that the opportunity cost of building for the 1% is always worth it. Does everyone just have basic blogs on the mind when they envision the labor involved in what they preach?
When I go to a blog post linked from HN and see a white empty page I will just move on.
Of course they can. The <form> action submits via POST to an endpoint that disambiguates the selected action, and forwards inside the server side to the appropriate endpoint. Shouldn't be hard with a competent framework.
Then, when JS is enabled, you override the click action on the action buttons, so that the <form> action never gets used.
I think it depends on the user demographic. If you're actively developing a service that you hope to be used even in the most deprived areas with outdated equipment and poor connections, then it may be worth it. For example, outreach programs, charities, and emergency services.
If you're developing something that is more or less a needless, but useful, product -- your demographic is more than likely the upper 30% of earners in the world... yeah, probably not worth your time to develop for that 1% who won't be using JS (or have the capacity for only older versions).
It has been somewhat humbling to watch users on low speed connections use the app before the JS finishes loading; it shows everyone the true value (or lack thereof, for the passive content consumers who make up ~98% of the visitors) of the JS portion of the app, since they see it with and without JS. Sure, they can't drag a box on my fancy visualization, but they can see a snapshot of it, and use the peripheral controls as links to navigate to the desired application state. Then, as they are reading something that is useful to them, the ~2mb JS blob slips in and quietly brings the application to life.
Also, I love the way the 3rd party JS blobs that management mandated, are so obviously slower than the rest of the page. This gives me good ammunition for the arguments where I demand an HTTP API, not a JS blob, from our partners. They hate that, because then they can't stuff their own trackers into our clients. Fork 'em.
From a comment below.
Some people may like it, but I'm just saying that it's not a feature that isn't disliked by some people.
Some people are so scared of "premature optimization" and "catering to a tiny number of geeks" that they trick themselves into making a huge JS mess. Most websites these days seem to be examples of this.
I browse with JS on (but I block ads and most tracking scripts) and only use a separate browser profile with JS off for sites that look fishy.
Requiring JS for a web app or interactive features in a website is fine.
A few years ago I had to use an old PC for a while, and disabling JS by default improved my experience significantly, but too many websites simply didn't display any content without JS, or didn't load images. The "web apps vs. web pages" debate has been beaten to death, but being unable to e.g. read a blog post without enabling JS just feels wrong to me.
I'm not sure if things are as bad now.
This is reasonable logic and I think it is an important point in getting more people into a technology movement, whether it is removing JS or anything else. A similar example is getting encrytion: many users don't know or care to use it, so it is usually a side issue if mentioned at all in a company. But if the percentage of people who do use it increases, companies will have a greater interest in supporting it.
Currently, normal users just care that content loads when the click the link for a website, and perhaps don't understand or care that JS is running or what the consequences of that is. A more constructive way to get better experience without JS is to ask others to also block it to show companies that this is an issue, rather than just directly asking companies to add support.
1. You browse without JS. You're a power user. You already know why the page doesn't work. A courtesy message would be nice, I guess, but it seems fairly pointless.
2. Should my HTML and CSS still target IE7-friendliness? IE7 users still have more market share than actual humans who browse without JS. They get treated like lepers in the Year 0, and we all seem to be okay with that.
3. Well-designed use of JS can help distribute computation load that might otherwise all fall on the server. A very contrived-to-be-important (but fairly common) example of this is scaling/cropping an image before it's uploaded. Or, even though I have some other reasons to hate on SPAs, page rendering itself. The no-JS user is more expensive to serve than the typical user.
4. Except for some extreme cases of JS reliance, search engine spiders are a head and shoulders more accommodating to developers' choices than no-JS users are.
I just don't think that making accommodations for no-JS power users, who are not plentiful, and know full well how to turn JS back on, is valuable. Making JS bundles smaller and making them load more efficiently? That's a worthy cause for sure. But people who browse without JS at all are extreme outliers in the 1st world, and all of them know how to toggle it back on. Developing countries? If I were trying to serve those users I would do the research and make choices accordingly.
Well, the point is that a lot of people post their site on HN as "Show HN", and the "intended audience" is then (or should be) "power users", which should also mean that "power users" (few as they might be) are potentially interested to your site, but you make sure that only a subset of these power users can access your site (not necessarily in full, sometimes a simple text summing up what the thing is about would be enough to either - as I do if the page doesn't load - discard it or get me interested enough to turn javascript on/use the "other" browser).
If you don't post your site on "Show HN" the missing "no-javascript message" is only a (small) lack of courtesy, if you do post it, it sounds (to me) like a plain lack of attention.
In the real world, you open a new shop in town, and advertise on the local newspaper "everyone is invited for the shop opening tuesday at 7:00 P.M.", than you put at the door a couple big guys that only let in those dressed "black tie". I do have a suitable attire, but I am not going home to change into it, not without having at least the possibility to peek inside your shop and see what it is about. Will I become a customer? Maybe yes, maybe not, but more likely not.
You could just read the Content-Length header and drop the connection if the site is over the user's limits (at which point you'd want to display a status message instead of the partial site).
<meta http-equiv="refresh" content="1;url=http://www.example.com/nojavascript" />
which show a usable flash of the site for one second and then bounce me to a useless "You must enable JavaScript to use this site." page. By the flash I know that this is technically not correct.
Except JavaScript blows, the emerging JS extension ecosystem that tries to fix that is still highly in flux (and mostly blows), so developers try to keep their server-side stuff NOT JavaScript, and then supporting server-side rendering means re-implementing everything twice.
Of course, this doesn't excuse document-centric sites like news and blogs.
2) I think this is actually a cultural problem. Are users steering away from overcomplex/bloated/intrusive websites? If not, why not?
3) That's an argument similar to should a site support IE8? IMO it really boils down to the cost vs the benefit of supporting user without JS. And that of course will depend on your target users.
Simplicity is having one place where the DOM is created and managed, and optimizing for the 99% use case.
Complexity is splitting up DOM rendering over two networked systems for servicing a 1% use case.
Browsers are JS runtimes now. Get over it.
If your site doesn't work, I don't care, I will go to a different one.
I may be the minority now, and while there is some great use of js out there; most of it is bloated, slow, insecure, and often privacy destroying.
It is not a question about JavaScript or not. It is a question about well developed site.
The idea of browsers sending data that the user has explicitly elected to send (in addition to, if we're being pedantic, that the server put there in the first place) is very compelling in this day and age - only problem being that in order for that to have any meaningful impact on web security in the general case, you'd have to more or less universally deprecate JS support, which would set the web in a very different direction indeed.
You will also be in the minority later
Sorry, I won't. I don't trust you and I won't simply run your code by default. It's not like I actually need whatever your web site wants to provide; there are plenty of other things to do on the internet.
Sure, dude, ignore anyone without a machine that can run MBs of JS within a reasonable time.
I'd wager 90% can even run the strawman you're building
I'm amazed at how many websites there are on my phone that take 15+ seconds to load... and they've clearly been "optimized" for phones in the sense that the site reacts to being on a mobile browser and lays itself out for a phone... if I wait for the whole thing to load.
(I see this less often, but it's also amusing how many sites pop up their "hey, you've been here for three seconds so clearly we are an integral part of your life from now on even though the main page layout isn't actually done rendering, would you please like us on facebook, subscribe to our newsletter, and tell us your mother's maiden name and SSN? [allow this site to use location services [yes] [no]] [allow this site to push notifications to your home screen [yes] [no]] [allow this site to enter your bedroom at 3am to remind you how much it loves you [yes] [no]]" dialog where both the X to close out and the submit button is unreachable, because the position and zoom is fixed and the whole thing is too large.)
Subsequently loaded-pages or resources can be significantly faster in webapps however, as they can request (or generate) exactly what they need.
The problem of slow initial loads is being addressed by tools like React by offering server-generated pages on the first load, and then transitioning to JS-based loading for subsequent loads. This offers the best of both worlds.
Obviously you can't make a web app without JS, but I still think you should minimise JS, or remove it if the site truly is static. It's just a better experience.
I often read in subway, where I need to load the page in 3-4 seconds or I'm in the tunnel again without the signal. In some stations I only get 50kbit/s or so.
Most websites don't cut it so I don't even bother. Those who cut it though, I get engaged with more, because I can't go anywhere else without a signal.
In a nice world I would write a scrapper + alternate website that hosts only the content and some simple navigation over plain HTML, preferably with as little CSS as possible. There's the annoyance of copyright though, so no way of making this public.
Less javascript would be an improvement for everyone, not just the noscript users.
so, win-win?
As much as I hate JavaScript, Google Maps gets a pass. I'm pretty sure the code behind it is thoroughly tested. We can just suck it up and turn JavaScript on for one of the most useful tools from the internet -- how hard is it to find something that whitelists domains to run JS anyway?
Compare that to sites where you just get a blank page.
It also had a habit of freezing an older (core2) laptop I was still using completely (with Firefox). Not just the browser, the whole OS. Had to power cycle. From time to time I'd forget and go back to Google maps were the cycle would repeat.
Why was I still using a core2? Because it worked fine for almost everything else. Got a better second laptop and no more issues but still... there wasn't anything wrong with the first.
Now that I've updated to 16.04 firefox runs better than it did but chrome still blows it away.
1. https://developer.mozilla.org/en/docs/Web/HTML/Element/map
I do miss the days when people considered JavaScript an enhancement and not a dependency.
Server side rendering has been a big priority in React, Vue, Redux, ReactRouter, etc.
Usability is also a problem. JS heavy sites often break standard web expectations such as the back button. They are often overly complicated, favor design cleverness over usability, and don't work on mobile devices.
Sure JS is great for web applications but is really needed for every single site? Whatever your view it is at least worth discussing whether or not the status quo is misguided.
* existential: questioning the zeitgeist is taboo, especially with the amount of momentum the web has
* personal: it implicitly devalues the skills some are investing large amounts of time
However, once a new platform emerges (and one will), devs will have to deal with both of these issues anyway, so they might as well start.
There is one function on the server that you need to use to render any component you imported.
I know there's a lot of work done on making server-side rendering work with React / Vue / whatever, but I'm wondering if there's a framework available that asks for some tradeoffs in how your SPA is structured in order to maximize the amount of functionality available when scripting is off (similar to how Redux asks you to make state-management tradeoffs in order to get hot-reloading, dev tools, etc.).
For example, you'd probably want, at a minimum:
* By default, all code related to fetching or subscribing to data from a server is tied to URL routing.
* By default, all code related to sending data to a server works with standard webforms.
The closest analogue to what I'm thinking about is Turbolinks and Ruby on Rails, but I'm curious if there's some equivalent in JS-land because you'd get less context-switching when adding extra JS-only SPA interactions on top of the core JS-optional form-based interaction.
The nice thing about this, though, is that most of the work happens up front, and as long as you develop the app within the proper constraints, server-side rendering is more or less "free" after that.
It's good to have a standardised way of doing all of those things anyway, and when you do, you can make sure they all work on the server.
I was experimenting with this [1] a couple of years ago with React, react-router and a form library based on django.forms. The key was to handle form submission in components which behaved like they were servicing a request on both sides, passing in the POST body on the server or form data extracted in the same format on the client.
There's some not-so-fun plumbing to make sure everybody has the data they need to re-render with user input and validation errors when they happen, and to handle redirect-after-submit properly on both sides, but I initially had to hack some of the necessary plumbing into a pre v1.0.0 react-router so the specifics are probably no longer relevant.
Ex: Make a request to an API upon page load. Populate tables or whatever you want. Then if JS is enabled, load a script that makes AJAX calls to the API to update the data every x seconds. That way your site gets "enhanced" by JS and is completely usable without it.
And if you want to allow JS-enabled browsers to transition between views (and different data subscriptions) without having to reload the entire page, then you'll have to write two pieces of routing code (one route in Rails/Django/whatever and another in JS).
And if you want to allow JS-enabled browsers to post form data back to your server and make minor changes to the page (e.g. edit one field in a table) without reloading the entire DOM, then you'll have to write two different routes on your server -- one that processes the form data and returns the HTML for a newly rendered page, and one that processes the same form data and returns only what's changed.
You could, of course, use server-side-rendering JS to DRY things up for issue one. I'm more curious if anything reduces the boilerplate for issues two and three.
There are some sites that require JS to render, but the great thing is that majority of pages I visit work just fine as plain html/css. In general I feel less distraction from popups, overlays, ads, etc.
However, neither offers a UI for whitelisting specific scripts, which I see as an important feature in the Year of the CDN. I think NS has that feature but it's hidden away in the preferences.
What might be helpful now is something like a MAX-JS-BYTES=n header that tells site owners that the useragent will ignore any JS beyond the first n bytes on the page, and will not request more once that limit is reached. (I know this is a terrible idea; hard byte limits could never work. But somehow site owners need to be made to feel more immediate pain when they screw their customers with too much JS bloat because they've hired lazy developers, or because their idiot VP of marketing is all about TEH BLING.)
One might say, for other reasons, that Mozilla is 100% to blame for all of it.
I love this idea. Web development seriously needs some discipline. Myself included.
I've always been a JS hater, though I have to code it frequently.. However, with that said I find the arguments against the language becoming more and more obsolete as the years go on.
The best FE devs make sure that they create functioning web pages first. Then they go ahead and make them better with some JS. Only the least competent/laziest developers create JS only sites (this is discounting things like JS games etc where there's no text or images, or pretty much anything that can be done in HTML).
I find it frustrating when these devs try to paint the web as something more advanced, or somehow different (seriously, it's not a special snowflake) in order to try to validate their preferred way of working. It's unprofessional to their employers, it's a disservice to themselves and it's a big "screw you!" to their users.
For people with powerful smartphones and reliable internet, this may be true.
Let me point you to: https://danluu.com/web-bloat/ (discussion: https://news.ycombinator.com/item?id=13601451 )
Now add the fact that:
- the ecosystem is exploding like a holy grenade, only not as funny
- having to learn what "rebinding this in the closure's callback" is still core to the path to the language understanding.
- you have so many ways to do things, especially asynchronously, and yet no simple way to do simple stuff like removing an item from an array
- pre-processors are used everywhere and you have so many of them
- safari is becoming the new IE6
We are still very much paying the price of the terrible language that is Javascript.
The article shows quite nicely that it's completely possible to create great websites without the requirement for JS to work well. Make it an enhancement and your users will love you for it. Make your users love you, and your employer/client will love you as well.
"I’m a 30-something woman living in Berlin, Germany (the famous one, with the wall and stuff)."
I take this to extreme on mobile apps, only native ones get into my devices. If it looks like a web widget after being installed, it gets the boot shortly afterwards.
https://mikegerwitz.com/talks/sapsf.pdf (slide 60 / pg 115, "The Web---Mitigations & Anonymity").
There's a bunch of stuff before that slide that's mitigated by JS, including things like ultrasound cross-device tracking and hardware fingerprinting.
On the other hand, JS allows us to build great user interfaces which better to use than our old school point and click adventures we use to have. And if you do it right the performance is also ok, but it is also not so hard to fail and ruin the whole user experience by rendering the scene twice every frame ;-)
My current off-work project is a web application, that is built with Elixir. I've written 0 lines of JS. It feels really good. This is my way of internalizing some of the points made here[0]
If you're referring to screen readers, I was under the impression that pretty much all of them execute JS these days. Am I wrong?
One significant enhancement (w/o JS) is that you can type something in the search bar without losing your current results while you're typing.
Tested and working, for a while now.
This policy makes it pretty much impossible to use social media, because social media is basically blogs-that-require-javascript. I see this as a beneficial side-effect.
There are exceptions when I use JS. When I have to use someone else's computers or manage certain accounts using the www. The later not being by choice.
In the 90's, there was an attempt to allow web developers to run their code on the user's computer via the user's web browser. This was called Java applets.
There was no limit to the pie-in-the-sky promises that developers were making back then. All based around the web browser and Java.
Not surprisingly, Java applets failed. I think there were some security issues. Maybe. Not sure.
Javascript reminds me of Java applets.
I am not sure if there are security issues with Javascript. From discussion surrounding this language, today we are asked to believe there is nothing that cannot be accomplished with a web browser and some Javascript. Unlike Java applets, this time, it is real. I think.
But, as far as I know, I too can do anything I want to do without using Javascript. And without using Java applets. If there are websites that truly require Javascript (see below) in order to access data, I cannot find them.
1. require
Here, "require" means that the data could not be served to the user via any other e.g. more direct mechanism than through a series of steps that includes Javascript being run by a web browser. Here, "require" does not mean the choice by the website owner to use Javascript in this way or a message displayed to users that suggests "Javascript is required". The meaning here refers to technical capabilities not design choice.
Maybe the maps product wholly depends on JS for all functionality?
What is simplest: A full website in Elm, or a website developed in a plethora of HTML, CSS each with at least a handful of libraries?
Well, Elm needs javascript..
All in all: there is not need to be religious about the tech stack.
SPAs can also support traditional URLs for bookmarking, indexing, etc.
> …it’s a sad indictment of things that they can be so slow on the multi-core hyperpowerful Mac that I use every day, but immediately become fast when JavaScript is disabled.
> It’s even sadder when using a typical site and you realise how much Javascript it downloads. I now know why my 1GB mobile data allowance keeps burning out at least…
As a developer, I understand not wanting to devote a large amount of time, catering to some insignificant portion of your audience who disables JavaScript.
And I love JavaScript, but I cringe at the thought that we are needlessly slowing things down with MBs of JS that change too often to be meaningfully cached.
If you are serving MBs of JS after gzip, please make sure that I am not going to have to download all of it every time I pull up your site on my phone every week or so.
As an aside, it's very difficult to contact feedly directly, but they do have a uservoice account (https://feedly.uservoice.com).
What totally breaks is when you do a complicated bank transfer or work on some older site. They often transfer you across multiple domains, so whitelisting doesn't work, as you can't anticipate what site to whitelist (when you check your points, bank.com redirects you to bankrewards.com, things like that).
What's really needed is a chrome extension to let you turn JS off and on, and if you turn it on, it can be set to auto-turn off after some time. What would be even better is if Chrome offered this behavior in an easily accessible way.
Every time I set up a new browser, NoScript is the second plugin I install, after uBlock Origin. Between the two, the web is far less annoying than it used to be.
> Verdict: Failing… to not work. Sad!
Delicious.
"An engineer is someone who can do with ten schillings what any fool could do with a pound."
By this definition one could argue Javascript developers are not engineers.
If the user can get the desired data from a website without having to run 4.5M of js in a large browser, but the developer "needs" 4.5M of js and a team of people to deliver the data, then who is the "engineer"?
'Support the 0.1% of people without javascript' usually doesn't make it beyond the bottom of the backlog.
It is the Javascript and website complexity, the embellishment of data with needless garbage, that necessitates "support" i.e. work for developers. It creates more work.
Serving text without embellishment requires less work, not more.
At some time or place in every website development project, data exists in plain text or some other raw form.
Some users might just want that data as it is, without embellishment, before web developers even start working.
This requires little if any "web development" work. Basic HTML can be autogenerated with ease.
<a href=http://example.com/data>Data</a><br>
<pre>
Description: blah, blah, blah
</pre>
# usage: $0 section
# sections: world, etc.
curl -4o .$0 https://static01.nyt.com/services/json/sectionfronts/$1/index.jsonp
exec sed '/\"guid\" :/!d;s/\",//;s/.*\"//' .$0
Meanwhile we are having this discussion on a web site that does more or less exactly what I am suggesting. It can be easily autogenerated. The HTML could have been written in the 1990's. It is trivial to remove the tags and have plain text.
I guess we are the 0.1% that would ever access a website that did not need Javascript?
The fact that the popular browsers run all manner of javascripts and process all sorts of tags does not obligate anyone to use them. Whether it is web developers or users.
It's a kind of software used to make websites where you write your posts in a markup language like reStructuredText or Markdown, and once done a script transforms it into HTML and CSS. Various plugins exist, including for comments, although this tends to sacrifice your "staticness" in varying degrees, especially if you just use Disqus.
var contentSettings = chrome.contentSettings;
contentSettings.javascript.clear({}, function() {
contentSettings.javascript.set({
primaryPattern: '*://*/*',
setting: 'block'
});
});While that's true it's not reasonable to assume the user has JS enabled. Ad-blocking plugins that also block JS are increasingly common.
and it's no longer reasonable to expect all websites to work very well without it.
The question should be "what does work very well" actually mean?
For a closed application that requires the user to log in I don't really care. Users won't use the app if it doesn't work for them, so it's entirely up the developers to build something the users want. Talking about web applications is silly. For a public-facing website though, I would expect it to at least work without JS even if it doesn't necessarily present as good an experience as it would with JS (which is nothing new, it's just progressive enhancement). The problem is web sites that present an essentially a meaningless page (blank, no content, populated but broken, etc) to users who have JS disabled. That's where work needs to be done.
What percentage of users do you think block JavaScript? I'd be utterly shocked if it were more than one or two percent.
Why?
Instead of building for 0.5% of users that can just enable JavaScript, why shouldn't I invest the time into building a new feature, writing more unit tests, or writing an app for Windows Phone?
<script src="//cdn.example.org/few-jigabytes-blob-6d96270004515a0486bb7f76196a72b40c55a47f.js"></script>
<script type="text/javascript">
import ReactDOM;
const HowQuestion = (text) => {
return (<p>How {text}?</p>);
}
const Comment = () => {
const text = \
"the year justifies using Turing-complete programs"
"to express what could be a simple static text document";
return <HowQuestion text={text}/>;
};
const el = document.querySelector("#14507550 .comment");
ReactDOM.render(<Comment />, el);
</script>Just like me! I also suffer from the same disease, but on a much more serious level… lol! Everything just crashed yesterday and the count was on 270+… :-o
I have something like 300 tabs saved in One Tab, which is a huge improvement on what it used to be (> 1000).
Actual web applications, like e.g. office suites, map applications, ect. are obviously extempt from "should work fine without JS" rule.
Obviously there are disadvantages as well, but it's a tradeoff, and if executed correctly it's one that, as fewer people turn off JS and browsers become better at running web apps, is increasingly becoming worth the complexity for certain use cases.
JavaScript is a core part of website development, regardless if it is not the only way to do it. It is unfair to judge websites on whether they can run without JS.
Because she left it up to the end user, how about "A day without JavaScript is like a day without a brain bleed"?