@Ashrand That's not the fault of the language itself. That's an implementation issue. And there are some very nefarious practices that have become the standard over the years unfortunately.

I understand people's concerns when it comes to js, but the solution has to be more nuanced than burn the house down.

@Are0h Sure, that makes sense, but it's also not fair to get people to vet every website they visit offhand for being a 'good' or a 'bad' implementation either. It's not JS fault bad practices become common. Just like no-one just *decided* all advertising was bad, things got bad enough to need fixing and that fix didn't distinguish who was doing things right or not, a few bad apples spoiled the barrel. I like JS but i like a lot of websites without it a lot more.

@Ashrand Why is that unfair? Expecting to people to take some responsibility for the sites that they visit isn't reasonable? Hard disagree on that point.

And we'll disagree about that as well. Yeah, there are some sites that are fine without out, but hamstringing the web based on those outliers isn't a very smart decision.

@Are0h It's unfair because websites aren't entitled to peoples time, whether they don't visit or don't discriminate on JS people engage at the level they want and if there is a mismatch there it's not the users fault.
If the web is hamstrung then people with slow internet, on mobile, a million qualifiers limit what makes a website work for some, good website design builds for people where they are, if the website doesn't work, that isn't the users fault.

@Are0h I want to make it clear though that you are right!
JS is cool, used well it's Very cool, I wish it didn't make it harder for people to use the web way too often when it really shouldn't... but there we are.

@Ashrand JS doesn't make the web harder for people to use. It's just a tool.

How places implement js is the problem. That's where we need to improve. There needs to be more thought on how a user can know how js is being used a particular location and that information needs to be clear and easy to access.

If we don't solve the root of the problem, terrible code practices, we're going to have the same issue not matter what front end scripting language we use

@Are0h I can agree on that too, in the mean time it's not up to people to bear with it until it's fixed.
And it does make it harder for a lot of things... unless you have internet faster than the worldwide average connection. Which is why projects like AMP exist when they don't need to.
Likewise making JS that you can use with a screenreader isn't an optional extra, you are shutting people out if you don't but it's also not feasible for a lot of JS to work with a screenreader.

@Ashrand I would disagree. We can't find better solutions if we don't work together and talk about it. Choosing not to engage it because one doesn't want to isn't going to solve anything.

That's simply not true. It's not that hard to make JS play nice with a screen reader. You're again talking about an implementation problem, not an issue with the language itself.

@Ashrand No one is forcing people to use any website, so that point is irrelevant. If one doesn't like the particular experience of a location, they can choose not to use it.

Yes, you're right about that. So let's improve those practices rather than just fire bombing a fundamental part of the web that will cripple millions places with no viable solution.

@Are0h @Ashrand I don't think it's funadmental. Javascript lets us do a lot of things that would otherwise not be feasible because of a variety of reasons, but it certainly doesn't add anything fundamental to what the Internet is.

Also, if 90% of a language's implementation is bad, I do believe the language bears some fault there.

Frankly, it sounds like you're arguing for keeping the bathwater to not throw out the baby. Some of what Javascript allows is cool, but not unique

@emsenn @Ashrand We're going to agree to disagree on that point. The web needs a front end scripting language.

90% is a purely subjective number. You could say the same about any popular language on the web, so that point is moot.

And it sounds like you're arguing anecdotes to get rid of a piece of the web that has allowed to evolve to where it is now. I'm open to better solutions, but getting rid of fundamental tool is not something I'll ever agree with.

@Are0h @Ashrand Which seems an odd sticking point. Why are you insistent we not get rid of a "fundamental language", instead of focused on making sure we can maintain those fundamental abilities, regardless of language?

That, I think, is my main point: you're attributing to Javascript what I think is better attributed to human cleverness, and misattributing that cleverness as dependent on Javascript i think hampers seeing other potential - better - solutions.

@emsenn @Ashrand That _is_ my point. We do that with now with JS. If we have something that can do what JS does, but better I'm on board. But getting rid of a fundamental tool is not smart.

The insinuation you are making is false, as at no point did I express that JS is attached to cleverness. I have no idea where you got that from.

If there is a better solution, I'm all for it. But let's figure that out before we throw out a basic building block of the entire web.

@Are0h (1/n) You seem to still not be getting what I'm saying. Javascript is not a fundamental tool. The things which it enables have, arguably, become fundamental to our Internet, but the language itself is not a fundamental tool. You're upset that people want to get rid of Javascript because it takes away a tool for doing something fundamental - but it does not take away the ability to do the fundamental things.

@Are0h (2/n) It seems like you have a strawman, where you say "people want to get rid of javascript, they must also want to get rid of the things that javascript enables," when at least in my social circles, that isn't the case - they want to keep much of what javascript's allowed - keep those fundamentals. But they don't want to continue to accomplish them with javascript.

@emsenn Nope. That is what you're saying, for whatever reason. At no point have I implied that idea.

For the second time, that's fine. If there is a better idea than JS, cool. I'm all for it.

What I am saying is let's not get rid of js until we figure out how to do that without it or enable people to disable the parts of js that hinder their experience.

And your 'social circle' should not define how people use js. We should be empowering people, not limiting their options

@Are0h

> for whatever reason

If someone is repeatedly misunderstanding your point to the degree they feel the need to repeatedly chime in about it, even while apologizing for chiming in, it may be more appropriate to re-consider how your messages could be inferred, rather than focusing on what you meant to imply or emphasizing their inability to understand you.

@emsenn That is an irrelevant action when one's message has been stated repeatedly, but is being ignored by the party that is continuously misinterpreting said message.

Misunderstandings happen and that's cool. But I can't help a person that ignores what I'm saying to push whatever they want to believe.

@Are0h Your language continues to make it clear you view me as responsible for the misunderstanding, and since I don't, I'm going to move on with my day and hope you do the same.

@emsenn As you have implied certain points that I did not say or imply, yes, I do hold you responsible. It happens. It's not an insurmountable point, but you've demonstrated an intent to interpret my words that serve your point, rather than engaging what I'm saying.

Ha, uhm... ok.

@emsenn For the second time, I do get what you're saying. I don't agree with it.

Ha and saying I'm 'upset' is a subjective insinuation on your part. Again, I don't know where you got that from.

And we're just not going to agree on that point. If it's not fundamental for how you use the web that's fine, but that language has enabled people globally to connect and interact in ways that aren't possible without it.

It just is what it is.

@Are0h I'm sorry to be so firm on this point, but you are not understanding what I'm saying. "The places a car allows you to travel", and "a car" are different things. "The things Javascript allows" and "Javascript" are different things. You are conflating the two, and that is the only point I am speaking to.

If you're saying those two _are_ the same thing, then yes, we do disagree, but as I read it, nothing you've said disagrees with me, just misunderstands me.

@emsenn There's no need to apologize for being firm. You just don't understand what I'm saying, for whatever reason.

Ha, no, I'm not. I have clearly said more than a few times my issue is with _implementation_ not the language itself. I have no idea why you're missing the point that I've stated multiple times.

There is a misunderstanding here, and it seems largely based on your assumptions of what I'm saying rather than what I'm actually saying.

@Shotagonist Absolutely agree. Evolution is part of the process when trying to build a better web. Throwing out such a commonly used tool out of frustration and anger with no real solutions is the opposite of that.

@Are0h I wonder if this attitude of (mostly white) tech guys to 'just throw out the risky stuff' reflects on their stance on immigration.

@Shotagonist I think it absolutely does. Getting rid of such a fundamental piece of the web would harm so many people who depend on the web for their livelihoods.

And you know how rarely those considerations enter tech discussions in those particular circles.

@Are0h I see Tech Folk constantly stick their noses into areas they have no expertise in. For example, a Cisco Engineer suggested (in a presentation at my vocational school) to create a Medical Wristband that checks your health and links that data to doctors, and they get to decide based on that when you could/have to call in sick.

He didnt see the millions of issues with this idea at all.

@Shotagonist This is true. Tech folk tend to be myopic when it comes to the ramifications of whatever cool stuff they think of.

And the fact tech spaces are usually havens for white men, that doesn't bode well for the process.

@tindall We'll agree to disagree about what should be the default for a user.

@Are0h yeah, absolutely. It's the kind of thing that's easily configurable anyway; I just wish the browser vendors weren't so all in on the dynamic aspect of the web. It tends to kill compatibility with many accessibility technologies, and archivability. Plus, as a frequent text mode user, it makes some websites a real disruption in my workflow.

@tindall I don't agree. The dynamic web was allowed for some great experiences on the web to be created.

And no I don't agree it kills compatibility with accessibility. That's not what JS inherently does. That's an issue with how people use it. That's where we need to improve.

And that's fine for you. I don't think the web should be adapted to your personal usage preferences.

@Are0h I wonder if we're perhaps coming at this from different angles. I definitely don't think that JavaScript should go away, but I feel like you're not hearing what I'm saying about accessibility (and I don't just mean in terms of screen readers, but also alternative input methods and low-powered hardware).

1/10? or so

@Are0h The first thing to address is "web apps" - that is, applications software written to run client-side in a web browser. I certainly agree that having an easy way to distribute cross-platform software is a boon. Not having to write the same app over and over for different platforms, being able to easily update and modify your app without worrying about users not downloading the updates, and reducing user barrier-to-entry are awesome.

2/10? or so

@Are0h Dynamic content on "regular" web pages is a seperate issue. I also agree that dynamic content on mostly static web pages can be a huge value add, and can enable some really cool content - the 538 and NTY data visualization tools come to mind.

On the other hand, JavaScript by default everywhere has had some seriously negative consequences.

3/10? or so

@Are0h Most obviously for those of us who use slow devices (e.g. my T430s), text-mode browsers, or screen readers, accessibility tools and non-JS rendering are broken by default on tons of sites, despite the fact that HTML5 has incredible a11y support.

I'm not talking about web apps here, but about what should be simple HTML documents - news stories, download pages for native software, and even manuals from many hardware manufacturers.

4/10? or so

@Are0h Rather than being written as simple static pages, or even static pages enhanced with dynamic content, they are often written as SPAs which are extremely fragile.

Pages that don't render their static text without JavaScript are broken for some users. Pages that require the use of a mouse to active a dropdown are broken for some users. Pages that dynamically load content without tagging it for re-parsing are broken for some users.

5/10? or so

@Are0h Pages that don't use standard HTML forms are broken for some users. Pages that break with the use of the "back" button are broken for... well, the majority of users. These are all things I run into _often_.

6/10? or so

@Are0h We have a technology which is really good at laying out documents - HTML. It supports and integrates well with a11y technology, is relatively easy to support in anything from Firefox Quantum to w3m/elinks to flip-phone browsers, and can even be read raw by humans, to some extent. We also have a technology which is good at styling documents - CSS. It also supports and itegrates well with a11y technology, and has basic dynamic features via MediaQueries.

7/10?

@Are0h Both of these technologies have mature and robust tooling ecosystems (SCSS/SASS, any of the dozens of well-supported HTML templating libraries). Users should not be expected to allow the execution of arbitrary code in a Turing-complete language on their machine in order to do these things for which we already have well-supported declarative languages. 8/10? or so

@Are0h The only reason JavaScript is so prevalent and well-supported is that large tech companies can make a hell of a lot more money if they're allowed to do complex computations on the user's machine and exploit dynamic features of the user-agent to track us.

9/10? or so

@Are0h No, I don't think JavaScript should disappear, but I do think it should wane. It's unnecessary in many places and, in my admittedly subjective experience, leads to broken shit for everyone except the market segement being targetted: able-bodied, sighted users on relatively powerful hardware running approved browsers on mainstream platforms. If web designers could stop shipping broken websites while still using JavaScript, that would be fine with me.

10/10

@Are0h My apologies for the long thread, but this is a fairly important issue to me and I wanted to get away from trying to express this rather complex opinion in tiny, easily-misunderstood chunks.

@tindall I don't mind long threads. I'd rather have someone be thorough than not, so it's all good.

And that gives us an opportunity to actually talk about the details rather than broad stroke it.

@Are0h I'm glad! I do still feel like I'm not communicating my point, though.

I'm explicitly NOT saying that "js is only used for the tasks HTML and CSS are used for". I'm saying that when it is, it needs to not be used at all, because it does the job less well than either one while being a burden on computers and humans. That's why I give all the examples of issues caused by using dynamic content where static content will do.

@tindall Yeah, we can agree it is over used in some spots, and that's cool, but that's a specific use case as it is very possible for the trinity of HTML, CSS and JS to play well together.

That's great for static content and that's cool. But the web has become so much more than a document reader. I think we need to adapt to what it is rather than trying to go back to what it was.

@tindall Yeah, we agree on this. I absolutely believe devs and designers need to do better concerning how we implement and use js.

I think that is much more useful conversation that just advocating getting rid of JS. Abandoning it out of frustrating isn't going to fix the underlying issue of bad practices becoming the norm. That's what we need to content with.

JS can absolutely be better. The issue is _why_ some platforms are choosing not be.

@tindall This is false. JS is so prevalent because it is the go to front end scripting language for the web. It has always been that.

And what you're describing is an implementation of how some entities use JS. Capitalism is not the reason JS is so popular. That's simply not remotely true.

@Are0h

> JS is so prevalent because it is the go to front end scripting language for the web. It has always been that.

I absolutely agree with you on that. I'm using the two synonymously. My basic thesis here is that I don't think front-end scripting, in whatever langauge, is necessary in the vast majority of web content, and where it is necessary, it isn't well-implemented.

@tindall Yes, I understand this point. I just don't agree with it.

There is something to be said about it's over use in some places that don't need it, and I understand that.

But the statement of saying that front end scripting is not needed is a comment I find extremely naive based on what the web has evolved into and what it has enabled.

@Are0h I think perhaps this is our fundamental point of disagreement. I just don't understand why, e.g., a news site can't set their site up to render correctly without scripting. Yes, using a user agent that doesn't support scripting means a loss in features. I don't expect to get infinite scroll or search-as-you-type in elinks. But why can't I read Motherboard articles to which I have a direct link? Why is it better to use scripting for that? I'm genuinely asking.

@tindall That's a question for those individual places, because in my experience, it's not that hard to have sensible scripting that is accessible. That's a specific implementation issue, not an inherent feature of JS.

Ha, it's funny you mention two features that I don't care for myself, so I feel you.

Ah, and there is the rub. _Who_ is saying it's better? Not you and definitely not me.

I don't think extraneous scripting is better. Never have.

@Are0h I'm glad we agree on this - I do think we're coming from the same place, fundamentally.

The reason I suggest click-to-play client side scripting is because it seriously discourages web designers from using JavaScript except when necessary. Think about the user stories, if you would:

If I go to a page to play a game, I'm probably going to click "allow". I know I'm there to run arbitrary code. Not so if I just want to read text. It discourages unnecessary JS.

@Are0h Also, to be clear, I've never contended that any of this is an "inherent feature" of JS.

However, client-side scripting is created in a world with deadlines and budgets, and if users and user agents don't do something to discourage bad practices, most web development shops won't spend the time on a11y, static fallbacks, et cetera.

@tindall Yeah, absolutely. We just disagree on the path to solution for it.

We are in total agreement on this point. Again, I absolutely believe implementation of JS needs to improve in such a manner that encourages trust and enables user to control what experience they want. I am big time advocate for this.

What I don't agree with is the idea that getting rid of JS is the path to get there.

@tindall This is assuming that js is only used for the tasks HTML and CSS are used for. This is false.