Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript TC39 implementing hashmark private class fields

github.com

Post reply on HN
Print view View original

61–70 of 81 posts

Re: JavaScript TC39 implementing hashmark private class fields

#61

Post by erikpukinskis »

svckr wrote: post #51

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.

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 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?

Re: JavaScript TC39 implementing hashmark private class fields

#62

Post by erikpukinskis »

Andrex wrote: post #46
jorblumesea wrote: post #23

True "Classes" in JS always seemed like a hack anyways. It will never be true OOP, so why shoehorn these concepts into it? Especially given prototypical inheritance patterns we will never have real java style oop patterns. Except for primitives, almost everything is an object, but they are basically hashmaps, not real classes or objects as someone from other languages might think of them. Imo, the language was not bu…

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before. Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

ES2015 classes are not easier to learn for newbies, they're easier to learn for Rubyists and other people coming from OO languages.

There's nothing hard about this:

    function Person(name) {
      this.name = name
    }

    Person.prototype.greet = function() {
      return "Hi, "+this.name
    }

    var me = new Person("Erik")
    console.log(me.greet())
The syntax hurts your brain if you're used to looking at something else, but the control flow is actually very simple and totally transparent, unlike ES6, which does magical things that can't be understood by thinking about where the thread is moving.

Re: JavaScript TC39 implementing hashmark private class fields

#63

Post by hajile »

cromwellian wrote: post #30
BinaryIdiot wrote: post #25

Earlier quoted context omitted.

You could encapsulate them with a closure. They don't _need_ to be exposed.

Does this scale in a large code base? What's the effect on memory and performance of hiding most of your fields by closures?

Closures in JS are basically objects that have only one public property (called apply).

Modern JITs are good at optimizing static objects (provided props are never added or deleted and the types never change). There is still (from what I remember) a small performance increase to normal objects, but it only becomes significant if you are creating hundreds or thousands of them.

I'd say that in typical cases though that closures should be faster because devs tend to use them in ways that are easier to optimize (Closures don't ever add/remove properties and types are much more likely to stay the same).

Re: JavaScript TC39 implementing hashmark private class fields

#64

Post by just_astounded »

erikpukinskis wrote: post #61
svckr wrote: post #51

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.

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 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 concurren…

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".

Re: JavaScript TC39 implementing hashmark private class fields

#65

Post by just_astounded »

dmitriid wrote: post #44
just_astounded wrote: post #14

Earlier quoted context omitted.

I think the concern is that if you look here: https://github.com/tc39/proposal-private-fields/issues/14 and other places, you'll see this massive push back from the community, yet the proposal is moving forward regardless.

Pushback from the community means nothing to TC39. Zilch. Zero. Nada. The only instance of something dropped was cancelable observables. AFAIR it was only because some other group at Google opposed it. Everything else is carried full steam ahead. Enjoy your import() instead of the vastly superior System.loader. Enjoy your hashes as member access specifiers. Dumpster fire. Template literals. BigInts. `new.target`. Dum…

While it hasn't changed their minds, I do see the authors of the proposal actively discussing and engaging with the community. That's better than nothing, I suppose.

Re: JavaScript TC39 implementing hashmark private class fields

#66

Post by jhall1468 »

erikpukinskis wrote: post #62
Andrex wrote: post #46

Earlier quoted context omitted.

You don't need all aspects of OOP ever to get use out of some of its concepts. ES2015 classes are much cleaner and easier for newbies to grok than messing with the prototype chain, which was the way that sort of thing was achieved before. Classes also make a lot of sense for custom elements (Web Components.) See Polymer v1 compared to v2.

ES2015 classes are not easier to learn for newbies, they're easier to learn for Rubyists and other people coming from OO languages. There's nothing hard about this: function Person(name) { this.name = name } Person.prototype.greet = function() { return "Hi, "+this.name } var me = new Person("Erik") console.log(me.greet()) The syntax hurts your brain if you're used to looking at something else, but the control flow is…

There's zero magic. It is literally syntactic sugar and nothing else. Calling that magic is dishonest.

Re: JavaScript TC39 implementing hashmark private class fields

#67

Post by pjmlp »

just_astounded wrote: post #58
kodablah wrote: post #57

Earlier quoted context omitted.

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.

Re: JavaScript TC39 implementing hashmark private class fields

#70

Post by mercer »

just_astounded wrote: post #64
erikpukinskis wrote: post #61

Earlier quoted context omitted.

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 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 concurren…

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 i…

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.
Post reply on HN