News for hackers. Stuff that matters.

A comment on Web Components Eliminate JavaScript Framework Lock-In. Parent comment

Re:Web Components Eliminate JavaScript Framework Lock-In by QuadmasterXLII on Monday November 27, 2023 @01:20PM (#38435994)
With modern browsers, "completely re-output the entire user interface on every state change" is kinda viable. I recently wrote a trebuchet simulator app (hastingsgreer.github.io/jstreb) without a framework. instead I wrote a "rebuild UI" function that I call on every new state, and the user experience is super snappy
[ Parent | on HN ]
Re:Web Components Eliminate JavaScript Framework Lock-In by nightpool on Monday November 27, 2023 @04:01PM (#38438222)
Weirdly I see that changing the "Projectile" selection to "P3" and then back to the original "P4" made the range drop way down, even though the new value was identical to the old value. But changing the "Main Axel" value made it jump way back up: https://imgur.com/a/boo5Xw3

So maybe some kind of "non-functional"/reused state issue exists regardless?

[ Parent | on HN ]
Re:Web Components Eliminate JavaScript Framework Lock-In by QuadmasterXLII on Monday November 27, 2023 @04:31PM (#38438645)
Oh, I don’t like the look of that. This may be a valuable lesson in “I should have just used a framework”
[ Parent | on HN ]
Re:Web Components Eliminate JavaScript Framework Lock-In by stickfigure on Monday November 27, 2023 @01:42PM (#38436317)
It doesn't seem to work at all in Chrome, so maybe not the best example.
[ Parent | on HN ]
Re:Web Components Eliminate JavaScript Framework Lock-In by QuadmasterXLII on Monday November 27, 2023 @02:31PM (#38437030)
Ah, global variables in modules have to be declared with var etc in chrome, but firefox and safari let it slide if you just assign. Fixed, but I guess I’m gonna have to set up a test suite
[ Parent | on HN ]