3 ms·

AFAIK (I'm not a front-end dev but tried some) vanilla JavaScript has much of the things jQuery provided built-in nowadays yet they look much longer. Now as Ja

AFAIK (I'm not a front-end dev but tried some) vanilla JavaScript has much of the things jQuery provided built-in nowadays yet they look much longer. Now as JavaScript accumulated a lot of legacy stuff only kept for compatibility + also numerous verbally/syntactically sub-elegant APIs IMHO it is time to design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences so it would be very easy to transpile by just string replace/mapping, essentially just a lightweight "syntactic sugar+discipline" layer. Then it can be integrated in browsers directly.

Gigachad 4y ago
The future will probably be that anything complicated enough to require frameworks like React will eventually move to web assembly, then you are free to use a newer language or compiler which strips out legacy mistakes and old sites can keep shipping their binary which will always work. Already a few of the complex web apps have become webasm.
cies 4y ago
> design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences JS' problem is that it is fundamentally not "clean, modern and elegant". It was designed in a couple of days. And all the greatness that's added to it nowadays is done in a much better design process than at it's inception, yet some choices made at it's inception can never be reversed. I've written some Elm and think it is phenomenal at being a better JS; but it fundamentally very different. Rotten fundamentals are notoriously hard to fix; especially when a lot has been built on top and needs to keep running.
- qwerty456127 4y ago
  AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
  - cies 4y ago
    Same C programmers sometimes use assembly. The abstraction is leaky. I agree it's not a clean superset like TS is, but for the app I wrote I did not have to use any JS except in instantiating the app (3 lines iirc).

Gigachad 4y ago

The future will probably be that anything complicated enough to require frameworks like React will eventually move to web assembly, then you are free to use a newer language or compiler which strips out legacy mistakes and old sites can keep shipping their binary which will always work. Already a few of the complex web apps have become webasm.

cies 4y ago

> design a language which would simply be "better JavaScript" - clean, modern and elegant yet have no fundamental differences JS' problem is that it is fundamentally not "clean, modern and elegant". It was designed in a couple of days. And all the greatness that's added to it nowadays is done in a much better design process than at it's inception, yet some choices made at it's inception can never be reversed. I've written some Elm and think it is phenomenal at being a better JS; but it fundamentally very different. Rotten fundamentals are notoriously hard to fix; especially when a lot has been built on top and needs to keep running.

qwerty456127 4y ago
AFAIK Elm can not be considered "a better JavaScript" because it not only is fundamentally different, it also is not fully self-sufficient - in many cases you have to resort to JavaScript pieces while engineering an Elm app.
- cies 4y ago
  Same C programmers sometimes use assembly. The abstraction is leaky. I agree it's not a clean superset like TS is, but for the app I wrote I did not have to use any JS except in instantiating the app (3 lines iirc).