11–20 of 206 posts
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…
It’s a little funny seeing vue/angular/react/whatever people discover vanilla JS. I thought classList, innerHTML, and querySelectorAll were all extremely common knowledge.
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.
More specifically, how JavaScript can do a lot in browser by interacting through the DOM API. The modernization of the DOM API in the last 5 years has done a lot to remove the need for jQuery et al, and has made building the View part of JavaScript apps much more frictionless.
Where can we learn about this “modern JS“? I feel like in some ways I’m learning the old ways, similar to old c++.
If you don't need to support older browsers, you don't even need to use any packaging software (although if you're building a serious app, it's still wise to do so). You can import ES6 modules in vanilla JS, and a modern browser will do the loading for you. Great for quick starts.
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…
This is super super minor but it's JavaScript not Javascript. IMO the camel case makes it look so much better :D
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…
$E is pretty close to React.createElement, which JSX's tags compile to https://reactjs.org/docs/react-without-jsx.html
More specifically, how JavaScript can do a lot in browser by interacting through the DOM API. The modernization of the DOM API in the last 5 years has done a lot to remove the need for jQuery et al, and has made building the View part of JavaScript apps much more frictionless.
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…
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 fill each of the required widgets.
This does sound resource intensive, for computers back in the 1990s, but today’s iPad, iPhone, and modern laptop computers should be powerful enough to handle it.
Or did I just describe some already popular JavaScript framework?