| The ECMAScript committee really need to address the core issues of JS performance - native integers, structs, linear layouts, stack allocation, SIMD, memory arenas, etc. Javascript should ideally be capable of superb performance for its own tools. |
| |
| ▲ | mu53 a day ago | parent [-] | | JS is eating the world. You can fight it like so many people before, but you will lose like everyone else | | |
| ▲ | vacuity a day ago | parent | next [-] | | Grandparent is making the case that it shouldn't have this role, which is independent of it having the role. It seems contrary to "the hacker spirit" to use the is-ought fallacy to discourage innovation. Is it wrong to have a contrary, if probably doomed to fail, stance to the mainstream? But of course a contrary idea would fail if everyone seeks the mainstream instead of it. To justify sticking to the mainstream, you have to weigh its costs against the benefits of the alternative too. | |
| ▲ | pdimitar a day ago | parent | prev | next [-] | | You are not paying attention. WASM's ecosystem is moving slowly but surely in the direction of JS being thrown away for good. Ain't happening anytime soon -- sadly -- but especially with WIT used to specify various modules and collections of modules plus having more or less uniform function specification, the days of JS' monopoly are numbered. The writing is on the wall. There are successful WASM web apps not written in JS today. JS is being tolerated. Not adored. Frontenders are living in a bubble and don't see it. | |
| ▲ | pjmlp a day ago | parent | prev [-] | | Until there are electricity bills from servers to pay. JavaScript on the server, only when I can't say no for whatever reason, like being forced to search for another job as consequence of it. Instead of rewriting JavaScript tools in Zig, Rust, Go, whatever cool compiled language of the month, use the said language directly. | | |
| ▲ | pdimitar a day ago | parent [-] | | I believe all of Zig, Rust and Go have been around for long enough to not deserve the moniker "cool compiled language of the month" though. I do agree that it's time to write frontend not in JS. It has been time for 10+ years even but oh well. | | |
| ▲ | pjmlp a day ago | parent [-] | | English reading compreehension problem, or feeling attacked? | | |
| ▲ | pdimitar a day ago | parent [-] | | Needlessly provocative. Sounds more like you felt attacked. No reason for me to feel attacked, I pointed out that what you said doesn't make much sense in terms of how long have these languages been around. | | |
| ▲ | pjmlp a day ago | parent [-] | | On the contrary, apparently we are in a need of English lesson over here. "Instead of rewriting JavaScript tools in Zig, Rust, Go, whatever cool compiled language of the month, use the said language directly." Meaning use Zig instead of JavaScript, use Rust instead of JavaScript, use Go instead of JavaScript, use "whatever cool compiled language of the month" instead of JavaScript, or if you prefer for the last example, use "whatever compiled language takes your fancy" instead of JavaScript. Clear enough? | | |
| ▲ | pdimitar a day ago | parent [-] | | Would be clear if it did not seem to me that you are including three languages that have been around for a while in the "whatever cool compiled language of the month" group. If not -- then clear. If yes, then this is getting even more confusing. | | |
| ▲ | pjmlp 17 hours ago | parent [-] | | It is called an enumerations of choices, 3 named ones, followed by a generalisation of whatever else might possible as option. Given that boring languages like Java, C#, OCaml, Haskell are kind behind their times for cool kids to rewrite stuff, that leaves the unamed cool programming language of the month as option, whatever that language may be. |
|
|
|
|
|
|
|
|
