Live data from Hacker News

A little bit of plain JavaScript can do a lot

jvns.ca

61–70 of 206 posts

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

#61
post #33

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.

> in order to build anything of any remote sophistication, you need a framework

Sure. But does the project/requirement described in the original article sound particularly sophisticated?

I note that HN loads less that 150 lines of js and no framework. While there's an argument to be made that this place's frontend code is "not remotely sophisticated", it without doubt provides a huge amount of value anyway.

While I agree with everybody here about the requirements for good frameworks (and good development practices) for complex or sophisticated web applications, to me at least it's abundantly clear the author of the article made the correct choice for her problem domain.

Some things should resist every effort to make them more complex or more sophisticated than they need to be. Most things probably.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery

I strongly believe that, while he did not know it at the time, he was totally talking there about lines of code.

Bill Atkinson clearly took that philosophy to heart:

"He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000."

from: https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

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

#62
post #57

Earlier quoted context omitted.

As a React developer I have the strictest policy to never go lower level than the browser and I never touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.

>> it feels close to the metal > never go lower level than the browser So maybe "close to the DOM" rather than "close to the metal"? :-) On the other hand, if you ever want a project to get you out of your comfort-zone(/rut?) - check this out: https://www.espruino.com/ You _can_ go "bare metal" and still use your hard won javascript skills... > I started my computing career in 1986 knowing only React That's a big gap…

> That's a big gap in your memory between 1986 and when React was first released in 2013. Or _maybe_ 2010 or 2011 if you were working inside Facebook back before they released it publicly...

You do realize why you're being downvoted, right? :D

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

#63

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. So the only real option seems to be to write it as a webapp. So I started, but personally, I just really can't stand the JS ecosystem.

I basically see two ways here this could go. Either the we go the use-canvas-as-framebuffer route. Or we'll need small embeddable html/css engines so you can write your code once in your preferred language, where for native apps you access the engines DOM directly, and when compiled to WASM it 'syscall's it out to JS see e.g. go [1]

Basically something like sciter[2].

[0] https://www.qt.io/web-assembly-example-slate

[1] https://www.godoc.org/syscall/js

[2] https://sciter.com/

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

#64
post #44

Nice work! The only advice I’d give is don’t use patterns like div.parentElement.parentElement.foo() It’s inflexible and will break if you ever make dom changes. Use the .closest() selector instead. It’s like a reverse .querySelector (.closest selects ancestors, .querySelector selects descendents) which means you’ll have more specific code.

TIL about .closest!

From the article.

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

#65

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 feels close to the metal. Please tell me you're joking?

The web will be very close to metal in five years. Google is working on it.

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

#66

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…

A bit more minified/modern version of this that I'm using:

    function $e(t='div',p={},c=[]){
      let el=document.createElement(t);
      Object.assign(el,p);
      el.append(...c);
      return el;
    }
    
    var $t=document.createTextNode.bind(document);
That's 173 bytes not minified, might be useful for someone.

Interestingly, the function names are exactly the same - I guess people think similarly :-)

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

#68

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…

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...

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

#69
post #52

Earlier quoted context omitted.

Pretty much this. I knew all of the things she wrote about but all I could think was "I can't imagine writing foo.classList.add and remove 100 times. That's going to create some major spaghetti code once that project grows beyond a couple of pages"

There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use the same HTML to generate both a PDF (with Prince) and to make an interactive version of the questions." Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. At the same time, reachi…

> reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision.

Do people really do that? To me, that reflects bad frontend engineering practice. Even so for something like that, I'd use jQuery or something similar, because it's a much nicer API than the DOM.

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

#70
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) { var a = el.className.split(' '); return afind(cl, a) }
    function addClass (el, cl) { if (el) { var a = el.className.split(' '); if (!afind(cl, a)) { a.unshift(cl); el.className = a.join(' ')}} }
    function remClass (el, cl) { if (el) { var a = el.className.split(' '); arem(a, cl); el.className = a.join(' ') } }
    function html (el) { return el ? el.innerHTML : null; }
    function attr (el, name) { return el.getAttribute(name) }
    function tonum (x) { var n = parseFloat(x); return isNaN(n) ? null : n }
    function remEl (el) { el.parentNode.removeChild(el) }
    function posf (f, a) { for (var i=0; i = 0) ? a[i] : null; }
    function acut (a, m, n) { return Array.prototype.slice.call(a, m, n) }
    function aeach (fn, a) { return Array.prototype.forEach.call(a, fn) }
    function arem (a, x) { var i = apos(x, a); if (i >= 0) { a.splice(i, 1); } return a; }
    function alast (a) { return a[a.length - 1] }
    function vis(el, on) { if (el) { (on ? remClass : addClass)(el, 'nosee') } }
    function noshow (el) { addClass(el, 'noshow') }
    function elShow (el) { remClass(el, 'noshow') }
    function ind (el) { return (byTag(el, 'img')[0] || {}).width }
https://news.ycombinator.com/hn.js
Post reply on HN