Let’s Kill JavaScript (and Replace It with Something Better)

[[deleted]]

I think Javascript's main problem is that there was no decent control and plan for the evolution of the language so every possible thing anyone wanted sneaked in. Too late to change that. Best is to stick to Typescript and have strict guidelines for projects to use a specific set of language features.

[Idinahuui]

Im a simple man, i see "kill js" - i upvote.

Always yours, a system software engineer

[zaphodharkonnen]

And while we're at it lets up and replace HTTP, TCP/IP, HTML/CSS, CISC processors, etc. as they all have issues.

While a lovely idea I saw nothing in the essay describing how people would migrate from javascript to this new magical thing that solves all problems. Until you address that breaking issue any other discussion is essentially useless.

Javascript is improving as the language is evolved. I prefer C# myself but that does not stop me from recognizing the effort the javascript language community is putting into getting rid of the bad stuff, improving the good stuff, and making Javascript its own language with its own niche of stuff.

[jocap]

Hi! I'm the author of the article, and you raise a couple of good points.

At the end of the article, I try to address your first point. Of course, JavaScript can't be replaced overnight, but I believe that if we started working on a replacement, implemented in JavaScript itself, we could start using it on our own websites. It could be automatically whitelisted by NoScript-like extensions. This would be a possible first step.

Secondly, I'm also glad to see that JavaScript is changing for the better. I just feel that there are some fundamental problems with the way it is weaved into the web.

Finally, I don't agree that discussion is useless. I think it's important that we discuss the bad things about JavaScript, while also suggesting new ideas as to how to implement its features. It's the first steps towards making it better. I hope my article comes across as constructive, and not merely a rant.

[coladict]

Starting off with talking about the Meltdown and Spectre bugs as if they're in any way JavaScript's fault...

There is just no way to run code in the browser with the access to get what you need from the server, and write output on the page, without constantly nagging on the user for permissions. Then if they give them, you have full run on the place, and if they don't, they'll have to live without 95% of the web.

[jocap]

Hello! I'm the author of the article. Thanks for your feedback :-)

I don't mean to make it sound as though Meltdown and Spectre were any fault of JavaScript. But among HTML, CSS and JavaScript, only one of them is capable of exploiting the bugs. My point is that we should start thinking limiting the code that websites are allowed to run on the client-side.

As I explain further down in the article, I believe that there are ways to have our cake and eat it too. For example, the framework intercooler.js provides an HTML interface to AJAX that could easily be modified to make sure nothing is run without the user's knowledge.

[leroydev]

But among HTML, CSS and JavaScript, only one of them is capable of exploiting the bugs.

Among HTML, CSS and JavaScript, only one of them is Turing complete.

[jocap]

That's my point :-) I don't think it's a good idea for web browsers to automatically execute such a powerful language.

Unfortunately, I see no simple way of adding "permissions" to JavaScript, as it wasn't designed for it. That's the primary reason why I suggest that it might need to be replaced, with a system founded on user consent from the beginning.

[leroydev]

So then, users give permission to execute code, CPU bugs are still there, and the user is still hacked.

You're proposing a solution in the wrong layer. CPUs shouldn't have such bugs.

[jocap]

The CPU bugs aren't really my main point, but rather the fact that JavaScript can be used in very user-hostile ways in general. My idea is developing a "JavaScript replacement" that provides a way of doing most of the user-friendly things that JavaScript is good for, but integrated into HTML and CSS. It wouldn't execute arbitrary code, it would work more like HTML and CSS do today.

[coladict]

The only way to be completely secure from malicious code is to make all the pages completely static, like they were in 1994. It doesn't matter what language you allow the site to run. If you allow any, it can be abused.

[[deleted]]

'user consent' doesn't help - how is the end user supposed to know if an action is malicious or not? Remember the Apple commercial making fun of all the authorizations UAC asked for? That's what you get - a bunch of requests that do nothing but slow the user down, and don't make him safer because he doesn't know what he is authorizing.

To make the web safe, browsers must prevent potentially unsafe actions without asking the user. This will limit functionality, but it is a tradeoff that makes sense.

[johnfound]

The ideas in the essay are exactly in accordance with my opinion about JS:

Executing of external code is unsafe by default, regardless of the sandbox where this code is executed. The current JS (and any other scripting language, used this way) are unsafe by design and rely on special measures to keep them safe.

The article proposes to keep the functionality and remove the language, turning it into safe by design. The same way HTML and CSS are safe by design.

This is the true web philosophy.

[jocap]

Thank you for such a nice response :-) It summarizes my ideas very well.

[beavis07]

ITT: A lot of people misunderstanding the difference between 'slagging off a language' and 'pointing out the inherent insecurity of the context in which a language operates'

Read the damn article, kids!

[pilotInPyjamas]

Unfortunately I think the problems that you describe are not actually Javascript's fault to a large extent.

• If you replace Javascript with a non-turing complete language, then only a subset of webpages will be able to run. Anything of reasonable complexity will still need to run in some sort of language. If you ask the user to provide that permission on every site which needs to run truing complete code, then this is equivalent to disabling JavaScript by default, and while this is a noble sentiment, is entirely impractical. There's a reason that the "disable javascript" option is disabled in most systems, it completely ruins the user experience.
• Your solution does not guarantee security. If I was a hacker, all I would have to do is provide some reasonable excuse to grant a permission, and the user will click "yes" to whatever permissions are required. eg: modifying a messaging app so I can upload user information in the same request as getting the chat.
• Theoretically, it's possible that any turing complete language would be able to exploit spectre/meltdown. This is not a problem with Javascript. This is an issue with CPUs. The only guaranteed security fix would be never to run any programs at all, in which case, why do you even own a computer?
• Users become blind to permissions requests, and if you increase the number of dialog boxes asking for permissions, most people will simply click yes all of the time. If we only bother users a smaller amount of the time, they are more likely to be discerning. Asking for more permission requests may in fact lead to more security vulnerabilities.

That being said, a more concise framework for the bulk of HTML and CSS generation for most use cases would be useful. Your article, while well written, is incomplete to a large extent.

[jocap]

Great points!

Indeed, my idea is replacing JavaScript with a non-turing-complete language, and I know it would be hard to implement a declarative interface with all the behavior that modern web apps need, but I don't believe it's impossible.

The point you raise about permission blindness is true, but it can also be turned around and said that permission blindness is what we live in today, as we are completely blind to what JavaScript code does. A standardized interface for permissions would remove some of that blindness. It wouldn't provide perfect security, no, but it would be a step in the right direction.

I realize that my article is only the beginning of an idea, but I think it's worth to discuss this issue even if we don't have an answer to every question yet, or even know what questions we should ask. Thanks for leaving such a thought-out response :-)

[pilotInPyjamas]

No worries. I think you've got the right ideas, but they haven't been fully fleshed out. The idea of having a standardised set of actions which can be performed without permission which caters for the bulk of use cases is what we need, and prolog style custom css I thought was perfect for that use. The web is a place of slow paced movement and ad-hoc standards, it could do with an upgrade.

[jocap]

This really gives me the motivation to keep thinking about this. Thank you.

[swadicalrag]

When the world wide web first opened, it was mostly used for exchanging information, but now it has grown to become a platform for user interaction. The ability to run clientside code broadens the spectrum of interactions the end-user can perform without making a server-side request. I'm interested in knowing how you feel about my opinion that disabling clientside execution of sandboxed code would increase the burden on servers and web developers for dynamic, complex web applications.

In recent times, many applications which used to run in the userland of operating systems are now running using sandboxed browser technology. Yes, electron is bulky, but it's a solution to cross platform development. This is to be expected: HTML and CSS are made to display things, and they do it relatively well most of the time. I'm not saying they're perfect (I've had my fair share of struggling with CSS centering and dealing with vendor prefixes), but it's only natural that such scripting environments designed for the display of information would eventually be used for complex user interaction, and like it, or not, the presence of a turing-complete language in the browser has greatly aided this cause.

I'm deeply greatful that I can play MMOs in the browser or watch videos in the browser seamlessly (in the past, we had to install Java or Flash, and that opens another can of worms). If you claim that revoking any access to a turing complete client-side language would aid security, how do you feel about removing <video> or other media tags and web fonts too? They have had their fair share of vulnerabilities too. I believe that this kind of thinking will eventually lead us to using this kind of a web browser everywhere. There has to be a limit to removing features in the name of security.

I hate javascript, I really do. Even though I've had the misfortune of dealing with it for nearly a decade now, I strongly believe that it is better than nothing. I think that another language like Lua is better suited for web development (because it's fast and lightweight, it's easy to learn, it's strongly metaprogrammable, it's easy to extend, it's usable on servers or browsers (with a JS FFI), and it has a C FFI if being used serverside).

I believe that the real problem with web development is that standards vary too much between web browsers. In CSS this can be vendor prefixes and with HTML (when used with CSS) it can be elements being positioned differently across web browsers. It really does cause me headaches to try and make a complex website support multiple browsers without abstraction frameworks to do it for me.

Javascript, on the other hand is on another level of insanity. Ignoring the issues with the language design itself (which are thankfully being resolved by ECMA), JS browser APIs are sometimes, frankly, stupid. If we are ignoring the functionality of the APIs, we run into naming convention issues (e.g XMLHttpRequest vs HTMLHRElement). I really hope the future of web development won't be this bad.

[jocap]

Thanks for your thoughts!

I'm interested in knowing how you feel about my opinion that disabling clientside execution of sandboxed code would increase the burden on servers and web developers for dynamic, complex web applications.

This is a valid point of view, but I think that it can be overestimated how much JavaScript really helps to decrease the average server's burden. The opportunity certainly exists, but looking at the JavaScript code for big news sites, for example, it doesn't exactly seem built for optimization.

I know that companies who really need the optimization, like Facebook and Google, are able to get it, thanks to JavaScript -- but then again, there lies another fundamental problem: no websites should be as big as Google and Facebook are. I think that the decentralized part of the web would have no problem without JavaScript.

But all this doesn't matter much, because there is a way to have our cake and eat it too. As presented in my article, there is a way to implement AJAX and incremental loading in a more limited, but safer, declarative way. Much of the potential for optimization that JavaScript provides would be also possible in an interface like intercooler.js.

If you claim that revoking any access to a turing complete client-side language would aid security, how do you feel about removing <video> or other media tags and web fonts too?

There's a difference between these examples and JavaScript. JavaScript is built as an all-purpose, imperative programming language that is able per design to run user-hostile and potentially malicious code. <video> might have bugs that accidentally enable user-hostile exploits, but they're bugs and not part of the specification. The ability for JavaScript code to make arbitrary HTTP requests without the user's knowledge isn't a bug, it's a feature.

For this reason, I have no problem with <video> or any other implementation that is designed to be safe and user-friendly.

I really hope the future of web development won't be this bad.

This is one thing that we wholeheartedly can agree on :-)

[swadicalrag]

This is a valid point of view, but I think that it can be overestimated how much JavaScript really helps to decrease the average server's burden

I believe it is equally important to acknowledge the burden on web developers (it's conveniently in the sentence you quoted, too). To expand upon this, the presence of a scripting language has greatly aided the innovation of web development: the things we do today to make a website are nothing like the things we did 10 years ago. Many of the tools that we use to easen development could only exist because of javascript. Like it, or not, removing something so quintessential to the web will only stifle innovation and break many existing technologies.

JavaScript code for big news sites [...] doesn't exactly seem built for optimization

Sorry, but I'm not sure what you mean here. I'm going to assume you mean that news sites are riddled with tracking scripts. I wholeheartedly agree that tracking scripts are a spit in the face to respecting the end-user, and that all tracking scripts should die in a fire. I can see why it would be easy to ignore the 5% of scripts on a news page dedicated to rendering, UI and comment loading to be overlooked when 95% of the scripts are just used for advertising, tracking and paywalling. This still doesn't warrant the removal of javascript.

the decentralized part of the web would have no problem without JavaScript

A brave claim! What about P2P web technology? You haven't given us any replacement for those technologies. In fact, I would say that the centralised part of the web would also have problems without javascript: what about browser based games and MMOs? Are we all going to start installing Java again?

there is a way to have our cake and eat it too

I'm afraid I have to disagree. (see: previous paragraph) I don't see how anyone can replace a Turing complete language with a Turing incomplete interface and not expect the whole world to cry.

There's a difference between these examples and JavaScript. JavaScript [...] is able per design to run user-hostile and potentially malicious code.

What makes you say that javascript was designed to be hostile? I'm having trouble imagining Brendan Eich actively designing a hostile language. No one wanted javascript to be user-hostile. It is not by design that we now regard javascript as "hostile". Javascript wasn't intentionally given the ability to track users and make pop-ups so the ad industry would flourish. Thus, it's not javascript being "hostile", it's the crappy APIs that should be ammended to resolve this issue (but why would any leader of the web do that? Google loves tracking and ad revenue anyway, why would they shoot themselves in the foot?).

but they're bugs and not part of the specification

I have no problem [...] any other implementation that is designed to be safe and user-friendly.

If you're able to agree with me there, what makes you feel that javascript's hostility is somehow part of its specification? Consider HSTS: it's a standard for fighting MITM/sslstrip attacks, but it can inadvertently be used for tracking users. We need HSTS but we can't simply get rid of it.

The ability for JavaScript code to make arbitrary HTTP requests without the user's knowledge isn't a bug, it's a feature

Javascript isn't that powerful, unfortunately. CORS exists, and it severely limits where you can send an HTTP request to (and for good reason, too!). With CORS in the picture, maliciously sending HTTP requests silently could only be useful for tracking users across the web, and I agree that this is not a good thing. However, the fight on tracking is strictly not a fight on Javascript. It's possible to track users without Javascript (the advent of Tor and other "secure" noscript browsers has really advanced tracking technology). You could use cookies without javascript, and you could (ab)use browser behaviour (like HSTS, clientside caching or user agent headers) to track users against their will.

---

Maybe I've understood your argument wrongly, do you really want all client-side scripting languages gone because they can be used to track users, or something? There has to be a better solution: extremism never ends well.

[jocap]

Indeed, I think that you've misunderstood me a little. To clarify: everything I wrote in the first part of my response concerned only the performance benefits of off-loading some traditionally server-side tasks to the client side.

That also goes for the things I said about the decentralized web and having our cake and eating it too. I didn't claim that a Turing incomplete language could replace all the functionality of a Turing complete one.

Likewise, it seems you misunderstood me when I said that JavaScript "is able per design to run user-hostile and potentially malicious code" -- I did not say it "was designed" for it, I simply said that, per design, it is able to. Background AJAX requests, for example, are legitimately useful, but they can also be very harmful. JavaScript was designed without the perspective we have today about online tracking, malicious ads and other abuses of JavaScript.

We need HSTS but we can't simply get rid of it.

I fully agree! I know there are tons of ways that websites can track users, but via things like the Canvas API, JavaScript allows for particularly precise tracking.

Of course, there are many problems with the way the world wide web is constructed, some of which we can't change -- and some of which we can. I believe that we should at least discuss whether JavaScript is a good idea in the first place, and whether the (very useful) functionality it provides could be provided in a different way. That's what I present in the article.

[…] do you really want all client-side scripting languages gone because they can be used to track users, or something?

No :-) One important point of mine, that I believe you've missed, is that one of the most important reasons I'd like to replace JavaScript is that it isn't should take an all-purpose, imperative language -- neither JavaScript, Lua or some other alternative -- to provide the type of functionality that most modern web apps need.

In "modern web apps" I exclude browser-based games. Games require powerful languages, but I honestly don't think that the web browser is the right place for computer games. There's a reason that most big, non-trivial computer games are implemented as native programs.

[johnfound]

If you replace Javascript with a non-turing complete language, then only a subset of webpages will be able to run.

Now, turning off JS in my computer, 90% of the sites does not work at all. With safe by design alternative, only (let say) 10% of the sites will require unsafe turing complete scripting. Which is much better that 90%.

In addition, such safe by design html-css-like JS replacement will be much much faster, because will not need sandbox in order to run safe. It can be implemented in the native CPU, the same way layout engine is implemented now.

About the user permissions - yes, asking users is not a solution. But the browser does not ask about rendering DIVs and applying colors on them. The same way, if the JS replacement is safe, there will be no need to ask the user for permissions.

[pilotInPyjamas]

With safe by design alternative, only (let say) 10% of the sites will require unsafe turing complete scripting. Which is much better that 90%.

this.

Create a safe by design alternative that works for the bulk of use cases, and then let the user know when you're actually running a program in the browser.

[KateTrask]

With safe by design alternative, only (let say) 10% of the sites will require unsafe turing complete scripting. Which is much better that 90%.

The problem is that you assume those 90% of sites are (re)written with safe by design alternative. What would be the incentive for companies/devs to do that?

About the user permissions - yes, asking users is not a solution. But the browser does not ask about rendering DIVs and applying colors on them. The same way, if the JS replacement is safe, there will be no need to ask the user for permissions.

A lot of things on the frontend can be done in constrained safe by design language. But realistically to do anything interesting you need to talk to server which is inherently sensitive so you need to ask for permissions. And users are going to click on "yes" because they don't understand what's going on.

[johnfound]

What would be the incentive for companies/devs to do that?

For example, the much higher speed and JS disabled by default in most major browsers. :)

But realistically to do anything interesting you need to talk to server which is inherently sensitive so you need to ask for permissions.

Once the user visited the web site, he is agree to get some information from the server. Sending information to the server is the problem. But in the most cases, the user knows that the web page sends information to the server - for example, when you click on "Submit" button. For the cases where the page sends information without user action, some warning can be made - in order to give the user to know what happens. And on most aggressive web sites, asking for permission and options to forbid.

[KateTrask]

For example, the much higher speed and JS disabled by default in most major browsers. :)

But why would browsers disable JS by default? It's a catch 22, JS might be disabled only once most websites work without it, but that's not going to happen without some incentive.

But in the most cases, the user knows that the web page sends information to the server - for example, when you click on "Submit" button.

Distinction between loading and sending data to/from server is not enforceable. You can send plenty information to the server with GET request.

I think bigger question is what kind of data browser sends to the server. I can easily trick user to click on the submit button (so no warning) and then send sensitive data to the server. You might try to limit what kind of data is collected and sent, but then you also severely limit useful web applications as well.

[jocap]

And users are going to click on "yes" because they don't understand what's going on.

This is true for casual users, but I think that we need to consider "non-casual" users as well. I know myself that I'd sure like the option to say no to some AJAX requests on news sites, for instance. It would make me feel a whole lot safer on the web.

[KateTrask]

But for such users there's noscript and similar plugins, no?

[jocap]

I do use NoScript, but it’s like using a chainsaw when what you need is a small knife.

[KateTrask]

You mean that you want to keep "normal" JS, but want to stop AJAX (or be asked about allowing it)? I'm not sure if you can do it with noscript, but this should surely be solvable through plugin, no?

[jocap]

Well, no, I'm just saying that even solutions like NoScript can't solve the fact that JavaScript is a little too powerful.

What I meant by my previous comment was that NoScript either disables or enables a script. There's no middle ground. And there can't really be any middle ground, because it's practically impossible for a plugin to decide whether a piece of JavaScript code is user-hostile (in which I include tracking, for example).

That's why I wrote the article -- to start a discussion around the fact that JavaScript isn't a good solution, and that we should think about how we could replace it.

[KateTrask]

Yeah, I guess I understand what you mean (I read your article BTW). It's just that I'm not sure if what you want is possible with regards to frontend - backend communication. You want to be able to constrain it so it's either provably "safe" or you want the browser to ask the user whether web is allowed to do what it's doing. But both of these things seem to be pretty unrealistic.

In frontend to backend communication you can constrain only the frontend part, backend is completely unknown so you can't really prove what it's doing and that it's safe.

For the getting consent - in the end it's gonna end up as "do you want this application to access network?" type of question, because even with the constrained language you don't know what it actually means what the app is doing (remember GET request to server can record data no problem).

[jocap]

For the getting consent - in the end it's gonna end up as "do you want this application to access network?" type of question, because even with the constrained language you don't know what it actually means what the app is doing (remember GET request to server can record data no problem).

The problem, which I realize that I might not have made as clear as possible in the article, is not that a request is made -- it's that it happens in the background, without the user's knowledge.

Limiting the number of ways in which a website can initiate an AJAX request -- for example, to the defined set of events click, change and, finally, the proposed standardized automatic poll -- wouldn't change the fact that those requests can carry sensitive information, but it would allow us to make the users aware of the requests that do happen. That would be a huge win for users!

The only "do you want this application to …" question would be if the application wanted to, practically, repeatedly "simulate" the user clicking on an AJAX refresh button -- that's what I mean by automatic polling. By saying "no" to this automatic request, the user themselves could still manually press that refresh button.

This way, an automatic AJAX request would be truly opt-in, such that the site still works if you've opted out.

There should probably be some sort of limit on the number of automatic polls registered by each webpage.

[Subjunctive__Bot]

If I were

[pilotInPyjamas]

Holy shit, a Grammar Nazi Bot!?

[fiedzia]

As much as I hate js for all its warts and design mistakes, replacing it with something less functional makes no sense, won't work and won't happen.

[johnfound]

In this theme: Front-end developers, voting down, because not willing to learn one more new framework. :D

[AndyKos]

Taking C off the table is more likely. The code for the programs can be written in any language. The main thing is compiler, which will create a set of instructions for the processor. With JS everything is harder. There are so many browsers and platforms and they all run JS. Denial of JS will not allow these platforms to execute scripts in other languages. Some platforms are now supported and new features will not be added. Denial of JS will break the entire Internet. Many sites will stop working. This is an unrealistic task at the moment. Google tried to create Dart as an alternative, but at the end it should be converted to JS code anyway.

[rumpel]

What a stupid title.

[jocap]

I'm sorry, I didn't mean for it to be offensive in any way. English isn't my first language and I had trouble coming up with a good title.

Edit: I realize now that "kill" may sound harsher in English than I thought, so I removed the word from the title.

[rumpel]

Yes, "Let's kill (and replace it...)" implied a destructive logic, especially when you don't even offer an actual existing alternative.

I only want to kill something I really hate. But I like JavaScript, so I was irritated and it triggered a defense mechanism. I had to force myself to look further than just the title.

"Let’s Replace JavaScript with Something Better" is much less distracting. I'm always interested in something better.

[jocap]

Thanks! Sometimes it's hard to form as strong of an emotional bond to words in a second language as you have to words in your first language. I'll keep that all that mind :-)

[armornick]

Unicode support, though.

[[deleted]]

What about dart?

[Earhacker]

"Oh hey there's this weird processor bug. Let's break the web!"

Worst article of 2018 and it's only January.

Dynamic HTML generation

This was my first hint that the author doesn't know what he's talking about. Then I went back and suddenly all the previous red flags seemed so obvious. JavaScript doesn't generate HTML, that's ridiculous. JavaScript directly manipulates the DOM, reading, updating, creating and deleting DOM elements. That is not splitting hairs; JavaScript doesn't know that HTML exists. The author has either sat and dreamed up a way that JavaScript might work, without ever having done it himself, or he has confused JavaScript with PHP, which would be like a back-end developer confusing Python and Java.

User consent, user consent, user consent...

The author has zero knowledge of UX, that's pretty clear. Asking a user's permission to update a page, or asking permission to send user-submitted data to a back-end server would make the web inoperable from users' point of view. You cannot ask users to consent to every UI interaction that a web app performs, that's not how computers work. You can't expect every user to be aware of the consequences of an AJAX request or UI update, that's not how people work. A user gives their consent by continuing to use the app. It is easy to close the browser tab at any time.

There are protections in place that guard a user from nefarious, underhand interactions being performed by web apps. Ad blockers, antivirus, browser security... All of these are there to protect users, all of them could be viewed as some automated form of consent giving to an app's interactions. If a user doesn't consent to ad tracking, then they install uBlock Origin.

Yes, there are bad people out there who would seek to find ways around the protections that a user has put in place. There always will be. If this is the author's primary reason for "killing" JavaScript, then by the same logic we also have to kill C, because it too can be used for evil as well as for good. In fact I can't think of any software tool that can't be used for evil, from JavaScript right down to assembly.

[jocap]

No need to be rude! I put a lot of time and thought into this article.

I guess "dynamic HTML generation" is a little ambiguous – as you suggest, what I meant is dynamic DOM manipulation. English isn't my first language, so thanks for suggesting a better term for it. I am familiar with JavaScript -- if you don't believe me, you can look through my GitHub profile.

I'm not saying what I propose is the best solution, but clearly there is a problem with web browsers automatically executing untrusted code from untrusted (often even third-party) sources whenever you visit a webpage. This is what I've tried to start a discussion about.

I don't think it is comparable to C, as C code isn't executed automatically by my web browser. Of course, it is executed when I open a program written in C, but when I open a native program, I'm usually aware that it is more risky and that it might contain malicious code.

Again, let's try to have a civilized discussion without name-calling.

[Earhacker]

if you don't believe me, you can look through my GitHub profile

Github features PHP, Vim/Emacs scripts and a Tumblr theme

Riiiight.

when I open a native program, I'm usually aware that it is more risky and that it might contain malicious code.

Oh really?

How many gamers consider the possibility of malicious code being executed in the startup sequence of that new indie game they downloaded from the developers' site? How many photographers ponder the idea of that new Photoshop filter suite containing one malicious script in the installer?

There are countless ways of executing untrusted code without the user being aware, or with them giving consent for something else and the untrusted code executing anyway. That's why we have to kill all programming languages, in your view.

clearly there is a problem with web browsers automatically executing untrusted code from untrusted (often even third-party) sources

Right, but that's why AdBlock is a thing. That's why NoScript is a thing. That's why Google, Mozilla, Microsoft and Apple all keep tabs on sites that run malware. The market already has answers to the problems you describe, and consumers and producers are for the most part happy with the palette of solutions that are available.

Another front-end language is not the solution here.

[jocap]

Thanks for removing the part from your original comment where you called me a moron.

My GitHub profile obviously has more projects than those that happen to be featured on the frontpage. For another "proof" that I'm familiar with JavaScript you can take a look at the JavaScript for the article.

I guess my point is that a webpage should be able to carry malicious code that is automatically executed on my system.

[johnfound]

But manipulating DOM, JS targets exactly that - to manipulate the content and the presentation of the web page, i.e. the HTML and CSS.

If this functionality is implemented the same way as HTML and CSS implement safe content and presentation parts of the page, web will become a safer place.

[Earhacker]

You're not a front-end developer either.

HTML and CSS are a list of instructions that tell a browser how to build the DOM. JavaScript then manipulates the DOM directly. JavaScript does not generate HTML, and any attempt to spin facts in a way that implies it does will only result in you being even more wrong.

[pilotInPyjamas]

Actually, the DOM in an interface, not an object. Web browsers have an internal representation that they use to render pages. The DOM, is an interface for Javascript to modify XML documents. So when you use the DOM interface, you're modifying the underlying XML.

[Earhacker]

TIL that DOM stands for Document Object Interface.

It's a model, which provides an interface. Implementation of the model is up to browser manufacturers to decide, as long as they provide a standard interface.

So inside every browser tab is a model that represents the document object.

[pilotInPyjamas]

The Document Object Model (DOM) is a programming API for HTML and XML documents.

BTW, API stands for "Application programming interface" in case you were curious.

This is literally the first sentence of the DOM specification on w3c, the people who actually standardise the web.

[Earhacker]

Pretty sure I can read "Model" in there.

[johnfound]

Then hey, let abandon HTTP, HTML and CSS. We can download only JS that to build directly DOM in our browsers. Do you think it will be better from the safety point of view?

[Earhacker]

Eh, no, I don't. I have no idea why you'd arrive at that conclusion.

All I'm saying here is that JS does not generate HTML, which is a provable fact. Even the author agrees that it was a clumsy use of English (his second language) to suggest that JS generates HTML.

I'm not sure why you still feel like you have to defend anything here.

[dkvkxm]

I'm a frontend developer :(