It seems the "hard way" here is just avoiding frameworks. The real hard part of UI is in fact state management and the myriad of methods for handling state.
JavaScript Views, the Hard Way – A Pattern for Writing UI
41–50 of 141 posts
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#42People like to hate on PHP, but PHP provides you with all the tools you need to write a fully working backend, where as JS provides you with half-assed solutions for writing frontend, which is why we have 1000 frameworks and we still can't agree on how to write frontend code. Seriously, we don't even have a convention for writing a simple reusable component with vanilla JS, everyone makes up their own thing. Web components were supposed to be that, but they're a good example of what I meant by "half-assed", because they're ugly, verbose, clunky, don't really solve the right problems, and nobody likes writing them.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#43Something is wrong with web developers culture, cause even in framework-free vanilla mode they cannot get rid of data localization and welding the data and "component" trees together irrepairably.
Rather than building a querySelector-able tree of elements to and monkey-patching mutiplexing nodes for syncing element counts, you invent the most bizarre ways to chain yourselves to the wall. For long time I couldn't understand what exactly drives this almost traumatic habit, and it's still a mystery.
For the interested, this is the outline I count as non-bizarre:
- make an html that draws your "form" with no values, but has ids/classes at the correct places
- singular updates are trivial with querySelector; write a few generic setters for strings, numbers, dates, visibility, disability, e.g. setDate(sel, date)
- sync array counts through cloning a child-template, which is d-hidden and locatable inside a querySelector-able container; make syncArray(array, parentSel, childSel) function
- fill new and update existing children through " :nth-child(n) "
- update when your data changes
Data can change arbitrarily, doesn't require passing back and forth in any form. All you have to do is to update parts of your element tree based on your projections about affected areas.
And no, your forms are not so complex that you cannot track your changes or at least create functions that do the mass-ish work and update ui, so you don't have to. For all the forms you've done, the amount of work needed to ensure that updates are performed is amortized-comparable with all the learning cliffs you had to climb to turn updates into "automatic". Which itself is a lie basically, cause you still have to jump through hoops and know the pitfalls. The only difference is that rather than calling you inattentive, they now can call you stupid, cause you can't tell which useCrap section your code should go to.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#44People like to hate on PHP, but PHP provides you with all the tools you need to write a fully working backend, where as JS provides you with half-assed solutions for writing frontend, which is why we have 1000 frameworks and we still can't agree on how to write frontend code. Seriously, we don't even have a convention for writing a simple reusable component with vanilla JS, everyone makes up their own thing. Web comp…
That is why I made my peace with Next.js.
It is the only framework that feels like I am using JSP, JSF, ASP.NET, Spring, Quarkus, PHP.
Don't plan to use anything else in JS space, unless by external decisions not under my control.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#45People like to hate on PHP, but PHP provides you with all the tools you need to write a fully working backend, where as JS provides you with half-assed solutions for writing frontend, which is why we have 1000 frameworks and we still can't agree on how to write frontend code. Seriously, we don't even have a convention for writing a simple reusable component with vanilla JS, everyone makes up their own thing. Web comp…
I don't think PHP is any better in solving the backend, than JS is in solving frontend. On the Frontend the situation is not ideal, but we made big leaps every let's say 5 years, going from jQuery to React and from React to later generation frameworks like svelte / solid etc. Yes, the landscape is fragmented and there are maybe too many options, but you make it sound like PHP is universally used as the backend solution, while I see it being used little these days except for legacy systems from 15-20 years ago.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#46Earlier quoted context omitted.
It’s probably about time for that to become fashionable again
IIRC its what frameworks like Svelte do when they hit the compiler and optimize, which makes the best of both worlds.
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.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#47This 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 =…
This approach is simple but does not scale. People did this long time ago, perhaps starting with SmallTalk in 80’s and VB/Delphi in 90’s. You need separation between components and data. For example you got a list of 1000 objects, each having 50 fields. You display 100 of them in a list at a time. Then you have a form to view the record and another to update it. You may also have some limited inline editing inside th…
That screams pub sub which is trivial with JavaScript proxy imho.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#48Earlier quoted context omitted.
This is begging for injection attacks. In this case, for example, if parsed_text and filtered can contain Generating serialised HTML is a mug’s game when limited to JavaScript. Show me a mature code base where you have to remember to escape things, and I’ll show you a code base with multiple injection attacks.
Posts are sanitized on the server side. This is client side code.
Server-side sanitization means that your view code is inherently vulnerable to injection. You'll notice in modern systems you don't sanitize data in the database and you don't have to manually sanitize when rendering frontend code. It's like that for a reason.
Server-side sanitization and xss injection should be left in the 2000s php era.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#49This 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 =…
The problem the name will have to be updated in 6 places in the UI.
Re: JavaScript Views, the Hard Way – A Pattern for Writing UI
#50This 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 =…
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?