Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Should Stop Using JavaScript According to Douglas Crockford (2023)

old.reddit.com

Post reply on HN
Print view View original

61–70 of 77 posts

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#61

Post by DemocracyFTW2 »

recursive wrote: post #15

I think I agree with everything he's saying. There have been arguments against javascript for a long time. If anything though, I think they've diminished over time as the language has improved. I still don't really like it. But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way. So people will keep using it at least as long as that's true. I'm…

I think the issue with comments runs a bit deeper and is more pervasive than the (sad) fact that plain JSON does not support them. Case in point, I just tried and improved a frequently-used piece of 3rd-party software (written in Python) that I use as a CLI tool. Because I use it frequently I want to pass in parameters on the command line instead of editing a TOML file, so I got myself a TOML parser and wrote a teeny NodeJS script that reads the TOML and returns an object on which I set a property according to the argv value, then serialize it and write out to the TOML file, then run that Python tool which grabs the value from the config. Nice kludge and all BUT, as a matter of course, the code comments in the TOML file that instruct users what the entries are for and so on—those are gone after the update. I fixed that problem by making a copy of the original TOML file.

So long whine short, I believe comments should have some kind of 1st class status in configuration files and tools should ideally offer to preserve them even when settings are updated, and to delete them when e.g. talking to another electronic machine over the telephone network, if you know what I mean. The same really goes for comments in other languages like JS, CSS, HTML: they're quite often just fly-over territory, but sometimes, just sometimes folks, they should be kept, and I don't see a great many tools that readily give me that option.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#62

Post by DemocracyFTW2 »

Devasta wrote: post #30

Javascript runs on every device, gets around corporate firewalls, has the backing of every major tech company and most crucially has way lower expectations of quality: If a desktop app crashes your users will curse your name, a Javascript app they'll just shrug and refresh the page. Is it a bad language? Doesn't matter, nothing can beat that feature set. In the year 2424 people will be using machines a hundred thousa…

> In the year 2424

...if Man is still alive

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#63

Post by 7jjjjjjj »

DemocracyFTW2 wrote: post #61
recursive wrote: post #15

I think I agree with everything he's saying. There have been arguments against javascript for a long time. If anything though, I think they've diminished over time as the language has improved. I still don't really like it. But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way. So people will keep using it at least as long as that's true. I'm…

I think the issue with comments runs a bit deeper and is more pervasive than the (sad) fact that plain JSON does not support them. Case in point, I just tried and improved a frequently-used piece of 3rd-party software (written in Python) that I use as a CLI tool. Because I use it frequently I want to pass in parameters on the command line instead of editing a TOML file, so I got myself a TOML parser and wrote a teeny…

This project claims to do that:

https://pypi.org/project/tomlkit/

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#64

Post by epidemian »

zbentley wrote: post #40
andrewfromx wrote: post #33

Earlier quoted context omitted.

so what's the big problem with calling instantiateStreaming? Explain it to me like i'm 5

instantiateStreaming is not the problem; the problem is that JS code is necessary (via that function or another) to execute WASM, and JS is necessary to call back from WASM into browser APIs. Because of that, WASM in the browser is, at present, effectively a JavaScript extension language, and it cannot meet the goals discussed by Crockford in TFA. This hybrid approach that requires JS both at bootstrap and browser-AP…

Not only that. The DOM API and general browser APIs are designed with JS semantics in mind, and for JS. Just like the UNIX APIs are designed in C and expect to be called from C.

So even if you get other languages working alright on browsers, they are always going to be second-class citizens IMO, because they are going to be interfacing with JS APIs.

I can't think of a way to avoid this TBH, other than designing a different API for the new language, at which point i think we'd be no longer talking about the web as we know it.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#65

Post by andrewfromx »

epidemian wrote: post #64
zbentley wrote: post #40

Earlier quoted context omitted.

instantiateStreaming is not the problem; the problem is that JS code is necessary (via that function or another) to execute WASM, and JS is necessary to call back from WASM into browser APIs. Because of that, WASM in the browser is, at present, effectively a JavaScript extension language, and it cannot meet the goals discussed by Crockford in TFA. This hybrid approach that requires JS both at bootstrap and browser-AP…

Not only that. The DOM API and general browser APIs are designed with JS semantics in mind, and for JS. Just like the UNIX APIs are designed in C and expect to be called from C. So even if you get other languages working alright on browsers, they are always going to be second-class citizens IMO, because they are going to be interfacing with JS APIs. I can't think of a way to avoid this TBH, other than designing a dif…

ok but I still don't understand why it's not a great idea for everyone to embrace WASM as it is today and write your frontend logic in go or rust EVEN if you have to use instantiateStreaming.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#66

Post by epidemian »

andrewfromx wrote: post #65
epidemian wrote: post #64

Earlier quoted context omitted.

Not only that. The DOM API and general browser APIs are designed with JS semantics in mind, and for JS. Just like the UNIX APIs are designed in C and expect to be called from C. So even if you get other languages working alright on browsers, they are always going to be second-class citizens IMO, because they are going to be interfacing with JS APIs. I can't think of a way to avoid this TBH, other than designing a dif…

ok but I still don't understand why it's not a great idea for everyone to embrace WASM as it is today and write your frontend logic in go or rust EVEN if you have to use instantiateStreaming.

You'd still need to interface with the JS APIs, wouldn't you?

For example, an API like `Element.prototype.addEventListener(string, callback)` wouldn't make much sense in Rust, IDK about Go. Sure, you can make it work, but you'll always be rubbing against an API that was not designed for that language. Hell, addEventListener isn't even on the Element prototype, but on the EventTarget prototype, which Element.prototype inherits from. And that's something else that wouldn't make sense at all in Rust: prototypical inheritance. But it's part of the DOM API. It's part of the web. So we'd have to deal with it too, even if we switch to a new language.

Does this make some sense? I feel like i'm repeating what's been said before in this comment chain, so maybe i'm missing something about what you're not understanding (:

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#67

Post by andrewfromx »

epidemian wrote: post #66
andrewfromx wrote: post #65

Earlier quoted context omitted.

ok but I still don't understand why it's not a great idea for everyone to embrace WASM as it is today and write your frontend logic in go or rust EVEN if you have to use instantiateStreaming.

You'd still need to interface with the JS APIs, wouldn't you? For example, an API like `Element.prototype.addEventListener(string, callback)` wouldn't make much sense in Rust, IDK about Go. Sure, you can make it work, but you'll always be rubbing against an API that was not designed for that language. Hell, addEventListener isn't even on the Element prototype, but on the EventTarget prototype, which Element.prototype…

https://github.com/andrewarrow/homeducky/blob/main/browser/v...

https://github.com/andrewarrow/homeducky/blob/main/browser/r...

https://github.com/andrewarrow/homeducky/blob/main/browser/t...

https://www.youtube.com/watch?v=dxO94MvfRCg

here's example coding frontend in go. I think I've achieved with vote.go and register.go and timer.go above a nice way in Go to do Javascript things. I don't feel limited.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#68

Post by FractalHQ »

leptons wrote: post #28

I started with Javascript the same week it was released in Netscape. Before that I was using Lynx on an Amiga, and I often opined that this internet thing needed a scripting language. Javascript came along and it was amazing, it answered my prayers. As Javascript and browser tech evolved, I grew with it, doing amazing things long before anyone else was, like "AJAX", and "Dynamic HTML", etc. I'm still coding Javascrip…

I’m glad I found your comment at the bottom of this thread, because while I avoid JS like the plague, I love Typescript, and I can build what feels like anything for any platform faster than many people believe is possible when I quote them.

I just need some more advanced features from C# / some runtime types… not a new language altogether. But even still, of all the languages I’ve tried, I prefer Typescript and its flexibility, power, and ecosystem by a decent margin.

I must be missing a hell of a lot because I find it very hard to relate to anyone in this thread.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#69

Post by Rohansi »

andrewfromx wrote: post #49
Rohansi wrote: post #47

Earlier quoted context omitted.

Your logic still needs to run JS code to change the DOM. You are indirectly relying on JS despite using WASM.

ok but I have all the advantages of go. I can code my go in a modern way and escape JS traps despite the end result is still using js.

Yeah I know. I don't care if it needs a bit of JS to bootstrap either. At some point it should get to a state where you can have a site with WASM and no JS required.

Re: We Should Stop Using JavaScript According to Douglas Crockford (2023)

#70

Post by matt-attack »

d_tr wrote: post #32
karaterobot wrote: post #25

By any measure except by comparison to a hypothetical counterfactual universe, I think javascript is one of the most successful programming languages of all time, and one that has added more to the world than almost any other. It's like standards: some have better performance characteristics than others, some are more elegant, and so on. But the the best standard is the one everybody actually uses, because that is th…

> I think javascript is one of the most successful programming languages of all time, and one that has added more to the world than almost any other. It is just a scripting language. If it wasn't JavaScript, it would be something else. It hasn't added anything besides lots of crappy code, most of which shouldn't have been written in JavaScript anyway. I can't understand how anyone could find its moronic semantics bea…

Can you give an example?
Post reply on HN