I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…
I'm less cynical about web development. Lots of software engineers bemoan writing web interfaces and pine for the days of native GUI development, but web won because it's extremely accessible to people without CS degrees. There just isn't a good native framework that's as forgiving and easy to learn as HTML, JS, and CSS. I think gtk is pretty decent though
Web Components Eliminate JavaScript Framework Lock-In
141–150 of 300 posts
Re: Web Components Eliminate JavaScript Framework Lock-In
#142I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…
I think you are talking about web components. Even in the old desktop world someone had to build the button widget (and all the others) that let you just throw stuff together in MFC or Swing or whatever. Same today - someone has to build the web components in order for us to declaratively use them as high-level Lego. Trouble is, there is no real high-level "general purpose" library of components beyond the core HTML…
Re: Web Components Eliminate JavaScript Framework Lock-In
#143Any web component easily plugs into React, svelte, lit, etc. Existing components written in those frameworks can pretty easily be wrapped in a web component. It's a common base-layer we can all use.
If you attempt to build a web app using just web components and no libraries, you'll quickly find that you're doing lots of manual DOM updates (no templating engine) and lots of manual state management (no data management API).
As an ABI, it's wildly successful. It does, in fact, just work. It's just very low level.
Re: Web Components Eliminate JavaScript Framework Lock-In
#144I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…
I do front end stuff for a living and have been in the javascript space for several years. I do other backend development as well and I can't see why people think like you honestly. Most other GUI libraries is in a much worse state than front end web dev. That is probably also the reason why people use front end tech to make native apps today, because you can customize and make apps much faster than in basically any…
Re: Web Components Eliminate JavaScript Framework Lock-In
#145Earlier quoted context omitted.
Interesting. Yet I find that React HTML—that is not actually HTML, but a look-alike, a dialect if you want—to be exactly what I dislike about React. That is because it still encourages people to put JS in their HTML in their JS in their ... And we are almost back to crazy PHP land of "I treat HTML as a string and blend everything together into one big lump.", instead of using a templating engine, that treats HTML in…
Your criticism was the biggest one of React when it came out -- mixing view code with your controller code. Big no no. Everyone loved the MVC pattern (model-viewer-controller where you separate these things in different places) and what React did was a big no no. But you know, if you are trying to put HTML templates in separate files, you have to now send extra HTTP requests. That's an even bigger no no. In other lan…
Most projects that I have been involved with have some kind of build system that does all sort of magic. It should be possible to include the template in the JS file during the build process
Re: Web Components Eliminate JavaScript Framework Lock-In
#146Re: Web Components Eliminate JavaScript Framework Lock-In
#147Earlier quoted context omitted.
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
It doesn't seem to work at all in Chrome, so maybe not the best example.
Re: Web Components Eliminate JavaScript Framework Lock-In
#148One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…
As someone who does remember why because they've been building sites since the 90s, it's because the React team created a preprocessor (JSX) to let you embed HTML tags in JavaScript. This fixed the problem that other languages like Java, Python, etc. don't have because those languages has assemblies/packages so they can put HTML templates in separate files and load them in your app. There is zero standard way to do t…
> This is what JSX compiles to behind the scenes.
Oh, it is much worse than that. By classic default it is:
React.createElement('div', { /* props and attributes ... */ },
React.createElement('strong', { /* ... */ }, text))
Recent updates and other JSX frameworks simplified the name of `React.createElement` to just `jsx` or `h`. I've seen projects that manually write `h` calls like that everywhere, and it is indeed terrible.(Source: I've just completed a bunch of crazy TSX work and got pretty familiar with the compiled forms.)
Re: Web Components Eliminate JavaScript Framework Lock-In
#149One of the linked articles [1] makes an interesting claim that feels like a reach to me, but I'd be interested in hearing HN's take on it: > At this point React is legacy technology, like Angular. Lots of people are still using it, but nobody can quite remember why. The decision-makers in organisations who chose to build everything with React have long since left. People starting new projects who still decide to buil…
React isn't legacy technology. What a perfidious statement. I can easily justify the reasons I still use React, but I can't be bothered writing it out every time some gimmicky front-end tech hits HN.
1. Go back to reactive templates.
2. Sprinkle directives over plain HTML a-la early Angular 1.
3. HTML over the wire.
All those ideas pre-date React and React won against them back in 2014.
Re: Web Components Eliminate JavaScript Framework Lock-In
#150I haven't been in the frontend world for many years now, but I come from the mid-90's world of GUI development / game engines / old school desktop stuff. I look at this stuff, and just think how sad it is that we haven't progressed beyond the state of gluing together freakin low level divs and spans within some JS code with callbacks galore. For some reason I thought we'd have made it beyond that by 2023, and we coul…
This is talking declaratively at a high level about the kind of interface to render. Lots of component frameworks look like this example. Thinking "how sad it is that we haven't progressed beyond the state of gluing together low level divs and spans" sounds like a preconceived idea rather than a response to this article.By the way, I come from mid-80's BASIC on 8-bit home computers. You get off my lawn.