Comment by BiteCode_dev | Hacker News Reader

Comment by BiteCode_dev | Hacker News Reader

I note that all those ecstatic quotes are from executives.

Because the way I remember it, technical people hated it with a passion, from its design to its implementation.

In fact, the most popular JS projects have always been to avoid writing ES5, its DOM API, or depending of one of its implementation:

- scriptaculous: we hate even the basic types, so we monkey patch our own code into it.

- jquery: don't use any of the language paradigms and use ones from Lisp and Haskell. Avoid "this". Don't touch the DOM. In fact, don't code, just make a few calls and pass parameters. And we rewrite the whole damn browser API to avoid incompatibilities.

- GWT: write JS from Java.

- underscore and co: let's rewrite typeof, the equality sign and array manipulation methods. And provide an stdib for god sake.

- coffeescript: we like Python and ruby but must do JS.

- React: HTML in JS now please. And magic DOM. Oh, and prototyping is horrible, lets use classes. And we strongly advice immutability, but do what you please...

- webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages.

- typescript: ok, we were wrong, ES7 is not enough. Not nearly enough. Please make intellisense works.

Now, in 2020, JS is finally not so horrible to work with. You can use map(), () => and "..." and fake namespaces. Which is amazing to access the crazy cool plateforms that the modern browsers and the web are.

So I guess, in a way, this quote from the AOL guy was true.

JavaScript has a very high learning curve. But it becomes great once you are fluent. When manipulating the DOM it kinda sucks that you can't just monkey-path attributes, you have to use el.setAttribute. The DOM is also very slow. But the DOM do a lot of work - ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.

> The DOM is also very slow.

https://news.ycombinator.com/item?id=22391509

> I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.

I guess not much has changed in 25 years. Most developers still fear the language, have no idea how it works, and will do everything in their power to pretend this language is some other language.

> ever tried to make your own UI framework from scratch only using low level GUI calls? z-index, styling with CSS, screen-reader support, etc.

https://news.ycombinator.com/item?id=22321333

I meant creating a GUI from scratch. Creating a GUI using the DOM is easy. Working with the DOM overall is simple. What I mean is that the DOM do so much work for us (that we take for granted).

What I mean by slow is for example adding a element to the screen, or updating some text. Compared to for example everything that happens on the screen in a 3d game.

I do everything using vanilla JS and I cannot understand why anyone would use a web framework, (although most web project does). I do however have a vague memory that the learning curve was fairly steep, as I have been working with vanilla JS for over 20 years. (whereas the average developer has only used JS for one year) it wasn't until I started to use JS full stack (with Node.JS) that I started to like it!

I worked with vanilla JS for some time (before Prototype.js or jQuery existed) and used a bunch of incantations of different libraries and frameworks over the years and I cannot understand why anyone would choose to use JS for platforms where you can use any other language (aka... any platform that isn't a browser).

No construct or design decision of JS is better than in other languages, the lack of a basic standard library hurts a lot. Dependency management was inexistent until recently, the same for a lot of basic constructs, data types and other utilities that should be baked into any modern language.

The current landscape of JS is so convoluted and with such a varying level of quality that is intractable for me just trying to get things done without getting into the community and everything around it, it's not an easy tool to use and it's not an ergonomical one.

I have used JS for the past 15+ years for different kinds of software and I dislike it, not intensely but I'd never choose to work solely on JS. Yes, you can be productive in it but there are much better tools for most of the job it does around, its only power was to be the only language you could use to script a browser and I hope that WASM kills that.

JavaScript has taught me that there are only two things separating a novice programmer from an excellent programmer: writing and data structures.

In order to improve as a programmer over the years I have had to learn to improve my writing. This requires a clear vision before putting keys on a keyboard and a solid sense of organization. You should know what you are going to work on with a strong confidence on how to go about it before doing any of the actual work. Sure rough spots will emerge along the way, but that shouldn't stop you from solving for the original vision. Then once the original vision is achieve refactor, debug, and refactor again. In writing that is call drafts and second opinions. This applies to any programming language equally.

A confidence of data structures is also critically important. Once skills and conceptual mental modeling of data structures becomes as common as spelling your name algorithms and logic almost write themselves. JavaScript does some things right by providing simplified data structures (objects, arrays, sets, maps, and such) and is really expressive in how you use them. JavaScript also does a lot wrong in this regard with its loose typing and some of its sloppy conventions. Fortunately, TypeScript interfaces coupled with consistent use of strict type declarations close many of those gaps.

---

I have heard so much hope for WASM killing JavaScript over the last 3 years, and almost all of it based on ignorance of how the technologies work. So much of this hope hinges on the availability of the page's DOM to a WASM instance by people who have never written to the DOM and have no idea what they are really asking for. While the WASM working group says this will never happen I suspect that very simple technology reasons will get in the way first regardless of what anybody wants.

If, however, WASM does replace JavaScript because the page's DOM becomes available to a WASM instance I suspect it will be the same clusterfuck that those developers were hoping to replace. I suspect if those developers couldn't figure out the relationship-oriented tree structure of the DOM using JavaScript they fail all the same when using their favorite language.

I can understand replacing JavaScript for other reasons, but rarely (extremely rarely) are the well grounded reasons ever a primary motivation for wanting JavaScript replaced.

I've just began to learn ES5 and ES6. I've compiled a small list of JS quirks, things that I'd take for granted because they're well stablished in other high level programming languages. For instance, 'for/in' picks the keys instead of the values of either array or dictionary ( object in JS terms I think), dictionary doesn't have a keys 'method' but you can call Object.keys for that functionality, arrays are key/value indexed, so array['a']=1 is valid, and so on. I've lost a little while just laughing when I learned about how ES5 does OO.

JS oftentimes reminds of Apple: there's the industry standard or some already well stablished way of doing things, and they go like "Well, flip it. We're doing our own way, just because".

I don't understand the comparison between jQuery and lisp/Haskell, can you elaborate?

For Haskell, when doing:

    $("foo").stuff().bar().res()

jQuery feels like the list monad, if you see chaining as similar to bind and $() not so far from return.

And for Lisp, jquery provided error handlers instead of relying on native try/except.

Of course, it's more inspired from it than the real thing, but it's far from any JS paradigm of the time. Remember that JS didn't even have map() and the only place you used your first class functions was to setInterval. Plus the joke is funnier that way :)

You didn't even need first class functions for setInterval. setInterval also accepted a string!

Wow, I just tried:

    setInterval('console.log(1 + 1)', 1000);

And it works. It's a big eval().

Stealing this for my next JS training, beginners always have a hard time with callbacks, so it's a good first step to actually explain the benefits of callbacks.

Why would you direct new comers attention to eval'esque functionality? They should stay far far away from it. Come to think of it, everyone should stay away from eval functionality!

Because students can understand "code being run every x seconds" easier than "reference to function being resolved then called every x seconds".

Once they do, you show the problems with it and show why callbacks are better.

When it comes to pedagogy, I'll use every trick I can.

And I always win.

I feel like you could start with manually calling the function, and then introduce callbacks as a way to get your code to run in response to some event. A callback is no different to a regular function after all.

If your way works, then it works though I suppose.

Agreed. In my class I always start with the hard/wrong way. Point out why it's hard/wrong. Let them hate it. Then show the easy/correct way. You can't just point them at something and say, "Do it this way or else." That's not teaching. That's directing.

What do you do when they decide that they prefer the wrong way? Eval is pretty compelling to beginners!

I suggest that, if possible, try to set up a cheap server on a DO droplet or somewhere with a built in amount of latency and use that in your presentation.

When I was learning callbacks I saw people use the "setInterval" example and while it did help to an extent, the real world implementation still left a good deal to be desired.

Method chaining (aka. fluent syntax) is not really comparable to bind. Bind is nested lambdas, which means an operation might be executed zero or multiple times depending on the bind. In method chaining, each call will be executed exactly once, unless an exception is thrown.

The use of method chaining in jQuery is cool, but it is not very similar to Haskell.

> which means an operation might be executed zero or multiple times depending on the bind.

That's what the jQuery API does behind the scene of the chained calls. That's one of the key reasons of its success actually.

$(".foo").foo().bar() will execute n times, for each of the n DOM elements you matched with ".foo", including one or zero.

No, foo() and bar() will each execute once, but the methods performs some underlying operation on each item in the underlying collection.

Yes this is a cool and useful pattern, but it is not bind. It is just a different thing.

In JS speech, I said "==", and you said "!==".

> - webpack and babel: ES6 and 7 are not here yet, but ES5 is so bad we will setup an entire ecosystem dedicated to make believe they are. Also pretend import works like in other languages.

They just peeked over at their low level programming neighbours and realized what they did to avoid programming assembly and program C instead was a smart idea.

Are you okay?

Reply on news.ycombinator.com