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

JavaScript Views, the Hard Way – A Pattern for Writing UI

github.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#111

Post by skydhash »

AmalgatedAmoeba wrote: post #95
iamsaitam wrote: post #90

Earlier quoted context omitted.

"I can also ditch a database and just dump everything into a text file." <- This is what you're saying. It isn't hard to see the problem with this kind of thing.

ngl, a lot of the times, an in-memory “database” that gets backed up to a file is perfectly reasonable. Even consumer devices have dozens of gigabytes of RAM. What percentile of applications needs more? Just because a technology works well for a few cases shouldn’t mean it’s the default. What’s the 80% solution is much more interesting IMO.

> an in-memory “database” that gets backed up to a file is perfectly reasonable.

We have org-mode, application configs, and music playlists as three widely used examples for this.

You switch to a database when you need to query and update specific subsets of the data, and there's the whole concurrency things when you have multiple applications.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#112

Post by mondrian »

exe34 wrote: post #50
mondrian wrote: post #49

Earlier quoted context omitted.

The problem the name will have to be updated in 6 places in the UI.

what are those 6 places? how were they updated before?

You have a card with a name, when you click it a detail popup opens and the name is in there. There's also a delete button saying "Delete ", which pops up a confirm dialog and the name is in there, too. When you update the name you have to update all those places.

The alternative is there's a canonical name variable, and it's rendered in all those places. To update the name, you just update that variable and "re-render", and those places naturally pick up the new value.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#113

Post by spankalee »

lylejantzi3rd wrote: post #5

I came up with something similar recently, except it doesn't use template elements. It just uses functions and template literals. The function returns a string, which gets dumped into an existing element's innerHTML. Or, a new div element is created to dump it into. Re-rendering is pretty quick that way. A significant issue I have with writing code this way is that the functions nest and it becomes very difficult to…

You should really check out lit-html[1]. It's not a framework like this README claims. It just renders template with template literals, but it does so with minimal DOM updates and safely. And it has a number of features for declaratively adding event handlers, setting properties, and dealing with lists.

[1]: https://lit.dev/docs/libraries/standalone-templates/

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#114

Post by skydhash »

edflsafoiewq wrote: post #107
atoav wrote: post #39

I program for roughly two decades now and I never got warm with frontend frameworks. Maybe I am just a backend guy, but that can't be it since I am better in vanilla JS, CSS and HTML than most frontend people I have ever met. I just never understood why the overhead of those frameworks was worth it. Maybe that is because I am so strong with backends that I think most security-relevant interactions have to go through…

The basic problem is when some piece of state changes, all the UI that depends on that state needs to be updated. The simple solution presented in the link is to write update functions that do the correct update for everything, but as the dependency graph becomes large and keeps changing during development, these becomes very hard to maintain or even check for correctness. Also the amount of code grows with the numbe…

But what if your dependency graph never becomes large (HN, Craiglist,...)?

I believe a lot of web applications can go without any reactive framework as using one is a slippery slope. You start with React and 80% of your code is replacing browser features. Imperative may not be as elegant, but it simpler when you don't need that much extra interactivity.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#115

Post by d357r0y3r »

_heimdall wrote: post #72
edflsafoiewq wrote: post #7

It appears to be exactly the kind of manual-update code that reactive view libraries exist to replace.

Reactive view libraries exist to hide those details. I think the OP is proposing that the benefit of reactive views/state isn't worth the cost and complexity.

It is absolutely worth the cost and complexity. The cost and complexity of building a web application using some home grown vanilla JS system will end up being a horrible engineering decision most of the time.

There have been zero times in my career where I thought "hmm, maybe we shouldn't have build this thing in React and let's just go back to page scripts." If you're building landing pages and websites, then okay. But that's not most of what we're all hired to build these days.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#116

Post by edflsafoiewq »

skydhash wrote: post #114
edflsafoiewq wrote: post #107

Earlier quoted context omitted.

The basic problem is when some piece of state changes, all the UI that depends on that state needs to be updated. The simple solution presented in the link is to write update functions that do the correct update for everything, but as the dependency graph becomes large and keeps changing during development, these becomes very hard to maintain or even check for correctness. Also the amount of code grows with the numbe…

But what if your dependency graph never becomes large (HN, Craiglist,...)? I believe a lot of web applications can go without any reactive framework as using one is a slippery slope. You start with React and 80% of your code is replacing browser features. Imperative may not be as elegant, but it simpler when you don't need that much extra interactivity.

Then you don't need it. Same for if you can do everything (or most everything) with page reloads, or if you don't have any reactivity at all. But the problem is still real, even if people use frameworks when they don't really have to.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#117

Post by MatthewPhillips »

athrowaway3z wrote: post #17

This might be heresy to many JS devs, but I think 'state' variables are an anti-pattern. I use webcomponents and instead of adding state variables for 'flat' variable types I use the DOM element value/textContent/checked/etc as the only source of truth, adding setters and getters as required. So instead of: /* State variables */ let name; /* DOM update functions */ function setNameNode(value) { nameNode.textContent =…

Hey, I'm the author of this doc. The reason for the pattern is to make it so you always can find why a mutation occured. So combining state variables and dom changes is ok as long as that's the only place that does the mutation. If not, now you've made it harder to debug. I keep the strict separation so that I can always stick a debugger and see a stack trace of what happened.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#119

Post by johnisgood »

SkiFire13 wrote: post #56
athrowaway3z wrote: post #17

This might be heresy to many JS devs, but I think 'state' variables are an anti-pattern. I use webcomponents and instead of adding state variables for 'flat' variable types I use the DOM element value/textContent/checked/etc as the only source of truth, adding setters and getters as required. So instead of: /* State variables */ let name; /* DOM update functions */ function setNameNode(value) { nameNode.textContent =…

> use the DOM element value/textContent/checked/etc as the only source of truth How do you manage redundant state? For example a list with a "select all" button, then the state "all selected"/"some selected"/"none selected" would be duplicated between the "select all" button and the list of elements to select. This is the fundamental (hard) problem that state management needs to solve, and your proposal (along with t…

Did you know you can have "stateful" UI without any JavaScript, using pure CSS and HTML? JS-less (Tor) websites use them.

I have implemented a fully functional, multi-state CAPTCHA using only HTML + CSS for state simulation, and PHP for real validation.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#120

Post by designerarvid »

emseetech wrote: post #97
epolanski wrote: post #73

I have been writing recently an application in plain "vanilla" TypeScript with vite, no rendering libraries, just old-style DOM manipulation and I have to say I more and more question front end "best" practices. I can't conclude it scales, whatever it means, but I can conclude that there are huge benefits performance-wise, it's fun, teaches you a lot, debugging is simple, understanding the architecture is trivial, yo…

I take it a step further and go no-build js with jsdoc. The hardest part about scaling this approach is finding UX designers who understand the web. Just as frontend devs have trained themselves to "think in react" over the past decade, so have designers. The understanding of the underlying capabilities and philosophies of the web have been lost to the idea that the web and mobile can be effectively the same thing. T…

IMO designers should read hypermedia systems by the htmx guy.
Post reply on HN