JS makes heavy use of pollyfills where needed, bridging the gap between old browsers and new ones.
A binary might still require a specific shared lib version, specific architecture, whatever, it’s not a magic bullet.
update gcc and any needed libraries
Doesn’t always work when working with legacy unupdated dependencies.
security concerns… …scripts to take over the users compurer
Wouldn’t having compiled code running in the browser (via webassembly) be actually worse for security? With JS you can at least see the source that’s being run, with compiled WA, not so much. Don’t really understand this point.
A binary might still require a specific shared lib version, specific architecture,
Yeah but those issues are dealt with at compile time by a developer. The problems don’t manifest themselves at runtime as they do with an interpreted language.
Doesn’t always work when working with legacy unupdated dependencies.
Also compile time, not runtime.
With JS you can at least see the source that’s being run,
You could disassemble compiled code and read the assembly code. Yeah that’s difficult, but about the same difficulty as reading JS that’s been run through an optimizer. Nobody has time for that, and users certainly don’t have the skill to do that, so the the organizations that make the browsers are ultimately responsible for making sure any new addition to JS isn’t going to cause the security problem.
Wouldn’t having compiled code running in the browser (via webassembly) be actually worse for security?
About the same for security. I don’t know much about web assembly but it has similar problems. I mean the reason I don’t know much about it is because it’s too new, can’t count on it being widely supported, etc. Similar problems as JS. But being compiled to a common language might shift the pain of dealing with a lot of problems with language changes to the people who write the compilers for it. Time will tell.
But the thing is, most languages aren’t designed to be primarily interpreted by a browser. Nobody is going to say “Hmmm we better think about how this will affect web browser security if we add to the language.” Because use by browsers as a web assembly isn’t the primary use case. If a language change negatively affects a browser, that’s their problem to sort out.
But with JS it is primarily being used as an interpreted language implemented by browser makers. Which means the browser makers have a huge amount of influence over the decision making process. If google says “we have concerns over security with this feature so we aren’t using it in chrome” then well it’s not a feature that developers can use because it’s not going to work for most users.
I think you’re trying to make this a fair comparison, but my point is that it is not a fair comparison. What the languages are used for and how they’re deployed impacts process for improving them. The requirements for JS in terms of what it’s primarily used for and how it gets deployed makes it difficult to change, which is why it is as messy as it is. Takes a lot longer to get changes accepted by all the parties that need to accept them.
JS makes heavy use of pollyfills where needed, bridging the gap between old browsers and new ones.
A binary might still require a specific shared lib version, specific architecture, whatever, it’s not a magic bullet.
Doesn’t always work when working with legacy unupdated dependencies.
Wouldn’t having compiled code running in the browser (via webassembly) be actually worse for security? With JS you can at least see the source that’s being run, with compiled WA, not so much. Don’t really understand this point.
Yeah but those issues are dealt with at compile time by a developer. The problems don’t manifest themselves at runtime as they do with an interpreted language.
Also compile time, not runtime.
You could disassemble compiled code and read the assembly code. Yeah that’s difficult, but about the same difficulty as reading JS that’s been run through an optimizer. Nobody has time for that, and users certainly don’t have the skill to do that, so the the organizations that make the browsers are ultimately responsible for making sure any new addition to JS isn’t going to cause the security problem.
About the same for security. I don’t know much about web assembly but it has similar problems. I mean the reason I don’t know much about it is because it’s too new, can’t count on it being widely supported, etc. Similar problems as JS. But being compiled to a common language might shift the pain of dealing with a lot of problems with language changes to the people who write the compilers for it. Time will tell.
But the thing is, most languages aren’t designed to be primarily interpreted by a browser. Nobody is going to say “Hmmm we better think about how this will affect web browser security if we add to the language.” Because use by browsers as a web assembly isn’t the primary use case. If a language change negatively affects a browser, that’s their problem to sort out.
But with JS it is primarily being used as an interpreted language implemented by browser makers. Which means the browser makers have a huge amount of influence over the decision making process. If google says “we have concerns over security with this feature so we aren’t using it in chrome” then well it’s not a feature that developers can use because it’s not going to work for most users.
I think you’re trying to make this a fair comparison, but my point is that it is not a fair comparison. What the languages are used for and how they’re deployed impacts process for improving them. The requirements for JS in terms of what it’s primarily used for and how it gets deployed makes it difficult to change, which is why it is as messy as it is. Takes a lot longer to get changes accepted by all the parties that need to accept them.