41–50 of 202 posts
Earlier quoted context omitted.
Much faster than Python or almost any non-native-compiled language (except Java)
Python is a notoriously slow language so that's not saying much. And there are a number of languages on the JVM e.g. Java, Scala, Kotlin, Clojure as well as countless compiled ones which are near-native.
Also, what do he suggest would be the replacement? Because it's not enough to replace the scripting language, it would need to fit into the DOM, HTML and CSS too.
I think it's quite backward thinking actually to bend the language making it more complex for the human for the benefit of the compiler. Especially with the shift to LLMs, programming languages should be closer to natural language and expression, not vice versa.
The good JS packaging ecosystem takes care of the small standard library issue, but I definitely agree there's room for expansion there. This seems like a surmountable problem. And by standard lib I'm not talking about things that can be trivially be implemented with Array/Object/Map (like queues or ordered maps), I mean things like RNG, math functions, or things like the recently added `fetch` method for HTTP calls.
A bit related: I still do not really understand why WASM has no direct DOM access. Answers to this question seem to fall into two categories:
- We don't need it, because you can do everything via a Javascript detour easily
- We don't want it for reason X
To me both feel a bit like excuses. I've yet to see a hard technical reason why it is not done. So, why not make WASM a first class citizen and do away with Javascript for good?
Earlier quoted context omitted.
> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don…
Seriously, every time people complain about CSS and HTML I think about how much work it is to support all the localisation and layout stuff they do. Managing massively different sized screens as elegantly as them is hard and yeah, it's still not that elegant or easy, but I haven't used anything better that didn't sacrifice something for it.
I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend / system software development.
It's just that noone has been able to replicate that kind of success in the web-based frontend space.
This happened in the case of Rust and Go after LOTS of searching for better alternatives to C/C++ and later Java. There are a lot of failed attempts along the way, and some which find their niche but fail to displace the older generation languages in any meaningful way.
There has been TypeScript and Dart and transpilers that have tried to shield us from the horrors of JavaScript development, but in the end they still are too closely related to JavaScript and its runtime to truly displace it. I feel like we have an opportunity now, with WebAssembly, to move beyond these limitations.
If browsers and web standards move to a point where we can use WebAssembly as a first class citizen, without the need for JavaScript scaffolding, we could see the rise of a new crop of languages for the frontend. Perhaps even making it possible to remove JavaScript entirely and move it into a WebAssembly module eventually, to remove it as the default choice and put it on equal footing with new alternatives.
We could take the lessons we have learned from other modern languages, and apply them more natively to frontend problems and practices, with language-native tooling and a higher level of integration in those tools than we have been able to achieve with JavaScript.
As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly. A bit related: I still do not really understand why WASM has no direct DOM access. Answers to this question seem to fall into two categories: - We don't need it, because you can do everything via a Javascript detour easily - We don't want it for reason X To me both feel a bit like excuses. I've yet…
0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
What is one of those 'really clean' languages that we should be using then? I'm interested!
Earlier quoted context omitted.
> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don…
Seriously, every time people complain about CSS and HTML I think about how much work it is to support all the localisation and layout stuff they do. Managing massively different sized screens as elegantly as them is hard and yeah, it's still not that elegant or easy, but I haven't used anything better that didn't sacrifice something for it.
While people like John Resig were innovating (jquery) working with the language and around all kinds of language quirks 15 years ago, Crockford wrote his book "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else.
Then he made the mess that was YUI at yahoo with the same enterprise patterns. When that failed he went right back to these types of doomsday messages in the media every few years calling for the end of Javascript.
Meanwhile we have seen ES6/typescript/react and countless other innovation take place.
He might be right on some fronts, but at some point its a case of put up or shut up imo. There are far better experts to talk to about the state of JS and its future.