3 ms·

No. Javascript should be split into 3 languages and html and css should be split into 20 languages. Seriously frontend is already the most fragmented and fast

No. Javascript should be split into 3 languages and html and css should be split into 20 languages. Seriously frontend is already the most fragmented and fast changing area of web there is. Don’t split the language.

ttoinou 2y ago
You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.
- ninetyninenine 2y ago
  Yeah but if I change jobs or work on another project then I’d have to learn two standards.
  - loftyal 2y ago
    Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.
    - ninetyninenine 2y ago
      Need to learn both because I still need to know what is sugar in order to use the subset.
bitwarrior 2y ago
You didn't read the article.
akira2501 2y ago
> and fast changing area Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.
- wiseowise 2y ago
  > Who cares? I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.
  - akira2501 2y ago
    I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be. Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.
    - wiseowise 2y ago
      > The existence of new language features has not forced me to adopt them. You still need to be aware of them when you encounter unfamiliar syntax.

ttoinou 2y ago

You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.

ninetyninenine 2y ago
Yeah but if I change jobs or work on another project then I’d have to learn two standards.
- loftyal 2y ago
  Did you read the article? The sugared JS would be a superset of the target JS. So you would only need to learn the sugared.
  - ninetyninenine 2y ago
    Need to learn both because I still need to know what is sugar in order to use the subset.

bitwarrior 2y ago

You didn't read the article.

akira2501 2y ago

> and fast changing area Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.

wiseowise 2y ago
> Who cares? I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.
- akira2501 2y ago
  I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be. Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.
  - wiseowise 2y ago
    > The existence of new language features has not forced me to adopt them. You still need to be aware of them when you encounter unfamiliar syntax.