Hacker News Reader

Comment by svckr | Hacker News Reader

Wouldn't it be funny if we see a resurgence of compile-to-js languages? If JavaScript keeps on piling up layers I could see people longing for a simpler, smaller language.

Where there was coffeescript to highlight functional features in JS in a time where most JS was imperative, maybe we'll see a language that takes the OO sugar away to, again, reveal the functional language that's underneath.

View on HN

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.

FWIW the arguably ideal target for compile-to-web tech, WebAssembly, is adding some OO too [0].

0 - https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...

Until wasm has GC, we're not likely to see much in the way of compile-to-web outside of C, C++, or Rust.

There is already a .NET prototype.

https://github.com/SteveSanderson/Blazor

https://www.youtube.com/watch?v=MiLAE6HMr10

WebAssembly without native GC support is no different that targeting a real hardware CPU. One just has to implement it as well.

As soon as WebAssembly reaches a more mature state, expect the resurgence of plugins and this time around we won't be able to disable them.

blazor is not .NET compiled to WASM. blazor uses a .NET runtime called DotNetAnywhere, which is written in C and compiled with emscripten. the actual .NET IL is then interpreted at runtime by DNA.

True, but the fact is that people are already toying with the idea of bring such runtimes back into the browser.

Also if you bother to read the meeting minutes from WebAssembly meetings, developers from .NET team are present in such meetings.

Fancy!

Reply on news.ycombinator.com