Hacker News Reader

Comment by alexkavon | Hacker News Reader

> I'm not a fan of the class keyword either, but to each their own. I think it obscures understanding of modules and prototypes just so that ex-Class-based OOP programmers can feel comfortable in JS

I couldn't agree more. Classes were implemented so that JS haters could write syntax they wanted to and not to improve the language per say. Seems like JS is entering an age of cruft.

View on HN

While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book.

It's only in the last few years that the majority have stopped trying to recreate Java in JS. (I don't think the majority of PRACTITIONERS were doing this, but the majority of INSTRUCTORS were, causing a lasting problem until enough people willing/able to teach were grown within the community.

Agreed. I think JS is quite a broken language that should probably be replaced. It won't be, but it probably should. I know Google thinks Dart could be that language but they're not even trying to put the VM into Chrome, so it's just another replacement that needs to be compiled.

I was complaining about some JS stuff (particularly the required writing of "use strict") in the #nodejs freenode irc chat the other day and someone asked me a way to help solve these issues without breaking 50 year old code. Thinking about it, I think a good attempt would be to create an HTML meta tag that would tell the browser to parse all JS in strict mode. Maybe there's something already out there. This is already possible in nodejs, but browser side I think it could be a big help in moving things forward.

Down-voters should be required to respond if they're going to down-vote. Too often is conversation halted by negative people on HN.

Isn't that basically what we did with doctypes? HTML has a lot of similar issues and it has slowly managed to move forward. The real benefit was not having to mix old and new code and getting rid of all the quirks by requiring you specify that you want them if you want that old doc to work.

JavaScript could get to the same place just be letting you specify a different language in the script tag.

The big question is how we support legacy browsers for a time because many won't support the new keywords.

A script type could work too. Either way, there would be some indicator of how the JS VM could parse the code. It's true you could get other languages into HTML this way as well, but the trick is that the browser needs to support the VM, which can be done natively or through a browser plugin/extension. Google tried this for a Dart VM (sidenote: there is no TypeScript VM from Microsoft that I'm aware of) into Chrome but discussions led away from that idea, and now Dart compiles to JS instead. A <meta> tag in <head> would eliminate <script type="application/sjavascript"></script>, <script type="application/sjavascript"></script>, etc. Though providing an either/or situation would be optimal too to allow a mixed script types for older libraries.

isn't that what <script type="module"> is for? it does "use strict" automatically

> While I am also not a fan of the class keyword, I'd argue that we already had that age of cruft. For quite a few years (past decade?) practically every book on JS would start with the author building their own version of inheritance, and then relying on it throughout the rest of the book.

This, right here. The class keyword is unfortunate, but at least it ends the useless meta discussion of "how to implement classes" by simply providing some sugar over the RightWayToDoIt(tm). (According to those in the know – whatever, I don't care for classes.)

Reply on news.ycombinator.com