You had me at JavaScript
JavaScript Views, the Hard Way – A Pattern for Writing UI
81–90 of 141 posts
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#82Earlier 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…
Server-side templating frameworks had context-aware escaping strategies for years before front end frameworks were even a thing. Injection attacks don't persist because this is a hard problem, they persist because security is not a priority over getting a minimum viable product to market for most webdev projects.
The old tried and true strategy of "never sanitize data, push to the database with prepared statements and escape in the templates" is basically bulletproof.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#83Earlier quoted context omitted.
They still nail "state" to element trees, which creates unbenchmarkable but real update costs. Svelte does better than react, but only within the same paradigm.
Can you describe what you mean by that a bit more? As I understand it, with the new signals-based system in Svelte, updating data directly updates the DOM.
It's also worth noting that the Svelte signals implementation is quite performant. [0]
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#84Earlier quoted context omitted.
1. Then add the 6 updates to the "setter" function 2. What UI has the same data presented 6 times? Seems unnecessary
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.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#85Why not use Web Components? Is it because they’re classes?
> Why not use Web Components?
If you check out his examples (e.g. clock), you will notice that he is using web components.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#86Earlier quoted context omitted.
So, state is simple, stupid simple. The way to keep it simple is to have a single state object, which is the one place where state is organized and accessed. The way to make it scale is architecture . Architecture is a fancy word that means a repeatable pattern of instances where each instance of a thing represents a predefined structure. Those predefined structures can then optionally scale independently of the pare…
I feel like you completely misinterpreted their comment. They replied to a comment saying that state should not be centralized. They said that if the state decentralized (as in held by individual child components) it's difficult to coordinate between sibling and parent/child components. It seems like you're saying that it's easy to do UI with a centralized state, therefore agreeing with them whilst having the tone of…
The parent comment said: This approach is simple but does not scale and You need separation between components and data. That is garbage and is what I replied to.
I completely understand why JavaScript developers would fail to read this as such as most JavaScript developers are wholly incapable of programming, a forest for the trees problem.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#87[deleted]
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#88I 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…
The problems with this approach are exacerbated in a team setting. The architecture might be trivial from your perspective but good luck getting a bunch of other folks on board with different mental models and levels of experience.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#89I 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…
If you look at it as a tradeoff space it makes more sense why the majority of folks are on some kind of react. What kind of problems do you want to experience and have to solve in a production setting?
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#90I 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.