Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A little bit of plain JavaScript can do a lot

jvns.ca

Post reply on HN
Print view View original

141–150 of 206 posts

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

#141

Post by spion »

peruvian wrote: post #131
userbinator wrote: post #24

I’ve never worked as a professional frontend developer, so even though I’ve been writing HTML/CSS/JS for 15 years for little side projects, all of the projects have been pretty small I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is not web development often make better sites/pages than "professional" developers. I once rewrote,…

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.

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

#142

Post by 6510 »

peruvian wrote: post #131
userbinator wrote: post #24

I’ve never worked as a professional frontend developer, so even though I’ve been writing HTML/CSS/JS for 15 years for little side projects, all of the projects have been pretty small I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is not web development often make better sites/pages than "professional" developers. I once rewrote,…

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.

right, i only do vanilla: sites are finished fast and they just work. not someone any one would hire. people are really used to frameworks. it would be a step back for them.

>In one place I wanted to change a button’s HTML contents.

if you know what the hidden elm is going to contain you can just add the html to the page as a hidden elm. if it can have 2 states you can also add both nodes as html. just show only one at a time.

the and the are always children of i would target them as such, no need to have a class. unless you use 2x. (one for each state) but i think the icon should be the button bg.

onclick gives you a reference to the button with which you can change it's class. things inside (now styled by the classname of their parent) will change along. (swap bg, hide/show etc)

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

#144

Post by austincheney »

felixfbecker wrote: post #85
austincheney wrote: post #50

Earlier quoted context omitted.

I also have custom DOM helpers I carry around with me: * getNodesByType - allows me to get things like attributes, text, and comments directly * getAncestor - allows me to get a specified element somewhere between a target element and the document.documentElement

getAncestor is built-in: element.closest() :)

Slow. It uses a selector as an argument, which requires a parse step. It doesn’t take much effort to write something substantially better.

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

#146

Post by christophilus »

andrewstuart wrote: post #28

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 had the same experience recently. I love using lightweight web apps. But I much prefer writing with React-like technology. Inferno is a great React alternative, FYI that keeps the app a little lighter while still providing a sane developer experience.

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

#147

Post by albedoa »

rasz wrote: post #88
ehnto wrote: post #76

Earlier quoted context omitted.

The class related functions have been made native by the classList property of elements. 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 I would also argue element.querySelector and element.querySelectorAll are plenty shortha…

querySelectorAll is a lot slower than old school functions. You would be tempted to say who cares, but then you load Gmail and wait 2 seconds for UI to render.

https://www.sitepoint.com/optimizing-css-id-selectors-and-ot...

The slowest and most convoluted selector took 21ms when tested against 50,000 elements using a 2014 MacBook Pro.

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

#148

Post by yunruse »

xg15 wrote: post #123

So, question for those who are following the JS ecosystem trends more closely: Is innerHTML now officially "ok to use" again? I remember way back (when XHTML was still on the table) that innerHTML was effectively deprecated: It was still around but you weren't supposed to use it for anything new because support might be dropped at any point in "the future". It was also non-standard. Instead, you were supposed to use…

The DOM draft [1] seems to include it. Legacy content is better slow than unusable, however, so it’s better off being discouraged – by linters, dev docs and a warning in the console. FWIW, this is currently linted in TSlint but not JSlint.

It would be nice to have this (via regular or template strings) compile to DOM objects, wrapped with a couple of pointers indicating where strings or elements are placed. I guess for now the best course would be to budge that into transpilation, raising an error if it does anything kooky like work at the boundaries of elements.

(.innerHTML setting is sugar for a HTML parser being initialised on the element, so such a transpiler wouldn’t be removing functionality per se)

[1] https://w3c.github.io/DOM-Parsing/#dom-innerhtml-innerhtml

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

#149

Post by fefe23 »

Thank you for this. Really. Thank you.

I wish we had more postings like this.

No complaining, no whining, no "my framework is better than your framework". Just what problems you had and how you solved them.

This actually gives me something to take away.

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

#150

Post by spion »

bigiain wrote: post #61
bitwize wrote: post #33

Earlier quoted context omitted.

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 a…

The issue is that on regular projects/products, you are trying to hone on perfection by adding and removing a bunch of things and trying different stuff. This repeats for a longer period of time, say 6 months to a year.

The codebase has got to be able to survive that churn in a sensible way, and certain tools like (ES6) modules, types and declarative UI descriptions that automatically update to reflect the changes really help with this process.

Why does this declarative approach help? Because the more features you add, the more places can generate events that cause updates to the same DOM, and the number of possible transitions between those DOM states grows a lot larger. If the number of possible states that the DOM can end up in is N, the number of possible transitions is N^2.

To a first approximation, declarative frameworks scale linearly with the number of interacting features, while imperative (the vanilla DOM API) scale quadratically.

Post reply on HN