I generally agree with what he is saying, but the web has moved beyond the point where its reasonable to expect websites to have JS fallbacks. It is just too prominent now a days.
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.
It's not becoming obsolete. Because of legacy code, docs and the fact the old behavior is still valid JS, beginners are still completely lost because of this bad design that never been fixed, only compensated by adding things.
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.
It's not unreasonable to expect hyperlinks or images to work without JS. Fancier stuff sure, but basic navigation through a content only site should be functional without it. This is what HTML does and you have to be profoundly lazy to screw that up.
This is really the problem I think. It's not as much fun to create something that functions properly.
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.
My favorite pet peeve is JS links, that aren't actually <a> links, but spans or divs with click handlers, so there's no way to right-click->open in new tab or ctrl-click->open in new tab. It's like intentionally doing something that is harder, and works shittier; I don't get it.
My favourite pet peeve is the lyrics wikia, which has some css embedded in a <noscript> tag that blocks out the lyrics and replaces it with a "sorry! This site requires javascript" message.
Not for me, I only use web apps when there are no native alternatives, even though I also do web dev when customers require me to do so.
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.
No, it hasn't really. I like JS, but I think the attitude that it's a requirement now really needs to go away. I'm hoping it will when the current generation of more junior FE devs start to grow up and realise their work is about the users and their clients, not about what they want to do.
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.
One of my clients loads a 4.5 Mb bower.js (including Angular with a lot of components and jQuery), they also include an extra jQuery script, a full jQuery UI and several other scripts on each pageload. Nothing is minimized. The bower file alone has 300k in comments.
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?
Yeah. Except you need to do Ajax and fetch doesn't cut it. So new lib. And manipulate the dom with something better then the browser API or you loose your mind. So new lib. Then normalize browser events. Oh wait, you can do that manually. But you are writing a new lib. Eventually the code will grow to be the size of jQuery anyway. Only not as well tested, documented and cached.
Programming is mostly creating functions and interfaces to decompose problems into reusable parts where reuse makes sense. Nothing wrong with creating a simple function for making XMLHttpRequests or for fetch API. Most of the time there's no need for the level of generality of jQuery interfaces.
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.
Do you realize JavaScript is a prototype based programming language? It is a major and very useful feature of the language. There's no reason not to use it. There are some things to be careful about with interop if you need it, but that's it.
We've already learned from our past mistakes changing the prototype of the standard library - the Ruby community learned the same thing with monkey patching their standard lib too. The maintenance overhead far outweighs any immediate benefits.
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.
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.
CDNs are a lie. The privacy implications outweigh the performance benefits since there are many, many, many CDNs and many, many versions of jQuery. It's rare for users to benefit from caching.
Also, the performance benefits from free CDNs that you have no service level agreements are unsubstantiated at best, but you'll notice very quickly how much your site is broken when your CDN is over capacity.
You can implement an minimal ajax interface in js (no jquery) in less than 30 LOC. But I grasp what you mean, it not just that. There are other concerns and requirements and you do not want to reinvent the wheel everytime...
Network bandwidth usage is also not the only metric of size we care about. After it's ungzipped, it needs to be parsed by the JS engine, and more code = slower execution.
Sure, if all you do is some onclick() and a few appendChild().
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 ?
> chasing compat issues, writting wrappers, choosing small libs and packing it all together, you could have done your site.
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.
Oh. Well that's true, but I think the point is more like you end up implementing some significant subset of that, except with homespun code that isn't tested as well.
Event + Ajax + DOM is most of jQuery. And is most what your webapp is. Now I'm more of a fan of Vue.JS + axios myself. But if I have to go minimal, 40ko of jQuery is nothing and save so much trouble. All the "you don't need jquery" thing is done by people doing prototypes that are not tested on most browser or assess in term or ressource vs reward, which is a lot of the projects in the JS community.
> Except you need to do Ajax and fetch doesn't cut 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())
Exactly, you had to write a wrapper. And the next project will do so. And if you want to save time, and improve reliability, you'll test it, and write doc for the 3rd. And the new team member.
Good luck supporting old android browsers, IE and dealing with the inconsistencies between browsers. It only takes one look at the jQuery source code to understand why it's not a good idea to "roll your own jQuery".
Simply don't target old browsers. If people don't use JS, or don't have a modern browser, feel free to go elsewhere. I don't target edge cases as I don't get paid to.
That's interesting! Do you know if it is possible to access this data from an extension? I would love an extension that crawls through the website and combines the data for all pages.
Note: The color-coding is likely to change in future Chrome releases. <-- Well, someone eventually found out that some people cannot distinguish red and green, but it was too late :-D
I am a little surprised to find such an issue in Google software as it is a topic for first semester CS undergraduates ;-)
If it was actually part of the curriculum I sure hope that it was in some design centered elective class. IMO if your CS degree spent time teaching that as part of the core curriculum, they missed an opportunity to put more Math, PL theory, and interesting algorithms in there, because there's more than can be sanely covered in any one curriculum.
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.
It's some years now, and there were at least two courses in which it could have been. The one was elected, HCI. The other was not, it was an introduction into graphics and audio, and since you need to understand basics of human perception to understand compression in that area (jpg, mp3), they talked about stuff like that.
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
I taught a ton of a11y stuff in my intro to web classes. Even did screen reader demos. I wasn't the only one. There are lots of folks teaching this stuff. Not a critical mass, but I'm so thankful it's happening. :)
I learned it in both my computer graphics course and my user-interaction design course as part of my CS degree (German university). None of these courses are required, but they are popular enough that the most important lessons were pretty universal knowledge among students.
Seen the same on maps where green is a good route and red is a dangerous route. Switched to a blue -> light blue -> yellow -> orange -> red -> black scale with great success. I also believe chemistry uses blue to mean safe, not green.
Even more off topic, but after Firefox (before Chrome) had introduced this feature in dev tools, they also recently introduced it as extension (and it might even work on Chrome)
uncss[0] works well for me. It removes the unused styles and then I run the css through a minifier to finish the job. The css filesize is greatly reduced.
Yes, it's called "tree shaking"[1], modern Angular apps can be cut down to a around 50-100k (assuming nothing heavy feature set). Find build tools that can do it, like Webpack or Rollup.
> Serious question: are there any tools that can scan a full website for unused code and unused CSS?
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.
I don't think more powerful tools are the solution here. The problems and solution are obvious. The root problem is that many "product" teams will take any 10x improvement from tooling and adapt by being 10x more inefficient. Because they can.
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.
Developers tend to over time expand their programs to fill available memory and take up available CPU, too. My currently open text editor's memory footprint is apparently 36.6MB, and it is displaying a single file composed of ~1000 characters.
The scary thing is that I actually consider that to be remarkably small. My current Emacs session (recently opened) is just over 200 MB is size. And Emacs isn't even considered a hog anymore compared to the real hogs like Atom.
Remember when Emacs meant Eight Megabytes And Constantly Swapping?
Lol @ testers. How about getting rid of the project manager and testers, and hire 2 decent developers who have some experience with automated testing, continuous integration and continuous delivery instead? Productivity rises 300% I would presume.
> Serious question: are there any tools that can scan a full website for unused code and unused CSS?
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.
As for JavaScript, Google Closure Compiler does some dead code elimination (DCE, a.k.a. tree shaking in Lisp lingo) as an optimization but it unfortunately doesn't tell you which parts of the code is dead. It also does not to DCE alone but does some aggressive size optimizations with it so, again unfortunately, it cannot output otherwise-identical code with only DCE applied.
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.
Well, while I like what you can build with JS, I often don't like what people build. For example, npm makes it so easy to import megabytes as a dependency to your project while you might only need a few kilobytes. And some devs simply do not seem to care about that.
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 ;-)
I actually liked the old point and click adventures better, because you always knew exactly what to expect. There was a fixed suite of tools provided by the browser and that was that. Now... well... every dumbass designer with a bright idea is free to inflict some bit of novelty on you. Fads sweep through the design community and suddenly old sites which worked fine have to be "updated" to work differently, and you have to learn them all over again, for no benefit.
Re [0], note that Google Maps on the other hand seems to handle lack of JS very well. I guess it can be blamed on different teams in the same big company.
If by "seems to handle lack of JS very well" you mean "does not work at all", that makes sense. Not being sarcastic either, it seems they decided to take an all or nothing approach and force the user to enable JS to use Google Maps, or instead see this page: https://i.imgur.com/Qc156Ds.png
Maybe the maps product wholly depends on JS for all functionality?
Yeah, my point is that they put actual effort to show you a nice-looking page when viewing Maps without JS enabled. Compare to the Chrome download page, which blanks out. This is orthogonal to whether or not a service can/should work without JS enabled.
NoScript definitely works without XUL support and is the fourth most popular extension listed on the compatibility page here: https://www.arewee10syet.com/
e10s is multi-process, I thought, which is a different animal to the new plug-in framework they are pushing. I'm pretty sure I read no-script will have problems, but that might have been with regards to tree style tabs instead (which is shown to work in the multi process branch)
There are more places to have a browser than on desktop computers, also not everyone wants to waste battery with JavaScript junk, the <blink/> tag of the 21st century.
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.
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?
For the same reason we build features in websites that work for blind people (aria tags everywhere), disabled people (accessible buttons), people who speak different languages (i18n), VIM users (GMail keyboard shortcuts), etc. We choose who we build for. If you want to ignore 0.5% of your users then that's your choice, but don't complain when you submit something to HN and get a page of responses saying it doesn't work.
It's 2017 and we should be over this "but it works on my machine!" attitude. It's completely reasonable to expect text and images to render without the need for the extra fluff.
I turned off JavaScript and Cookies for all sites a few months ago and only whitelist (or open in another Chrome profile) when they refuse to display or need an authenticated session.
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.
I use uMatrix as a substitute for NoScript + uBlock, and while it's a pain to get some sites working manually without bulk-enabling everything on them, I'm mostly happy about it, and the web looks better for me.
I use Noscript and uBlock Matrix together. It's a little annoying to have to double-whitelist pages, but they offer some non-overlapping functionality. uBM has finer whitelisting control, while NS has finer control (and better visibility) over specific kinds of objects on the page.
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.
I tried using uBlock (EDIT: uMatrix) for a while, but I felt like it was a lot of hassle, and most of the time it still wasn't granular enough to actually block the things I wanted to without breaking sites. It seemed like usually all of the bullshit javascript making sites sluggish came from the same domain as the few bits I might actually want. (Or at least needed to make the site useful.)
> wasn't granular enough to actually block the things I wanted to without breaking sites
I don't understand the criticism: it's no less granular than NoScript. If considering only the dynamic filtering panel[1], it can be argued it's more granular given that one can block inline-script tags only, and also one can block/allow on a per-site basis.
Static and dynamic URL filtering of course allows you to filter on a per-URL basis.
People should realise that most sites today aren't websites, they're web applications. HTML is just the template/output language.
Without JS you would have to download an even crappier, probably Windows only desktop app since it wouldn't be possible to implement the logic.
No, most websites are still websites, and one of the biggest problem on the web is the plague of people who think their website should be an application instead.
Actual web applications, like e.g. office suites, map applications, ect. are obviously extempt from "should work fine without JS" rule.
Are you really trying to say there's no argument to be made that SPA + prerendering is a design pattern with advantages over flat html, even for static content?
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.
I think he may well be saying that, and it's actually true. Want to make an SPA for static content? That's fine, but don't kid yourself that it's not worse in every single way. It's not a design pattern either, it's an anti-pattern.
In theory, maybe there is an argument. In practice, most of the time it'll be a pretty bad one.
For me it's about how user-hostile those decisions are. I can understand SPA-s when e.g. the service would be infeasible if all the processing was done server-side. But more often than not, it's just laziness. The devs can deploy a sleek-looking SPA in 5 minutes with their JS toolchain, forever dooming users to download tons of pointless JS that adds nothing valuable to their experience. But who cares, today's zeitgeist is "privatize the profits, socialize the costs".
Think of all those sites with articles and blog posts that blank out if you have JS disabled. There's no reasonable argument to be made that they should be SPA. That's just a case of user-hostile laziness.
> The devs can deploy a sleek-looking SPA in 5 minutes with their JS toolchain
Oh, if that'd be true...
Our experiments with React took quite a lot of time (like, weeks) before we got things in shape. And then some more time before that shape wasn't a pear.
And if the backend is not in JS, server-side rendering is quite a mess.
If the main work your site is doing is showing pictures and text - and this is still and always will be a large part of the web - the browser has a number of features that work very smoothly and reliably out of the box: scrolling, page history, following a link when it is clicked, right-click save as, searchability, basic accessibility, etc. - and typically much quicker rendering than something which waits for a lot of extra HTTP requests and extra work being done in a VM somewhere.
Reimplementing these features in JS is often pretty feasible, and occasionally there are use cases for it, but it's a lot of additional overhead and it's not at all unusual to introduce bugs that really hurt the UX. (UX is not just adding as much branding as possible on top of vanilla browser behavior.)
The average newspaper website should not load 15 megs of junk from 20 different domains with a massive amount of Angular code just so I can read a single paragraph of plain text. This is an example of a document, it's what the web was made for and browsers already do it well without turning most documents into an SPA.
> as fewer people turn off JS and browsers become better at running web apps
In my anecdotal experience, I am running across more people that are turning off JavaScript, partly because browsers are becoming more bloated and worse at running web apps.
One thing to consider is that at larger companies, we already have a difficult enough time testing all of our site with JavaScript enabled. Netflix building a version that works without JavaScript is like asking them to build a second website, especially from a QA perspective. When you look at your users and find that .5% of them are not running JavaScript, how do you justify spending the money for that few of people?
Try doing some automated testing, it'll take care of most of the non-JS testing and a lot of the JS enabled testing as well. Explority testing is another thing, that QA really does need to be involved with, but if you can't test static content without human intervention, you have other problems that are nothing to do with whether you have JS turned on or off.
The reason is mobile. While only .5% of your users may be non Javascript users it's highly likely a significant percentage of your users are on mobile and not optimizing for progressive enhancement means a significantly degraded experience for all of them at various times when it fails to load or loads too slowly on a mobile connection.
I can stand slow loads, my phone has wifi after all. But js bloatware doesn't even allow me to scroll without seconds lags and random misclicks due to delayed event dispatch. Me turned js off not because of security concerns, but because most js-only sites are not scrollable beyond the first screen anyway.
To help our (internal) customers better troubleshoot, we're adding HTML responses to our HTTP (web) services. Add a header, a footer, maybe some HATEOS... Starts looking like a barebones web site.
How do you know the percentage. Some stuff you may just never know. I very consciously avoid websites I know use a lot of JS or are bloated on mobile. Mostly news websites.
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.
They can't justify the cost. I wouldn't want them to, anyway. It would mean fewer improvements for their non-crippled site as resources are diverted for the sliver of people who like to be contrarian.
The NoScript extension is the 5th most downloaded extension for Firefox (https://addons.mozilla.org/en-US/firefox/extensions/?sort=us...). If you want to show a blank screen or a broken website to those users, that's up to you. Some of them may really want to see your site, so they might try to figure out which of the twenty domains they should enable, and which of the thirty they should enable after that one doesn't help them. Most will likely click on the back icon and see what's next on the list.
Yes, and Firefox is the 3rd of 4th most used browser at less than 10% (which is bad). So the subset of actual Firefox users that use NoScript is absolutely not worth supporting.
Netflix is one of those sites that makes we want to run noscript. I regularly makes firefox unresponsive and eventually popup a "this script is using too many resources". When a large tech company can't create working javscript for a minimally interactive interface then something is seriously wrong.
Less javascript would be an improvement for everyone, not just the noscript users.
Having browsed nearly JS-free for the last two-ish years, aside from a bit of tweaking at the start, I have to say that it has made things a lot faster, more stable, and just much more of a pleasure to navigate. If anyone is interested, I have found that two tools make life a lot easier:
- 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.
Presumably this occurs when the site uses a CDN for their js libraries (or even their main js). After a few days you start to spot which domains need to be enabled and which can be safely ignored.
Best i recall, even if you whitelist a CDN it only comes into action if you whitelist the root domain of the site you are visiting.
Beyond that i guess there is GRE, where you can build "firewall" rules.
For example i have Facebook blocked via it unless i visit Facebook.com directly, thus they don't see me browsing all manner of sites via their like buttons and comment boxes.
My main issue with having no script on is for website checkouts. Especially when buying flight tickets. A lot of sites will introduce new scripts in the middle of a stepper that you didn't need to complete step 1. Now you can't submit step 2 or 3 and when you allow the new scripts the page reloads and you lose all your form data.
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?
Firefox has Noscript, and perhaps another tool i forget the name of (never tested it). Not sure if there is anything similar for Chrome (and the various offshots/rebrands) or Edge, never mind IE or Safari.
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.
It's probably WebGL-related. Some Firefox update seems to have fixed it for me recently but for quite a while I could only visit Google Maps in a brand new Firefox instance, because any attempt to use it in a well-aged process would crash firefox and emit graphics errors to dmesg. You may have a poorly-supported WebGL stack.
Agreed, I just dusted off an old laptop with 14.04 ubuntu (or maybe it was 14.05) and tried to run a webgl app I'm making off of local host and the whole computer nearly locked up (after updating firefox too). Chrome ran it at 60fps easy with whatever version was installed on the computer three years ago.
Now that I've updated to 16.04 firefox runs better than it did but chrome still blows it away.
There should be something as a fallback, though, surely? Take out all the functionality, by all means, but at least give me a map image. If you can't even get link-to-zoom working to display different images, just give me a map image based on my IP location; give me anything rather than nothing.
Can you do lazy loading with just HTML and CSS? You can load the map around the GPS coordinates you start on, but what if you go 20 miles north? How do you: A) figure out what are the new GPS coordinates that your viewport is looking at? And B) load the map within the viewport centered around the new GPS coordinates that you're looking at without ajax?
Remember the HTML map tag? [1]. There is a huge amount they could do to make maps usable without JS (or even CSS). Zooming and panning would be pretty easy to implement, but would involve reloading the page with new coords.
While I agree with you, I still want to give them points for admitting their failure. It's a cute image, with a cute line that tells you exactly what the problem is.
Compare that to sites where you just get a blank page.
If I recall correctly there was an old version of Google Maps which worked without JS.
It was before they replaced the old snappy and functional Google Maps with the bloated and slow app we have now.
I honestly think the security/privacy arguments are the only valid argument against requiring JS as standard.
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.
So far as I know there has been exactly one such ad blocker released, and it was promptly abandoned in favor of the kind of adblockers people actually want to use.
WTF? You do realize most of the users on the internet don't even know what CSS/JS is and would be thoroughly displeased at being presented with a page with no styling. They don't appreciate that the rendering is done without JS/CSS. A properly built website is one that caters to most users, not developers or power users concerned about JS being enabled in 2017.
You know - at one time we built plenty of websites - and in some cases applications - using little to no javascript (either it didn't exist, or it was only used for very minimal things) or any CSS (it didn't exist).
So what could we do today? That is - if we purposefully limited ourselves to just basic HTML, and server-side processing, without any (or minimal) CSS or javascript, and only using the (expanded) tag and attribute HTML we have today?
I don't know for sure - but I believe we could create some amazing things.
Think about it this way: Look at what demoscene people are able to create when they put extremely artificial challenges in front of themselves; we could try to do the same - and see what happens?
Perhaps there needs to be a demoscene-like competition space for this kind of stuff (how much can you get done in under 100k browser-side? 10k? 1k? Limit bandwidth to the backend, too, and maybe server-side size of code?).
Just some random thoughts - it might be something I'd have to try myself, but maybe this post might inspire someone to do it as well...
What kind of things are you imagining people would get done with such a limitation?
Recently I was using an expensive mobile connection and I discovered w3m, a text based browser (runs in the terminal). I was amazed at how much faster everything worked.
Most of the sites were still perfectly usable (w3m has pretty good HTML rendering) but some were very difficult to navigate.
My point is, without JS and CSS, the web is just... text.
And when you browse with w3m you realize, that actually the web has always been text. It can be quite refreshing to get all the decorative crap out of the way.
--
edit: I now see you didn't say to remove JS, but to challenge yourself to see how much you can make in a tiny amount of JS. Such competitions exist!
That would be a valid reason to provide a JS alternative depending on context, not so much a valid argument for JS-free alternatives as standard.
There will always be something you can do to reduce power consumption: expecting (or advocating) JS-free versions of all websites for that reason is a completely arbitrary line to draw.
Sure, but the he only has to wait for the cycle to swing around again. Browsers will officially turn into JS/WASM runtimes. Sites will balloon until instant delivery is no longer feasible. Browsers will respond by allowing sites to version themselves to aggressively cache client code. Eventually browsers will start offering site-specific-browser features to 'new-modern' sites to combat the extreme waste of Electron and the like.
Someone with political capital and influence in the developer world will realize that the web is still mostly text and design a browser optimized for that use case. It will be hailed as a revolution and people will start preferring it over the 'old-web' for accessing static content like news.
Then under pressure from developers pushing the limits of static content they will include a simple, limited scripting language that promises to facilitate basic interactive elements and start the cycle anew.
We should call it something trendy, maybe 'The River'?
All google products. But it is ridiculous to disregard JavaScript because some people can't write it properly. It is the same as saying that I wouldn't use a browser because I once went to a website that displayed a popup.
It is not ridiculous, machine crippling JS malware is a click a way and you will never know until you click. The safe strategy is JS off by default plus whitelisting.
> wouldn't use a browser because I once went to a website that displayed a popup
I have been using the internet nearly daily for about 20 years now. I can't recall a single time I clicked on something that gave me "machine crippling JS malware".
Barring some serious security gaps, JS isn't even capable of doing anything more than lock up the browser and maybe send some extremely minimal information about you back to someone elses server.
> Barring some serious security gaps, JS isn't even capable of doing anything more than lock up the browser and maybe send some extremely minimal information about you back to someone elses server.
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.)
I'd be very interested to see some proper analysis of the difference in speed between HTML/CSS vs just JS, it seems obvious to me that the former would be much faster but then again I know how often "obvious" things are wrong.
As a very general answer, JS webapps will typically be slower on the first load because they require an extra step to show the content.
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.
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.
100% of users want websites to load faster though - that's a fairly big market share.
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.
Ironically, this articles confirms that investing into the no-JS functionality is becoming less and less important, with those major sites already forcing the user into JS. Why then would you invest your time and money to cater to the "eccentric" 1%?
You’re not wrong about screen readers, no. I wrote a blog post about this last year[1] but I’ll copy and paste a list of possible reasons from it here:
- script hasn’t finished loading, or has stalled and failed to load completely
- application route is up, but the route to the Content Delivery Network is broken
- user has chosen to install a plugin that interferes with the DOM
- user has been infected with a plugin that interferes with the DOM
- user’s company has a proxy that blocks some or all JavaScript
- user’s hotel is intercepting the connection and injecting broken JavaScript
- user’s telecoms provider is intercepting the connection and injecting broken JavaScript
- user’s country is intercepting the connection and injecting broken JavaScript
- JavaScript code has functions not implemented by your user’s browser (older browsers, proxy browsers)
There might be 1 or 2 billion "eccentric" people that rely on old/cheap devices and networks, plus the visually impaired that need to use braille interfaces with little support for dynamic contents.
Looking forward to the author's follow up: "A day without a CPU". I am sick of lazy, profligate coders assuming that my computer is a von Neumann machine. And that just because I run their software, I am happy with it spending billions of my CPU cycles. How did we, as an industry, get to this point!?
HTML isn't just simple to the programmer, it's also simple in other ways which gives it unrivalled accessibility (to disabled folks, different browsers and devices, web crawlers). Not sure any SPA framework can compete.
Have you tried relying on SPA crawling in practice? As far as I know it's still messed up and hasn't changed in half a decade, but maybe I'm missing something.
Disclaimer: I am, and have been for the last 5 years, a JavaScript developer
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]
Third-party scripts aren't just a performance problem---consider privacy/trackers as well. I gave a talk at LibrePlanet 2017, where one of the things I showed is the drastic effect disabling JavaScript has on third-party scripts, graphed by Lightbeam:
I just did the same experiment and, coincidentally, also checked feedly, only to receive a totally blank page. However, a little digging revealed an intent on feedly's part to handle this case. They have a 'feedlyBlocked' element, with content, that is simply fixed to "opacity: 0"; obviously, without javascript enabled, they can't then dynamically display that content. Another approach required.
As an aside, it's very difficult to contact feedly directly, but they do have a uservoice account (https://feedly.uservoice.com).
What is the motivation behind this mentality? Sure there are still webpages on the web, but there are also web apps. Why or even how would you expect a web app to work without JS? Why would you expect developers to spend time writing a non JS version of their app? Before taking on this endeavor, I would prioritize native apps, optimizations of all sorts, adding features, etc. Unless your app is gmail, why would you ever spend time on creating an HTML/CGI based web app? I keep seeing these posts and I just don't get why anyone cares about this.
- Twitter, is quite literally, a text based feed. There's no reason for this not to work without JS
- Netflix would depend on what you're doing. Much of it can work just fine as text, images and forms
- Youtube has a lot of text and the videos could be played without JS if they wanted to bother (HTML5 ftw!)
- Maps can also work OK without JS (just without the additional stuff, which is fine for progressive enhancement). Google "google maps without JS" for examples of what other people have done. I'm pretty sure you could also get around JS with pure HTML5 + CSS3, but I have no examples of it
So easy to write this in a comment but none of this is true. Twitter is not a text based feed. If it was, people would still expect it to be iteractive w/o full page reloads. Same goes for all your examples. DHTML happened, and for a reason. It's not going to unhappen.
Wow...just...wow! Look, I don't want to be mean, I understand you believe what you're saying, but, really, just no. You really do not understand how the things you're talking about work. For your own sake, go learn some more before jumping into comment here.
Please don't post unsubstantive personal attacks (which this is) to HN. If you know more than someone else, teach them; then we all learn. If you don't want to do that or don't have time, that's fine, but then please just don't post anything.
Commenting just to condescend about how ignorant someone is, instead of helping them, is lame.
Maps would be severely limited without JavaScript. However, Twitter, YouTube, and Netflix could just as easily be implemented using standard HTML <form> and <video> tags without much loss of functionality.
The content is the main thing users care about and it should be available as soon as possible even on a low-bandwidth connection, or a low-end device, or using a screen reader. This is what Progressive Enhancement https://en.wikipedia.org/wiki/Progressive_enhancement is about.
Progressive enchancement is a rubbish paradigm because it's incredibly difficult to implement. React isometric rendering has made it slightly easier but it's still one of these catchphrases people throw around lightly until they try it.
I negotiate the javascript issue by using two web browsers -- w3m for reading hypertext and Firefox when I want javascript. I'm fine with my bank or an online store expecting to use my browser as a thin client, but if you require javascript to present your blog, I'm going to find a different blog to read.
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.
http://mbasic.facebook.com
if you ever do miss social media this gets you a javascript-free, minimalist version of facebook. I use it all the time on mobile and get hours more battery compared to their app or standard mobile site.
411 comments
[ 3.1 ms ] story [ 298 ms ] threadI do miss the days when people considered JavaScript an enhancement and not a dependency.
[^1]: https://en.wikipedia.org/wiki/Progressive_enhancement
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.
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.
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 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 )
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.
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)."
https://sonniesedge.co.uk/about/
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?
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.
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.
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.
Now bundling it with the rest of your JS, that's indeed a mistake.
Ah, so this is how front-end got the way it is.
Event the damn native APP for hackernews, using only JSON, is not usable in 2G.
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.
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.
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.
... and daily standups? so busy working that there is no time to do the job
[0] https://github.com/giakki/uncss
[1] http://blog.mgechev.com/2016/06/26/tree-shaking-angular2-pro...
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.
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?
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.
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
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 ;-)
[0] https://www.google.com/chrome/
Maybe the maps product wholly depends on JS for all functionality?
Tested and working, for a while now.
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.
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?
What percentage of users do you think block JavaScript? I'd be utterly shocked if it were more than one or two percent.
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.
I don't understand the criticism: it's no less granular than NoScript. If considering only the dynamic filtering panel[1], it can be argued it's more granular given that one can block inline-script tags only, and also one can block/allow on a per-site basis.
Static and dynamic URL filtering of course allows you to filter on a per-URL basis.
[1] https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...
Sorry, to clarify, I wasn't comparing uMatrix to NoScript, merely commenting that it didn't seem particularly useful to me when I tried it.
I was considering trying NoScript at some point, but from what you've said, it doesn't sound like it would be much better for my purposes?
> Verdict: Failing… to not work. Sad!
Delicious.
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.
For me it's about how user-hostile those decisions are. I can understand SPA-s when e.g. the service would be infeasible if all the processing was done server-side. But more often than not, it's just laziness. The devs can deploy a sleek-looking SPA in 5 minutes with their JS toolchain, forever dooming users to download tons of pointless JS that adds nothing valuable to their experience. But who cares, today's zeitgeist is "privatize the profits, socialize the costs".
Think of all those sites with articles and blog posts that blank out if you have JS disabled. There's no reasonable argument to be made that they should be SPA. That's just a case of user-hostile laziness.
Oh, if that'd be true...
Our experiments with React took quite a lot of time (like, weeks) before we got things in shape. And then some more time before that shape wasn't a pear.
And if the backend is not in JS, server-side rendering is quite a mess.
Reimplementing these features in JS is often pretty feasible, and occasionally there are use cases for it, but it's a lot of additional overhead and it's not at all unusual to introduce bugs that really hurt the UX. (UX is not just adding as much branding as possible on top of vanilla browser behavior.)
The average newspaper website should not load 15 megs of junk from 20 different domains with a massive amount of Angular code just so I can read a single paragraph of plain text. This is an example of a document, it's what the web was made for and browsers already do it well without turning most documents into an SPA.
In my anecdotal experience, I am running across more people that are turning off JavaScript, partly because browsers are becoming more bloated and worse at running web apps.
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.
so, win-win?
Less javascript would be an improvement for everyone, not just the noscript users.
- 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.
Beyond that i guess there is GRE, where you can build "firewall" rules.
For example i have Facebook blocked via it unless i visit Facebook.com directly, thus they don't see me browsing all manner of sites via their like buttons and comment boxes.
0: https://github.com/gorhill/uMatrix
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?
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
Compare that to sites where you just get a blank page.
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.
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.
Same thing that is happening with ads and ad blockers.
https://www.eff.org/privacybadger
All ads are intrusive to some degree.
So what could we do today? That is - if we purposefully limited ourselves to just basic HTML, and server-side processing, without any (or minimal) CSS or javascript, and only using the (expanded) tag and attribute HTML we have today?
I don't know for sure - but I believe we could create some amazing things.
Think about it this way: Look at what demoscene people are able to create when they put extremely artificial challenges in front of themselves; we could try to do the same - and see what happens?
Perhaps there needs to be a demoscene-like competition space for this kind of stuff (how much can you get done in under 100k browser-side? 10k? 1k? Limit bandwidth to the backend, too, and maybe server-side size of code?).
Just some random thoughts - it might be something I'd have to try myself, but maybe this post might inspire someone to do it as well...
Recently I was using an expensive mobile connection and I discovered w3m, a text based browser (runs in the terminal). I was amazed at how much faster everything worked.
Most of the sites were still perfectly usable (w3m has pretty good HTML rendering) but some were very difficult to navigate.
My point is, without JS and CSS, the web is just... text.
And when you browse with w3m you realize, that actually the web has always been text. It can be quite refreshing to get all the decorative crap out of the way.
--
edit: I now see you didn't say to remove JS, but to challenge yourself to see how much you can make in a tiny amount of JS. Such competitions exist!
web pages https://a-k-apart.com/
java games http://www.java4k.com/
There will always be something you can do to reduce power consumption: expecting (or advocating) JS-free versions of all websites for that reason is a completely arbitrary line to draw.
It is not a question about JavaScript or not. It is a question about well developed site.
You will also be in the minority later
Someone with political capital and influence in the developer world will realize that the web is still mostly text and design a browser optimized for that use case. It will be hailed as a revolution and people will start preferring it over the 'old-web' for accessing static content like news.
Then under pressure from developers pushing the limits of static content they will include a simple, limited scripting language that promises to facilitate basic interactive elements and start the cycle anew.
We should call it something trendy, maybe 'The River'?
Sure, dude, ignore anyone without a machine that can run MBs of JS within a reasonable time.
> wouldn't use a browser because I once went to a website that displayed a popup
you would use a popup blocker though.
I have been using the internet nearly daily for about 20 years now. I can't recall a single time I clicked on something that gave me "machine crippling JS malware".
Barring some serious security gaps, JS isn't even capable of doing anything more than lock up the browser and maybe send some extremely minimal information about you back to someone elses server.
Not true. First JavaScript Rowhammer exploit was publicized in 2015: https://www.youtube.com/watch?v=9L5MJ43nbkI
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.)
https://vimeo.com/58808364
<style>.vote-42:active{ background-image: url(/api/vote/42) } </style> <a class="vote-42">Vote</a>
https://codepen.io/anon/pen/weMwRz
Realistically, I'd probably never use it because it's so dependent on browser behavior, but still a cool alternative.
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.
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.
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.
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?
- script hasn’t finished loading, or has stalled and failed to load completely
- application route is up, but the route to the Content Delivery Network is broken
- user has chosen to install a plugin that interferes with the DOM
- user has been infected with a plugin that interferes with the DOM
- user’s company has a proxy that blocks some or all JavaScript
- user’s hotel is intercepting the connection and injecting broken JavaScript
- user’s telecoms provider is intercepting the connection and injecting broken JavaScript
- user’s country is intercepting the connection and injecting broken JavaScript
- JavaScript code has functions not implemented by your user’s browser (older browsers, proxy browsers)
[1] https://gdstechnology.blog.gov.uk/2016/09/19/why-we-use-prog...
Because she left it up to the end user, how about "A day without JavaScript is like a day without a brain bleed"?
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.
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]
[0] http://idlewords.com/talks/website_obesity.htm
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.
As an aside, it's very difficult to contact feedly directly, but they do have a uservoice account (https://feedly.uservoice.com).
- Netflix would depend on what you're doing. Much of it can work just fine as text, images and forms
- Youtube has a lot of text and the videos could be played without JS if they wanted to bother (HTML5 ftw!)
- Maps can also work OK without JS (just without the additional stuff, which is fine for progressive enhancement). Google "google maps without JS" for examples of what other people have done. I'm pretty sure you could also get around JS with pure HTML5 + CSS3, but I have no examples of it
Commenting just to condescend about how ignorant someone is, instead of helping them, is lame.
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.