71–80 of 206 posts
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'?
Instead of HTML, can’t JavaScript just be used to paint the browser canvas? You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. Then you fetch your data, per the page you display, via JSON, and fill in the fields. The initial JavaScript download is heavy, but the normal usage of the web application should be quicker, as you’re only fetching the relevant data to…
> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Yes it can. Qt when compiled to web-assembly does this. It just uses a canvas as a framebuffer basically. [0] Going off on a tangent here. This is something I've been thinking about a lot lately. I wanted to build a cross platform app that also works in the browser. Especially as single developer maintaining multiple codebases just sucks. S…
But, JavaScript is such a poor language, that it’s a poor choice for rigorous software development. However, it is a good candidate for transpiling code to.
I was thinking of bolting on an Lisp type of scripting language, which can transpile down to a rigorous subset of JavaScript, which then controls how the widgets behave in the browser.
This way, the Lisp script can be used to control how the widgets are organized in the browser screen. How each widget gets its data, and how it interacts with other widgets on the screen. Basically, it becomes its own little GUI development environment.
Then over time, a public library of Lisp functions can be made available, and easily integrated into your code, with recommendations on commonly accepted techniques to do something. But if you don’t like that, then you’re still free to reinvent your own new technique.
Then over time, the superior nature of this system, becomes popular enough that the major browser vendors begin integrating the Lisp scripting engine as a first class library. And to improve efficiency, it can cut out JavaScript entirely, and just interact directly with the browser. So the Lisp engine should have the ability to both, transpile down to JavaScript for backwards compatibility, as well as to compile down to bytecodes that can be executed by the browser. This way, all the variant JavaScript ecosystems gets neutralized, since this new system, just sidesteps JavaScript completely. (Wait, I think I just described WebAssembly.)
And then, a new variant of web-Lisp takes over the world.
Excellent..
I agree about the nuisance of creating DOM elements. innerHTML is OK if you’re doing static content, but for anything that needs to be dynamic (untrusted input, event handlers, etc.) I have a little tiny helper library that I carry around in my head and write into projects that need it: const $T = text => document.createTextNode(text) function $E(tag, props, kids) { const elem = document.createElement(tag) for (const…
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) {…
element.classList.has('someClass') //true if present
element.classList.add('someClass') //add to element
element.classList.remove('someClass') //remove from element
element.classList.toggle('someClass') //remove if present, add if not present
Not saying HN should rewrite their JS obviously, just for anyone reading this and wondering if there are native equivalents.
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…
Earlier quoted context omitted.
If I'm not mistaken, she's a systems programmer. More low-level stuff. She's definitely not a frontend/React/vue.js dev, as she says in the article. She's written some excellent articles on lower-level programming. But I agree that VanillaJS is not appreciated by a large number of web developers.
That's because in order to build anything of any remote sophistication, you need a framework, otherwise you are committing to maintaining an unmaintainable spaghetti mess. Just like nobody actually built Windows applications with just the Windows API -- they all used frameworks like MFC or reimplemented those frameworks in-house.
1. Manage subtle browser differences
2. Store and manage reactive state
3. Manage declarative updates
Earlier quoted context omitted.
If I'm not mistaken, she's a systems programmer. More low-level stuff. She's definitely not a frontend/React/vue.js dev, as she says in the article. She's written some excellent articles on lower-level programming. But I agree that VanillaJS is not appreciated by a large number of web developers.
That's because in order to build anything of any remote sophistication, you need a framework, otherwise you are committing to maintaining an unmaintainable spaghetti mess. Just like nobody actually built Windows applications with just the Windows API -- they all used frameworks like MFC or reimplemented those frameworks in-house.