this post was submitted on 01 Sep 2023
329 points (96.1% liked)
Programming
17398 readers
105 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think it suffers from the same problem as SQL. A bunch organizations and companies would need to agree to make improvements, you don't want to break compatibility, so nothing really improves. You just get some extensions to it here and there which just makes it messier.
Isn't the "extension" problem the same with almost all programming languages?
For example, does 80s C compile under gcc with 2015 features? If it does, then it's no better than JS.
Yeah but with JS, you have to consider the browsers that are out there already. I think this is getting better now that IE is killed off, but there's still a consideration about whether to use a new feature that doesn't work on older browsers.
With C, it's compiled so if you're distributing the binary, you're done. And if you're sharing the source to another developer, that dev will be likely to be technically proficient enough to update gcc and any needed libraries to the right version to get it to compile.
When it's an interpreted language that is interpreted by browsers made by different companies and organizations (so they have to agree on changes), with users not being reliable of keeping their browsers up to date, it's going to be messy. Also there's security concerns, you need to make sure when implementing the extension it won't allow bad actors to make scripts to take over the users computer.
It's not anyone's fault, it's just a significantly more difficult problem to extend a language that is going to be sent to user's computer on the fly from arbitrary websites and have those extensions be reliable, secure, and consistent across the various companies implementing it.
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.