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

171–180 of 206 posts

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

#171

Post by earthboundkid »

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…

Don’t use innerHTML with data that you got from a user, directly or indirectly. But if it’s all your data, it’s great.

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

#172

Post by ben-schaaf »

_pdp_ wrote: post #73

A little bit of C can do a lot, yet most 3A games are written with frameworks.

If all you need to do is display a native dialog, read some files, etc. you're better off without the massive 300MB game engine. A lot of people making native apps aren't game devs and a lot that are aren't making tripple-A games.

In the same way there's definitely web apps that are better off with a large framework, but if all you're doing is toggling some classes you're better off without them. Most websites don't need to be SPAs.

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

#173

Post by kingdomcome50 »

bschwindHN wrote: post #159
kingdomcome50 wrote: post #127

Earlier quoted context omitted.

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

I linked to the "no build tools route": > Preact is packaged to be used directly in the browser, and doesn't require any build or tools

Oh I gotcha! That quote applies to react as well though (I've done it many times!).

I suppose I could rephrase my question to something like "What is the point of this library?". Every other page on that site that includes examples uses JSX... which means there needs to be a build step.

I guess if someone really just wants to include a 3rd party library to programatically create elements, but get none of the benefits of using them this would be great! Then again there is like 3 examples in this thread of tiny functions (I guess 3.5kb is about 10x smaller than React + React DOM, but 35kb isn't exactly breaking the bank either. I can't tell specifically by glancing over their examples, but I also suspect feature parity is not quite there. Specifically, I develop with Typescript so being able to type hint `React.ChangeEvent` etc. is sometimes necessary. It's not clear if Preact exposes a sufficient API. Maybe you know?

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

#174

Post by jb3689 »

Unfortunately the reason we have frameworks is because there are so many gotchas. It's true - vanilla JS can do a lot however, there are also a lot of strange edge cases that aren't handled well. If you don't mind failing on these cases then it is fine, but this is why things like jQuery were built and why your React project has hundreds of dependencies. Personally I prefer vanilla JS, but for any serious project it is hard to choose it

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

#175

Post by runarberg »

afarrell wrote: post #74

What sort of automated test framework do folks use while writing vanilla JS?

I use AVA[1] and c8[2] for coverage. It only works in node so I have to use JSDOM to mimic the browser environment.

1: https://github.com/avajs/ava

2: https://github.com/bcoe/c8

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

#176

Post by [deleted] »

Bellamy wrote: post #168
andrewstuart wrote: post #47

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.

This gotta be some kind of mistake. :) React 1986?!

[deleted]

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

#177

Post by dgb23 »

triceratops wrote: post #69
bigiain wrote: post #52

Earlier quoted context omitted.

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.

How do you generate html in the first place? With React you have the same UI logic in one uniform framework. Whether you render statically, on request or in the client doesn’t split up your code. Everything plays together nicely. You get sensible editor support with linting and static analysis and more comprehensive error messages.

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

#178

Post by monoideism »

bitwize wrote: post #33
monoideism wrote: post #12

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.

I totally agree. Frameworks are needed for large projects. You either use an open source one, or build one yourself. And usually, the former is greatly preferred.

However, if you're a frontend dev, you should understand VanillaJS. Just like a systems programmer should understand assembly and C. Also, there are some situations where you won't need a framework.

Knowing VanillaJS and using frameworks are obviously not mutually exclusive.

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

#179

Post by hombre_fatal »

onei wrote: post #119
hombre_fatal wrote: post #116

Earlier quoted context omitted.

Could never get over Mustache using {{foo}} for safe auto-escaped interpolation but {{{foo}}} for dangerous non-escaped interpolation. I wonder how many XSS vulns this decision has caused in the wild.

I'd say that's the more sensible decision if you want to maintain syntax. You can grep for {{{ without false positives matching {{. Conversely, it's harder to find places where == was used when === should have been used (although I'll concede it's not much harder). In general I'd prefer to go the extra mile to be unsafe than accidentally miss something out.

Maybe my point wasn't clear, but {{{ and {{ look too similar. It should be {{ and something else. Like {{Dangerous=username}}.

You shouldn't have to squint at your templating code to see if there's an XSS vector or not, or defensively/neurotically grep for "{{{" just in case you didn't trust your team to squint sufficiently.

For comparison, here's JSX: .

vs. Mustache: {{{username}}} in a file of 1000 other { and } glyphs.

Mustache's hey-dey is long over thankfully.

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

#180

Post by onei »

hombre_fatal wrote: post #179
onei wrote: post #119

Earlier quoted context omitted.

I'd say that's the more sensible decision if you want to maintain syntax. You can grep for {{{ without false positives matching {{. Conversely, it's harder to find places where == was used when === should have been used (although I'll concede it's not much harder). In general I'd prefer to go the extra mile to be unsafe than accidentally miss something out.

Maybe my point wasn't clear, but {{{ and {{ look too similar. It should be {{ and something else. Like {{Dangerous=username}}. You shouldn't have to squint at your templating code to see if there's an XSS vector or not, or defensively/neurotically grep for "{{{" just in case you didn't trust your team to squint sufficiently. For comparison, here's JSX: . vs. Mustache: {{{username}}} in a file of 1000 other { and } gl…

I agree that something possibly dangerous should be harder to mis-use. The world is full of small oversights. Having said that, surely this is the job of a linter - does one exist for mustache?

I've never seen JSX before (I haven't learned anything new in front-end later than ES5). In your example, it looks more like an attribute than an inner tag, the former of which I'd almost always escape. Is that how you set inner HTML as well?

Post reply on HN