337
you are viewing a single comment's thread
view the rest of the comments
[-] words_number@programming.dev 26 points 1 year ago

JS is horse shit. Instead of trying to improve it or using that high level scripting language as a compilation target (wtf?!), we should deprecate it entirely and put all efforts into web assembly.

[-] wopazoo@hexbear.net 14 points 1 year ago

"JS is bad" is hardly even a lukewarm take.

[-] words_number@programming.dev 6 points 1 year ago

To me it seems like the internet is full of JS apologists. Maybe it's just YouTube xD

[-] reverendsteveii@lemm.ee 8 points 1 year ago

Idk anything about web assembly but I 100% agree that JS is absurd and feels like it was created in a weekend by some schmuck who just wanted to be able to edit html on the fly because it was.

[-] fuzzzerd@programming.dev 4 points 1 year ago

That's basically how it happened.

[-] NBJack@reddthat.com 2 points 1 year ago

(That's the joke!)

[-] ggppjj@lemmy.world 6 points 1 year ago

"show hn: I made a JavaScript engine in webassembly using rust"

[-] jvisick@programming.dev 2 points 1 year ago

At that point, just make a typescript engine so people don’t have to build their TS projects anymore

[-] LufyCZ@lemmy.world 6 points 1 year ago

Why exactly is it horse shit? It does have it's quirks but I wouldn't go that far

[-] SpaceCowboy@lemmy.ca 2 points 1 year ago

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.

[-] LufyCZ@lemmy.world 1 points 1 year ago

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.

[-] SpaceCowboy@lemmy.ca 1 points 1 year ago

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.

[-] LufyCZ@lemmy.world 1 points 1 year ago

browsers that are out there already C is compiled

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.

[-] SpaceCowboy@lemmy.ca 1 points 1 year ago

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.

[-] onlinepersona@programming.dev 5 points 1 year ago

How is this a hot take?

[-] Torty@beehaw.org 3 points 1 year ago

Is this a hot take? You're absolutely correct lol.

[-] mindbleach@sh.itjust.works 1 points 1 year ago

Adoption is a feature you can't design.

this post was submitted on 01 Sep 2023
337 points (96.2% liked)

Programming

17314 readers
53 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 2 years ago
MODERATORS