Live data from Hacker News

The JavaScript ecosystem is delightfully weird

fly.io

231–240 of 248 posts

Re: The JavaScript ecosystem is delightfully weird

#231

Earlier quoted context omitted.

Are you really trying to say people couldn't build complex apps before TypeScript? I know of hundreds of examples that were made before TS... Complex apps still had lots of tests, which basically solve the same problem as TS is trying to address, without having to write a different language than what gets run by the browsers.

How would you compare the overhead of writing tests un JS to the overhead of doing proper TS? Obviously tests are still useful in TS, but not as many I think. Also, the feedback loop of a static type system is, IME, much faster than with tests only.

I end up having the same amount of tests in JS as in TS. I'm not really testing that the types are correct, but that functions work correct. So just because you're writing JS, doesn't mean that everything you would assigned types to in TS, you now write a unit test for itself.

And my editor does the autocomplete thing seemingly just as well as the autocomplete I get from TS, even when I just write JS code normally.

Re: The JavaScript ecosystem is delightfully weird

#232

Earlier quoted context omitted.

The class keyword is just syntactic sugar. JS still uses prototypal inheritance. Nothing has changed. Check out objectplayground.com for details.

Not ‘nothing’ has changed. Classes are supposed to be syntactic sugar over constructor functions, but the later could be invoked as well as instantiated with the ‘new’ keyword, whereas the interpreter will error out on you if you attempt to invoke a class. That is fine though, I don’t care for constructor functions. I was talking about using metaobjects, a different concept altogether.

Okay, I think I get your complaint. JavaScript doesn’t have a metaobject protocol, but there were a variety of user-land approaches to OOP that added one. Although they’re still technically possible, the class syntax formalized a non-MOP approach to OOP, and those third-party tools have all fallen by the wayside.

It’s not so much that you can’t use a MOP in JS, so much that people don’t, and will look at you funny if you do.

As a lover of simple and straightforward code, I never used the MOPs—I hand-coded “class.prototype.method = function()” like God intended*—and I’m happy the standard uses that more traditional approach. But I can see how someone who did use a MOP would feel that the class syntax is a step backwards.

*that’s a joke.

Re: The JavaScript ecosystem is delightfully weird

#233

Earlier quoted context omitted.

Not ‘nothing’ has changed. Classes are supposed to be syntactic sugar over constructor functions, but the later could be invoked as well as instantiated with the ‘new’ keyword, whereas the interpreter will error out on you if you attempt to invoke a class. That is fine though, I don’t care for constructor functions. I was talking about using metaobjects, a different concept altogether.

Okay, I think I get your complaint. JavaScript doesn’t have a metaobject protocol, but there were a variety of user-land approaches to OOP that added one. Although they’re still technically possible, the class syntax formalized a non-MOP approach to OOP, and those third-party tools have all fallen by the wayside. It’s not so much that you can’t use a MOP in JS, so much that people don’t, and will look at you funny if…

Yes, this is it. The MOP approach basically involves using ‘Object.assign’ to instantiate new objects from the metaobject. It is quite straightforward in my opinion, but that is relative I suppose. I don’t know if this is true but I’ve been told that Brendan Eich intended for this exact approach to be the one and true OOP in JS, but was persuaded by his boss to implement constructor functions to make it more like Java.

Re: The JavaScript ecosystem is delightfully weird

#234

Earlier quoted context omitted.

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail f…

I got quite used to the prototype inheritance style Javascript and really liked it. But I don't think it scales across teams as well as modern JS or Typescript. But for a small project with just myself or a few other skilled developers? I'd prefer old-school style JS semantics.

Yeah, I have some fondness for it myself, even despite listing some of the headaches I recall from past efforts. The fun/interesting/good news is that it is not technically an either/or in JS. Prototypes are still the underlying driver below the class syntax. There's absolutely still room for doing really interesting or cool things with prototypical inheritance, even doing things that aren't entirely possible with the class syntax, and then wrap them up in a cool library and make them interoperable with class syntax for all the downstream users. (Interop with the class syntax is still a useful design target.) The hardest parts of such "cool" library ideas is just likely getting the Typescript types correct with them. (Typescript doesn't quite model all the possible intricacies of prototypical inheritance, in my experience.)

Re: The JavaScript ecosystem is delightfully weird

#235

Earlier quoted context omitted.

Okay, I think I get your complaint. JavaScript doesn’t have a metaobject protocol, but there were a variety of user-land approaches to OOP that added one. Although they’re still technically possible, the class syntax formalized a non-MOP approach to OOP, and those third-party tools have all fallen by the wayside. It’s not so much that you can’t use a MOP in JS, so much that people don’t, and will look at you funny if…

Yes, this is it. The MOP approach basically involves using ‘Object.assign’ to instantiate new objects from the metaobject. It is quite straightforward in my opinion, but that is relative I suppose. I don’t know if this is true but I’ve been told that Brendan Eich intended for this exact approach to be the one and true OOP in JS, but was persuaded by his boss to implement constructor functions to make it more like Jav…

That'd be a little weird if that was Eich's "original vision" considering `Object.assign` didn't come out until ES6. Which was also when the `class` keyword was introduced.

Re: The JavaScript ecosystem is delightfully weird

#237

I started writing a small static site generator for myself using JavaScript and QuickJS by Fabrice Bellard[1]. QuickJS is not quite complete, and there are some cross-platform inconsistencies, but overall I found it pleasant to use and its libc wrappers to be powerful enough. I also found that JavaScript is actually pleasant to use when I'm not using classes, or dealing with metaprogramming/Babel, or implicit globals…

what's the use case for quickjs? can it be used for a light-weight runtime for JS on resource restricted embedded devices? by the way, comparing to angular and vue2-vue3, react is actually the one without python2-python3-alike breakages over the years to me, I would say it's the best out of the 3 options(angular,vue,react) so far, which could explain by market share that it remains to be dominant.

Yeah, the QuickJS interpreter is less than a megabyte compare to Node/Deno's >60MB or more install. My use-case was that I wanted something lightweight that I can run on lower-end hardware or in a CI pipeline to generate my site. At first I looked at bash, but I find bash gets unwieldy for more complex operations. I like JS as a scripting language, and QuickJS seemed to fit my YAGNI approach.

Indeed, React the library is generally stable. But React the ecosystem is not; best practices change every 6 months. Libraries gain popularity and then are abandoned, or people just realize the cost of using them. SSR vs SPAs? Wait you're telling me CRA is basically deprecated now? etc etc.

Re: The JavaScript ecosystem is delightfully weird

#238

Earlier quoted context omitted.

> created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. Well... C# .Net developers, as Microsoft found, correctly, that you can't build complex products easily with a lack of types. I also don't think many program in vanilla Javascript; it seems everyone is using JSX.

Are you really trying to say people couldn't build complex apps before TypeScript? I know of hundreds of examples that were made before TS... Complex apps still had lots of tests, which basically solve the same problem as TS is trying to address, without having to write a different language than what gets run by the browsers.

> Are you really trying to say people couldn't build complex apps before TypeScript?

I said easily. Types remove whole categories of errors.

I think the industry has generally found dynamic typing to be a mistake. Most dynamic languages are now trying to retrofit types.

Re: The JavaScript ecosystem is delightfully weird

#239

Earlier quoted context omitted.

Yes, this is it. The MOP approach basically involves using ‘Object.assign’ to instantiate new objects from the metaobject. It is quite straightforward in my opinion, but that is relative I suppose. I don’t know if this is true but I’ve been told that Brendan Eich intended for this exact approach to be the one and true OOP in JS, but was persuaded by his boss to implement constructor functions to make it more like Jav…

That'd be a little weird if that was Eich's "original vision" considering `Object.assign` didn't come out until ES6. Which was also when the `class` keyword was introduced.

Good catch. It’s been a while since I’ve been thought the ways of old JS so I’m misremembering. It’s all apocryphal anyhow.

Re: The JavaScript ecosystem is delightfully weird

#240
post #87
post #61

Earlier quoted context omitted.

Something something pnpm, yarn, jfrog

I believe they don't have registry or independent mirrors. Which CLI tool isn't that important.

https://jfrog.com/help/r/jfrog-artifactory-documentation/npm...
Post reply on HN