101–110 of 178 posts
Earlier quoted context omitted.
Elements with an id are globals, so you do this (not that it's recommended): count.innerText = up.onclick = down.onclick = etc
Technically, every element that's not in the shadow DOM is a global. But yes, there's plenty of ways to implement this and an argument to had for most of them.
I don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.
JSX manages to feel just about right: it's plain-old-HTML when you want it to be, and plain-old-Javascript when you need an out.
Still... I wouldn't mind writing in a truly standard language. You're "really" writing the DOM, and HTML and DOM are this godawful bastardization of a user-interface description language. I'd be slightly less grumpy to have a good DOM-writing library, and deal with its ugliness, rather than mix-and-match the domain-specific-language in with my actual coding language.
I'd written myself a good Java version of this type of thing, and I found it kinda pleasant -- especially since it let me do HTML structure checking via the Java type checking. Typescript is -- God help me -- actually a pretty good language, and I'd be OK with actually writing my user interface structure in it, with the help of a good library.
At least then I'm writing in only one language. That saves me time to go out and learn the godawful bodge of CSS to make it look pretty.
Dev: "All the legacy crap is too bloated obnoxious to use and has to much overhead, packaging, and training required to do even smiple things. I'm going to invent a simple lightweight framework from scratch that uses first principles to stay clean."
Time passes framework starts to get used
Random user: "I need to be able to dynamically modify table spacing in Elbonian based languages, whilst allowing for non-standard viewports to dyanmically load partial DOM changes while asynchronously displaying a cat falling over gif animation and the only way to do it in the framework is a bloated hack, any serious enterprise tool needs this, until you get it this is just a toy"
Dev: "Well I guess that makes sense"
Time passes: Hundreds of these random edge cases pop up, og dev is tired, the project gets moved to a committee, usually some drama pops up for several reason that have more to do about posturing than the framework itself
New dev: "This framework is bloated complicated and has too many dependencies and layers of abstraction. After all what purpose on earth is there for me to have to configure whether or not I am using Elbonian derived language encodings that nonsense. I'm going to write my own framework that is lightweight and simple and does what I need it to without all this extra crap"
IT'S THE CIRCLE OF FRONTEND!!
AND IT MOVES US ONWARD!!
we're coming full circle to $(' ').appendTo(parent)
This is where most libraries are going. Svelte 5 builds upon these signals / derivations as well, and I guess a bunch of other libraries. It would be time for them to get together and standardize on a signals library at this point that could be adopted to be a web standard and help interoperability between web components built with different frameworks.
I fully agree with the sentiment, but Svelte does not seem like a natural leader on that front since their version is a JS superset. Already a bit off the map for interoperability. Solid's attempt feels more promising since it's building on existing native functionality (proxies / getters), and has intuitive, low-footprint usage (just function calls and reference comparisons). Edit: It seems I'm not up to speed in fa…
I also have often have smaller deps lists in React's useEffect when wanting to call a callback on the props because of some local state changes. I wouldn't want the effect to fire because the callback changed however. I'm not sure solid even supports that in its createEffect since it is all automatic.
I don’t know why they’re selling lack of JSX as a feature. React works without JSX too. It’s just (very convenient) syntactic sugar.
It is really an odd flex. As soon as you need a transpiler, which many modern JS devs are going to want and need for the benefits they provide (Typescript being huge) then using JSX seems a benefit not a problem to solve.
If you're not a daily JavaScript developer, any form of transpiler / build mechanism seems almost guaranteed to break in the gaps between when you are working on a specific project.
The projects I have that are transpiler/build free are SO MUCH more pleasant for me to intermittently hack on!
Either you should statically/server generate your site, or you have rich content that needs a client side app and you should pick a framework with rich features.
const {circle, path, svg} = van.tagsNS("http://www.w3.org/2000/svg")
const {math, mi, mn, mo, mrow, msup} = van.tagsNS("http://www.w3.org/1998/Math/MathML")
const {circle, path, svg} = van.tagsNS(van.SVG)
const {math, mi, mn, mo, mrow, msup} = van.tagsNS(van.MathML)
This thing is tight!
Just for fun, I ran their minified code through ChatGPT to see if it could deobfuscate it. It did a pretty good job of guessing sensible variable names for things: https://chat.openai.com/share/9dac0b13-7b24-409a-9cc1-494667...
Earlier quoted context omitted.
> Taking into account how much nesting is involved in writing HTML which is another one of its flaws.
What would the alternative be? How can you design a UI without nesting things?
Same as with regular code and functions — overly deep nesting screams bad code.
Honestly, JSX is just a verbose way of calling functions / constructing objects, which is probably OK if it was a language of its own (XML/HTML) — and even then, JSON/YAML won over XML — but makes little sense being embedded in a language which had functions & object literals from the get-go (JS)!
The only reason JSX exists is because it was a cool marketing feature to convert existing PHP/HTML developers to React. And React succeeded mostly because of that. Not because JSX is cool technology-wise (it isn't). But because it hit the right spot in the right time.