Live data from Hacker News

A little bit of plain JavaScript can do a lot

jvns.ca

181–190 of 206 posts

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

#181
post #91

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

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…

> The valid, useful test is whether or not a good vanilla JS app can be better than a good framework driven app.

A much more useful test is to look at the average vanilla and framework app. Obviously the best framework app or vanilla app is gunna be pretty good regardless.

Do frameworks encourage bad/lazy coding? Do they make it very easy to half baked something but very hard to create something polished? Does the constant churn of frameworks mean that a project can never be mature and stable?

Is plain JS too restrictive? Do you have to reimplement react yourself if you want to make a good website?

I think these are the relevant questions.

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

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

Why bother with jQuery? I don't see the value add anymore.

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

#183
post #140

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

Well isn’t that the economics of it? A new dev is much more productive in the new thing they learned. A more seasoned dev is more productive in all the things they already know.

The question is, who gets to dictate the economics here? The answer is always Thanos, balance.

In a true meritocracy this is a legitimate fight, neither side has a one up. We have to find the pros and cons of the old and new and iterate.

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

#184

Earlier quoted context omitted.

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

Why bother with jQuery? I don't see the value add anymore.

Read this whole thread. People are rewriting it over and over again because it’s out of fashion.

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

#185

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…

And here we are in 2020 with everyone writing their own poorly documented and tested partial version jQuery. Instead of everybody working on the same better, faster, probably already cached library.

When will we ever get that jQuery’s thing wasn’t only cross-browser compatibility. It’s that the DOM’s native API is terrible and jQuery is a much terser, powerful, chainable alternative.

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

#186
post #36

Earlier quoted context omitted.

Using tagged template literals the way lit-html does is the nicest JSX-substitute I’ve seen: https://github.com/Polymer/lit-html

It's pretty nice but doesn't play so nicely with editor indenting modes and stuff like that, so there are some reasons to use normal JavaScript function calls instead.

In emacs, with evil mode, I can do:

    vi`:edit-indirect-region:html-mode
And edit the string contents as HTML.

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

#187
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…

>Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.

> I'm pretty sure gmail started out without a framework.

I'm pretty sure you're right.

I'm also pretty sure it's not only one of the big reasons frameworks exists as they do today (because it's perhaps one of the earliest and probably the most famous example of a web app that 100% _needs_ a framework for all the reasons discussed everywhere in this thread), but that it's also the poster child case of why every ambitious/opinionated/inexperienced FE dev builds their own framework (Of _course_ I can't use jQuery/Angular/React/Fluttr! _My_ ToDo list app is _groundbreaking and special_ - just like gmail was in 2004, I'll need to write my own framework for this. Stand back! ") ;-)

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

#188
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…

>Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. I'm pretty sure gmail started out without a framework.

Isn't that where Angular comes from?

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

#189

Earlier quoted context omitted.

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…

> I suppose I could rephrase my question to something like "What is the point of this library?"

It's just a lightweight, no-build-steps-required library that's similar to React. If you already like using React there's nothing much compelling to make you switch.

I like using it with HTM for a nice alternative to JSX which doesn't need any build steps.

I can't speak on its interaction with TypeScript, I've only used this for simple pages where I want to add some interactivity without involving the rest of the nightmarish JS ecosystem.

https://github.com/developit/htm

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

#190
post #46

Earlier quoted context omitted.

I mean he is a React developer after all, less than 3 levels of abstraction is greased lightning.

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.

Damn, you must be the one scooping up all those 10+ years React experience jobs :)
Post reply on HN