Live data from Hacker News

A little bit of plain JavaScript can do a lot

jvns.ca

151–160 of 206 posts

Re: A little bit of plain JavaScript can do a lot

#151

An interesting use of 'classList' is that it makes it easy to use css-classes to indicate the state of a dom-element. Is the element selected or not? Well does its classlist include the css-class 'selected'?

Do not use classes to mark something as selected. People using screen readers won't know whether something is selected. Use aria attributes like aria-selected instead.

https://www.w3.org/WAI/PF/aria/states_and_properties#aria-se...

Re: A little bit of plain JavaScript can do a lot

#152

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal. It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti. I also craved the ability to write small simple functions for making components. And I wan…

It seems like WebAssembly will allow high level languages to get close to the "browser metal", so I think we will see declarative frameworks that are closer to the metal compared to React. I'm wondering if Rust is the best language to learn to get a headstart on that.

Re: A little bit of plain JavaScript can do a lot

#153
post #141

Earlier quoted context omitted.

If you're a front-end only developer not only do you use the same hammer (big framework) for all nails, the use of that hammer is what gives you job security and satisfaction. If companies switched to using old fashioned server-rendered pages with light JS, half of HN would not have anything to do at work.

For the first year, anyway. If the project continues to grow, next year they would be called to deal with the enormous spaghetti mess that has resulted.

It’s as if everyone forgot why we moved presentation logic to the same place and why we favor declarative programming over DOM mutations. When you render is completely orthogonal to that.

Re: A little bit of plain JavaScript can do a lot

#154

Earlier quoted context omitted.

> it feels close to the metal. Please tell me you're joking?

Cmon. Close the the "browser metal". I of course don't mean close to the CPU that would be silly.

"Close to the Chrome"

Re: A little bit of plain JavaScript can do a lot

#155

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal. It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti. I also craved the ability to write small simple functions for making components. And I wan…

> I enjoy plain JavaScript, it feels close to the metal

Never thought I'd hear the day...

Re: A little bit of plain JavaScript can do a lot

#156
post #94

Earlier quoted context omitted.

And now we witness everyday spaghetti code written on the top of some framework and each noodle is wrapped five times in a needless abstraction. There is nothing preventing you to write nice and clean code in plain JS.

Yeah no shit. JS is the only community I've seen where code size scales with dependency count in the positive direction. It's ridiculous.

[deleted]

Re: A little bit of plain JavaScript can do a lot

#157

When starting to learn/write JS, I found a few of these basic name-shortening functions from HN's own JS very useful, and well-named: function $(id) { return document.getElementById(id); } function byClass (el, cl) { return el ? el.getElementsByClassName(cl) : [] } function byTag (el, tg) { return el ? el.getElementsByTagName(tg) : [] } function allof (cl) { return byClass(document, cl) } function hasClass (el, cl) {…

You might be interested in bling.js: https://gist.github.com/paulirish/12fb951a8b893a454b32

I was similarly inspired:

    if (undefined === window.$) {
        window.$ = document.querySelectorAll.bind(document);
        [EventTarget.prototype, window, XMLHttpRequest.prototype].forEach(function setOnOff(p) {
            Object.defineProperty(p, "on", {
                get() {
                    return function onElement(t, f) {
                        this.addEventListener(t, f);
                        return this;
                    };
                }
            })
            Object.defineProperty(p, "off", {
                get() {
                    return function offElement(t, f) {
                        this.removeEventListener(t, f);
                        return this;
                    };
                }
            });
        });
        [NodeList.prototype, HTMLCollection.prototype].forEach(function setOnArray(p) {
            Object.setPrototypeOf(p, Array.prototype);
            Object.defineProperty(p, "on", {
                get() {
                    return function onArray(t, f) {
                        this.forEach(function onEach(e) {
                            e.addEventListener(t, f);
                        });
                        return this;
                    };
                }
            });
            Object.defineProperty(p, "off", {
                get() {
                    return function offArray(t, f) {
                        this.forEach(function offEach(e) {
                            e.removeEventListener(t, f);
                        });
                        return this;
                    };
                }
            });
        });
    }

Re: A little bit of plain JavaScript can do a lot

#158

When starting to learn/write JS, I found a few of these basic name-shortening functions from HN's own JS very useful, and well-named: function $(id) { return document.getElementById(id); } function byClass (el, cl) { return el ? el.getElementsByClassName(cl) : [] } function byTag (el, tg) { return el ? el.getElementsByTagName(tg) : [] } function allof (cl) { return byClass(document, cl) } function hasClass (el, cl) {…

> well-named

They look useful to me, but I personally think they aren't so well-named; excessively concise for my taste.

Re: A little bit of plain JavaScript can do a lot

#159

Earlier quoted context omitted.

Not nearly as minimal as your example, but I like the "no build tools route" of using preact. You don't need to build your code, and you can get JSX-esque syntax and some of the niceness of React without messing with npm or webpack or any of that. https://preactjs.com/guide/v10/getting-started#no-build-tool...

I am failing to understand why someone would choose this over React. The page you linked to, I kid you not, has a section about how you build a Preact application from the command line...

I linked to the "no build tools route":

> Preact is packaged to be used directly in the browser, and doesn't require any build or tools

Re: A little bit of plain JavaScript can do a lot

#160

Earlier quoted context omitted.

You just spent three paragraphs describing how NodeList is different, including a reference to a non-existent operator. Nice.

Well, you called it a "weird object" that throws errors if you "look at it funny." They tried to demystify it for you in just three sentences. That jQuery lets you willfully cling to the corpse of familiarity instead of spending 30 seconds looking up what NodeList was years ago says more about you than anything about jQuery. And with your end-cap comment about the pipeline operator that they were already, helpfully,…

> Well, you called it a "weird object" that throws errors if you "look at it funny." They tried to demystify it for you in just three sentences.

I never said it was mysterious to me. I described it as concisely as possible. It is an object that has a grand total of two array-like methods (and it took the standards bodies two years to add forEach to it). And it does throw an exception on invalid input.

So, to work with it without hassle, guess what, you'll have to recreate that "corpse of familiarity" from jQuery: throw an Array.from at it, and wrap it in a try-catch.

And that is true for every single improvement to the DOM API. If you look at all the efforts to get rid of jQuery, you'll see people re-implementing half of it for one simple reason: all the improvements are still stunted, underdesigned, and need quite a lot of additional boilerplate to make it useable in any hut the simplest scenarios. (Notable exception: classList. It weirdly behaves and works the way that doesn't screw up developer experience).

> And with your end-cap comment about the pipeline operator that they were already, helpfully, pointing out was going to be introduced in the future, you just sound like sour grapes. What gives?

The pipeline operator proposal has been there for three years. Excuse me for not jumping with joy when someone quips that there will be no difference between arrays and NodeLists in some glorious future. I prefer reality.

Post reply on HN