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

91–100 of 141 posts

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

#91

Post by juliend2 »

chrismorgan wrote: post #80
jdsleppy wrote: post #76

Earlier quoted context omitted.

Where do you suggest we sanitize values? Only in the client, when rendering them?

Depends on what you mean by sanitising. If you mean filtering out undesirable parts of a document (e.g. disallowing element or onclick attribute), that should normally be done on the server, before storage. If instead you mean serialising , writing a value into a serialised document: then this should be done at the point you’re creating the serialised document. (That is, where you’re emitting the HTML.) But the golde…

What's wrong about filtering before saving, is that if you forget about one rule, you have to go back and re-filter already-saved data in the db (with some one-off script).

I think "normally" we should instead filter for XSS injections when we generate the DOM tree, or just before (such as passing backend data to the frontend, if that makes more sense).

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

#92

Post by [deleted] »

chrismorgan wrote: post #78
lylejantzi3rd wrote: post #27

Earlier quoted context omitted.

Posts are sanitized on the server side. This is client side code.

Although appealing, that’s an extremely bad idea, when you’re limited to JavaScript. In a language with a better type system, it can be only a very bad idea. The problem is that different contexts have different escaping rules. It’s not possible to give a one-size-fits-all answer from the server side. It has to be done in a context-aware way. Field A is plain text. Someone enters the value “Alpha & Beta”. Now, what d…

[deleted]

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

#93

Post by [deleted] »

iamsaitam wrote: post #90
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 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.

[deleted]

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

#94

Post by [deleted] »

MrJohz wrote: post #62
lylejantzi3rd wrote: post #29

Earlier quoted context omitted.

I call printPosts with the new post data. It rewrites the whole chunk in one go, which is pretty snappy. I haven't decided how I'm going to handle more granular updates yet, like comment count or likes.

Yeah, that's a pretty common approach. Unfortunately, browsers aren't very good at doing patch updates, so it'll completely reset any UI elements in the region being rerendered. It also will make it hard to scope anything you want to do to an individual DOM element. If you want granular updates, for example, you want to be able to do something like `document.querySelector(???)` and be certain it's going to refer to,…

[deleted]

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

#95

Post by AmalgatedAmoeba »

iamsaitam wrote: post #90
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 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.

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

#96

Post by MrJohz »

wordofx wrote: post #84
MrJohz wrote: post #63

Earlier quoted context omitted.

A lot of UIs have redundant data, it's very common to have the same data represented in different ways. Consider the comments page on HN, for example, which has plenty of duplicate information: The list of comments on a submission tells you how many comments exist, but the comment count is also made explicit at the top of the page directly underneath the submission title. If one person comments multiple times, their…

HN is static data. It doesn’t update. Re-rendering a user name 20 times doesn’t matter.

I wasn't trying to suggest that HN needs to update the UI like this, just give an example of how even a relatively simple UI like the one we're using now is full of duplicate data. I then also gave the example of a messaging app because that's a case where you do want everything in sync all the time.

If you just rerender everything every time, then it's no problem to keep the whole UI in sync. But you probably don't want to render everything all the time - that's unnecessary work, and will break any stateful elements in the UI (such as form inputs that will get reset with every render). That's where the idea of React comes from: write code as if the whole UI is being rerendered every time, but internally only rerender the parts of the UI that have changed.

Now that has its own disadvantages, and I think there are similar approaches out there, but the point is that keeping UIs in sync is a surprisingly hard problem.

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

#97

Post by emseetech »

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.

This approach can go far if the team using it knows and respect web technology.

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

#98

Post by SvenL »

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…

A List of items could just contain checkboxes holding the state of selected/not selected. Then it’s a trivial query selector. To get every selected item or to know if every item is selected.

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

#99

Post by nonethewiser »

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…

Can you elaborate on website functionality, team size, and production readiness?

I mean I totally agree on small personal projects. Thats just never the limiting factor though.

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

#100

Post by nonethewiser »

_heimdall wrote: post #71
zffr wrote: post #2

The read me says this approach is extremely maintainable, but I’m not sure I agree. The design pattern is based on convention only. This means that a developer is free to stray from the convention whenever they want. In a complex app that many developers work on concurrently, it is very likely that at least one of them will stray from the convention at some point. In comparison, a class based UI framework like UIKit…

Any code base lives or dies by how well it defines and then sticks to conventions. We can enforce it in different ways, or outsource the defining of convention to other tools and libraries, but we still have to use them consistently in the codebase. I think the OP here is basically proposing that the developer should be directly responsible for the conventions used. IMO that's not a bad thing, yes it means developers…

Using a framework like react constrains developers in a different way. React isnt simply a convention like the linked example.
Post reply on HN