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

131–140 of 206 posts

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

#131

Post by peruvian »

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.

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

#132

Post by reificator »

codemonkey-zeta wrote: post #120
CodesInChaos wrote: post #115

Earlier quoted context omitted.

Using innerHTML as default if the second argument isn't an object risks XSS vulnerabilities. I'd prefer innerText for as default.

What XSS vulnerability? Any user can set the innerHTML of any element at any time.

> What XSS vulnerability? Any user can set the innerHTML of any element at any time.

This mindset right here is exactly why XSS is still an issue.

If you pull user generated content and put it in the DOM like this, you will open your users to XSS from other users. Basing your personal use DOM APIs on setting `el.innerHTML` will lead to a slip-up. Use `textContent` by default.

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

#133

Post by jayshua »

kingdomcome50 wrote: post #127
bschwindHN wrote: post #68

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

That is the getting started page. It lists multiple ways to get started. One of them is simply including the pre-built preact library with a tag. After that you can use h() to build elements - no build step required.

I personally use preact over react because it's tiny - 3kb for the entire library.

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

#134

Post by hombre_fatal »

codemonkey-zeta wrote: post #120
CodesInChaos wrote: post #115

Earlier quoted context omitted.

Using innerHTML as default if the second argument isn't an object risks XSS vulnerabilities. I'd prefer innerText for as default.

What XSS vulnerability? Any user can set the innerHTML of any element at any time.

XSS is when other users can write javascript that executes on your machine, like if they can set their forum signature to `fetch('/send/@attacker/100usd')` and the client uses innerHTML to render it on your machine in the context of your authenticated session.

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

#136

Post by enlyth »

hombre_fatal wrote: post #114
ryanbrunner wrote: post #111

Earlier quoted context omitted.

Neat solution - out of curiosity though, why remove the properties from the passed options? If I called that function, I wouldn't normally expect it to mutate my arguments like that.

At a glance, they do it so that at the end they can merge in any remaining props they didn't handle after all their work building `elem` is done. This can be accomplished non-destructively with destructuring. const { attributes, classList, style, ...rest } = p // elem = ...consume attributes, classList, style... return Object.assign(elem, rest)

This approach with destructuring is great but you will need to transpile the code if you're targeting IE11 which is still often the case in enterprise settings unfortunately.

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

#137

Post by [deleted] »

hombre_fatal wrote: post #117
z3t4 wrote: post #95

Earlier quoted context omitted.

I think its a problem with selling. People want to sell. So out with the old, in with the new. Lets revive some of the trends from the 70's. Or lets rewrite all this code to use classes. Sell more books and courses. Hate on all solutions that dont require out products. Are you still writing plain old JS? In order to be pro you need to use these frameworks... Its all marketing. Trying to argue is like standing on a tr…

Or they have real value by helping developers deliver features that users love while contending with the inherent statefulness of clients.

[deleted]

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

#138

Post by onion2k »

mjburgess wrote: post #109
onion2k wrote: post #91

Earlier quoted context omitted.

The only way your comparison works is if your point is "Framework driven apps are never good". I've lost count of the number of times I've pointed out that a good vanilla JS is always going to be better than a bad framework driven app. One is a good app and the other is a bad app. It's obvious, and therefore not a useful comparison. The valid, useful test is whether or not a good vanilla JS app can be better than a g…

Yes, but the choice of approach isn't outcome-neutral. There is also the question of whether going-vanilla more often results in good apps. I'd go so far as to say the "naive approach" for most things, whenever it delivers on all the requirements, is always the best approach. Be it relational (vs., nosql); grep vs elasticsearch; etc.

The naive approach if you're a developer who knows React is to use React for everything.

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

#139

Post by yunruse »

PetahNZ wrote: post #99
goranmoomin wrote: post #66

Earlier quoted context omitted.

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 :-)

Isn't clarity better than bytes. We can always running through a minifier at build time.

Clarity is only useful when the variable scope is complicated, which it isn’t here. The problem COULD be that the ultra-short variable names make an unclear external API… but given the function is internal, the context of its use would make it rather obvious it’s constructing HTML elements.

You’re not wrong about clarity; it wouldn’t hurt here at all, but it wouldn’t hinder without, so I imagine it’s to reduce cognitive load and make it abundantly clear the function is logicless glue.

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

#140

Post by elisee »

Indeed! I swore off Web development a couple times because of the mess but now my whole party games platform is made with plain JS, no bundling, no post-processing, no big frameworks and it's pretty good. (Although I did recently augment it with some JSDoc types, for long-term maintainability)

At least three devs have asked why I wasn't using some reactive framework or big library. I know why: I'm much more productive without! Simple DOM helpers go a long way: https://jklm.fun/common/dom.js

(If you're curious: https://jklm.fun)

Post reply on HN