Comment by erikpukinskis | Hacker News Reader

Comment by erikpukinskis | Hacker News Reader

Parent Full thread

I am absolutely planning on forking an old school JavaScript off of the current runtimes. Or at least forking NPM. Not soon, because for now writing ES5 and running it on ES6 runtimes is Good Enough for my current purposes, as I'm still <1.0.0 so nothing really matters. But eventually I'm going to want a separate package space, and a separate language community.

Modern JavaScript is cool, but it loses many of the benefits of old school JS:

- only runs on newer devices

- requires a precompile step

- more language to learn

- confusing concurrency model

- confusing inheritance mechanisms

- no incentive to learn to use closures, callbacks, and prototypes properly

If I was willing to accept all of those things, I would just use a straight up better language, like Rust or Haskell, and get the additional benefits of type checking and deterministic performance.

But I'm not interested in those things. I want a simple run-everywhere language for beginners to get started on. JavaScript used to be that, but modern JavaScript is not that language anymore.

So, I'm going to bring back ES5. Why not. Who's with me?

I remember when Crockford released the fantastic book, JavaScript The Good Parts. I disagreed with some of his opinions in that book, like avoiding the use of 'new', but that book - more than almost anything else, helped me educate folks on how to use js well. I used to order copies for every member of my team. I wonder if, instead of a fork, we can just make a case for a subset of js. Take the good new things, and ignore the rest, like a modern "Good Parts".

Could you elaborate on the things you disagreed with? For example, for some reason I prefer avoiding new but I'm conflicted about it. I'd really like to hear your input as to why perhaps using 'new' is a good thing.

Not OP, but new is dangerous because it makes it easy to put a lot of methods on an object, which is generally an anti-pattern.

But sometimes that's what you want. I think a good use case is view models... You're not mutating anything, but you have a large number of consumers that are using different subsets of views on a piece of data. Constructing those by hand can be a PITA.

Although, it's dangerous there. "Lots of views on a piece of data" might be a way of covering up "several disparate pieces of data in one place" or "data that is playing two roles when it should be transmuted instead". So, it's good to be afraid of new.

I am still frequently decomposing a single index of objects into separate indexes of literals fairly often. I often get sucked into thinking something is an object when it's really just a few separate pieces of data indexed together.

I also use new for libraries that export something that isn't exactly a function, but more a point of reference. For example my browser-bridge module is a point of reference for the computation between a web request and response. It's not really an action, but it's a thin representation over a handful of low level things you want to do in that space. It's purpose is to wrap up a set of concerns.

Essentially, OO is generally bad in JavaScript, but sometimes it's good and in those cases new is nice.

There are a lot of reasons, honestly, and it's great beer conversation, but from a high level: producing a concrete instance that invokes a constructor function with a shiny pristine 'this' to build on is a pretty great pattern. Add the ability to muck about with clever prototype manipulation, and you have pretty enormous power - you can do everything that classic OOP can do (if that's your thing) and a lot more.

Reply on news.ycombinator.com