Do this only if you don't care about the people that use (sometimes: have to use) your software. Otherwise,
>> Choose the least powerful language suitable for a given purpose.
(Don't make me needlessly enable JavaScript to use your site.)
>> Choose the least powerful language suitable for a given purpose.
(Don't make me needlessly enable JavaScript to use your site.)
Rubbish. Web technologies are way too sophisticated to boil down to some silly rule of thumb that “the least powerful technologies are the” best in some way.
As a professional developer, use every technology at your disposal and use it in whatever way you like, including the most advanced techniques.
Ridiculous to be given the most one of the most powerful development tools ever made - the web browser - and artificially constrain how you use it for some dogma.
And if you’re a junior developer, ignore people who tell you how you should program - do it how you like unless the boss says different.
A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.
Are users happy? Is dev speed of improvement good enough? Can you onboard new devs easily enough?
That’s it. Nobody cares if you used CSS or JS for a toggle switch.
The only people who disable JavaScript in their browsers and expect the 2023 internet to accommodate them are right here in this thread.
Just componentize it and move on to solving the next business problem, not the next code elegance problem.
My 2 cents: native solutions like HTML and CSS are preferable: they are designed to degrade well, they work with screen readers, with increased font size, high contrast, and other less-known or unknown and even future use-cases and needs. No dev team has the time to test their custom JS solution on all possible browser targets, and in reality they frequently fail even basic accessibility needs for no good reason.
At least to me, honoring the principles of the web is our responsibility, especially in our current time when they are arguably under attack from well-funded players. I would hate to see the web degrade into a delivery mechanism for opaque executables that work only on corporate blessed mega-browsers.
Where does this idea come from? I’m seeing it all over these comments, and I strongly suspect this sentiment is coming from people that haven’t actually looked at WCAG or been tasked with creating a compliant accessible website. You can botch the contrast, hard code font sizes in pixels, and leave out pertinent navigation details for screen readers with plain HTML and CSS. Here’s WCAG if you don’t believe me (emphasis mine):
> Myth No. 9: Pages With JavaScript Cannot Meet WCAG 2.0: FALSE WCAG 2.0 was designed to allow many new modern technologies to be used and still provide accessibility. Pages with JavaScript can be made to conform to WCAG 2.0. It is also possible to write pages with JavaScript using the JavaScript in a way that would make the pages not conform. It is also possible to create a page using only HTML which do not conform.[0]
There is nothing about using JS that makes a site less accessible, and there is nothing built in to HTML to make a site automatically accessible. The only way you’ll have an accessible site is by testing it manually and bringing in users to find edge cases.
Other than the people who have to wait several minutes for your 20MB JavaScript framework to load on their slow metered connection just so you can make an expandable section using a bunch of <div>s rather than the native <details> element. But those people don’t matter because they should just move to a country with unlimited fast internet, am I right?
Nobody is suggesting using a 20mb framework to make a toggle switch work on a standalone page that isn’t a web app.
If you’re building a web app either way, then choosing between a screen full of CSS or a handful of lines of js is negligible.
For expanding sections, you should use native HTML elements when they do the job with less effort/code. You should use JS when they don’t.
What a strange statement. 'Vanilla' JS has been supported 'natively' in browsers since the late 90s.
The walkthrough in the article seems to demonstrate pretty effectively that the powerful development tools offered by a modern browser may obviate the need for elaborate frameworks in many cases.
Where this is the case, then, relying a framework instead of the tools the browser already provides artificially constrains an application, potentially for dogmatic reasons, and regardless of a developer’s level of advancement.
Browsers have rapidly come a long way even just in recent years. Frameworks well and truly have a place, but narrowly relying on frameworks, particularly out of beliefs about browser capability established years ago (like when React was introduced), can neglect browser-native functionality that can provide same-or-better results, with potentially better outcomes in performance, accessibility, maintainability, and more.
This qualifier probably applies to >90% of this website’s audience, so I don’t think it’s useful.
Using less power if you can get away with it is absolutely sensible. If my implementation is suitably robust without the use of type families, data kinds, singletons, lenses, etc., then that’s a more economic solution.
What actually makes a site screen reader friendly? Developers that actually write accessibility tests, tab through their site manually, open it with a blindfold and a screen reader to make sure they can navigate it, etc. This myth that no JS automagically enables accessibility needs to die.
Only a very small but vocal minority of users disable JavaScript, as it's not a default setting in any of the web browsers with a market share higher than the rounding error.
In a lot of cases, designing a no-JS website disadvantages both the service provider and the users:
- the service provider has to support a higher load to render the page and process the data on the server,
- the user has to endure longer processing times for their data, since their request necessitates a round trip from/to the server adding additional latency.
For example, let's think of an image processing web app. All of this can be done on the client side (and this gives the user a higher sense of privacy since their data doesn't need to reach the server). It's much faster there, reduces the server load - allowing the service to be used by more people at once.
And there is no value in appeasing the no-JS minority, since either maintaining a no-JS version of the app in parallel, or building the entire app without JS, outweighs the potential ROI from the <1% of users[1].
If you disable JavaScript because of tracking and ads:
- browser extensions exist to only prevent tracking JS from running without affecting the websites,
- you can still be tracked server-side.
[1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi... - 0.2% of users of the UK online government services had JavaScript disabled. Based on the research I can find online, most of the no-JS users are using TOR, which isn't a terribly profitable demographic for commercial websites.
I keep JavaScript always on and if I see a website abusing my trust, I just blacklist the entire website from my browser and never visit it again.
As a developer, all of my publicly available personal projects feature no tracking, no advertisements, and no third-party JavaScript in general. JavaScript is a really good tool, but as any tool can be, JS can be misused.