I remember the time when netbooks were a thing. An affordable device for easy tasks like web browsing. It’s in the name!
Excuse me, what? The web? It’s heavier than some games now! All thanks to React.js and stupid frontend framework boom of 2016.
Frontend people, wake up. Modern JS has everything you need. It’s time to switch to Web Components.

God I wish we could go back to web standards. Stop this nonsense of jsx and css-in-js, separation of concerns should be a thing. Stop requiring me to build a half a megabyte bundle just to sync js with html. And what do I get for it? useEffect that can't be asynchronous? Constant, and I mean it, constant full page rerenders if I only slip in just a single place and don't use useCallback in one place? Sometimes I wish I would have picked pottery instead of programming.

@ostream
SSR is not magic, it doesn't mean that you can send your react app without react and all its shortcomings, it just waits for the hydration.

@ostream SSR is the worst thing to happen to frontend since React

createElement

A single glance at the design and naming of the imperative DOM building methods makes it blatantly obvious that they were never meant to be used directly to build webapps.

And anyway, I think netbooks were always slow, they were just the best we had. We got used to fast navigation and being able to open more than one tab.

@ostream oh my goood, qt indeed is the way to go

@ostream good luck making it in the web world with your solution requiring people to download an exe while everyone else’s doesn’t

@ostream I don't know QT, but don't they have both QML and a visual editor to ensure that these APIs aren't used for high level UI building?

@ostream your qt shit (and every piece of wasm shit for that matter) renders on canvas. That means bye-bye accessibility. Screen readers can’t read pixels.
JS is superior in every way. Bun is reaching rust levels of speed for certain tasks. Wait till we get JS-specific cores in every CPU. That’s inevitable given the pace of web/JS development. Apple already has JS-specific hardware in Apple Silicon.

@ostream No, I'm talking about APIs and only APIs. Until this comment nobody mentioned implementations at all. I brought up QML and the visual editor because they are alternatives to the procedural API, indicating that the QT devs would like people to have alternatives that are closer to HTML and JSX, because procedural APIs have garbage DX.

@ostream Bun runs typescript natively, without a transpilation step

@kiki I timed a lot of parsers in the last few months, +/- 1 pass doesn't really make a difference in comparison to the cost of then translating that into a usable datastructure, unless I really suck at building ASTs. I think the bigger problem with pre-bun Typescript compilers is that the first pass - stripping type annotations - is often itself written in JS.

And when it isn't, it's a separate OS process which adds a lot of syscall and data transfer overhead.

@lorentz but zig goes brrrr, hence bun

Hot take, but frameworks provide a lot of boilerplate that devs have no business making for each project.

Frameworks like Angular might have some antiquated tech inside of them, but modern web still needs some help.

Web components are a pain in the cock to work with, plain and simple. While their sandboxing is neat, the fact that you can't un-sandbox them is so fucking annoying that I don't even like to work with them much. Not to mention that they have no built-in templating system worth a god damn.

Not only is it HTML-in-JS (and css in js) all over again to get the templates into your web component, but web components really only work well if they are smaller (like widgets) rather than larger (like pages, forms, etc) because the CSS sandboxing makes it really fuckin annoying to design a consistent theme, especially if you're making a UI library where you can't just <link> the site's main CSS file directly into the component template

@AlgoRythm you clearly never tried to go without a framework in production in today's web landscape. because I dared to do that and will never go back to using frameworks.

@kiki I have made two web component libraries (given up on both, first after about 45 hours of development) and am currently making a SPA without any framework (check my recent rant for timestamped proof of frustration).

Just because my experience differs from yours doesn't mean I don't have any experience!

@AlgoRythm oh… okay. I'm sorry.

My approach is

1. Write raw HTML + CSS to serve kinda like a mockup of a future app. Mock screens, mock data, mock everything. No JS yet.

2. Find reoccurring things like list items. Move them into <template> tags.

3. Take a screen you want to bring to life. Fetch data. Using direct manipulation with querySelectors + cloning template contents with cloneNode, assemble the page.

4. Profit!

There is no component hierarchy so to speak. There is just a flat page with “hot” tags whose content will be replaced with server data, and some templates for things you should have more than one piece of.

Of course this is given my usual backend architecture, e.g. a lot of big, single-purpose controllers that respond with everything you need for, say, one page. From user email in the header's “account” popup to the actual page's content. When the page loads, ideally, only one fetch() call should occur.

@kiki One fetch per page? Sounds like you're writing a SSR app without the SSR.

My approach with my current frameworkless SPA is very restrictive when it comes to layout, but it is what I want. I've attached some visuals to explain, but essentially I have a portion of the webpage reserved for content, and this portion of the page hosts pages that I have defined by extending the base class and providing a few attributes.

I use handlebars.js and node.js to keep my markup short and modular. Each template is defined in its own partial view, and each template-partial-view is also included in a larger "all templates" partial view so to include it on the page I just include one partial view. Otherwise the html file just gets inflated to the moon with templates.

When the SPA navigator navigates to ("builds", in my own SPA terms) a page, it calls onNavigatedTo, where you can setup logic, event handlers, and (1/?)

...access the dictionary object of <element name, element> that the SPA has done for you, so you don't need to query the DOM for those elements in code each time.

After the user navigates to a different page, the onNagivatedFrom method is called on the previous page so that you can shut down running processes, unhook from global events, etc.

Each page has a pathName so that the user can navigate around the webpage as if it were a classical website, and so that the user can save a bookmark of the particular part of the site they use, etc. The user can go back and forwards in the app using the in-page arrow buttons or the browser back and forwards buttons, but the in-page buttons are preferred because they show the accurate state of the navigation in the app, not in your browser, which may have more items in the "back stack" so to speak (such as your google search to reach the page).

SPA made the most sense for this project because it involves processes that (2/?)

...run indefinitely, as long as you have the app open, even if you're on a different page (it is monitoring multiple market places in an online game for good prices etc) which makes this more of a web app than a web page.

Though I agreed that I didn't want to have the weight of something like angular for this project, I also have personally met some hardships in the boilerplate of this app. Mostly that implementing SPA principles on my own is sort of boring, long, and already accomplished by countless free-to-use products such as Angular, and now I don't even get to take advantage of other creature comforts that Angular provides such as data binding etc.

And I haven't employed any web components yet. Everything is just basic DOM like in the days of old, because I don't actually want any CSS sandboxing because it's all one application and I want my styles to be inherited all the way down.

Plus, creating web components is such a bother too (3/?)

...especially when you compare it to the framework my personal SPA is based off (WinUI / WPF / etc), when you create a re-usable custom control (a "user control"), it's super intuitive. You get a markup file (control.xaml) and you get a behavior file (control.xaml.cs) and then to use the control, you just reference it in the markup using the format namespace:controlname

Web components ridiculous compared to this process. You somehow need to figure out how to get a template into it, which there's no extremely excellent options. You need to make sure that the CSS gets in there, which usually is accomplished via a link tag in the template which heavily relies on the HTTP cache and then FUCKING destroys your network tab in the devtools. You need to repeat this process for each component, or come up with your own solution. And this assumes you have just one or a few CSS files that define your theme for your entire site. (4/?)

...which means if you have any page-specific, contextual, or otherwise logic-based CSS files, your web component needs a way of getting those too. This presents issues for things like existing PHP or ASP.Net MVC applications which might have done the perfectly sane option of including a <style> tag that changes the color of all buttons to purple for one page (example).

And even if you get past all those hurdles, the base web has no great built-in options for data binding yet. It's not an essential thing for programming, but it's a really nice feature of many frameworks and keeps code clean (without needing to hook up events, explicitly update the content of controls, etc).

So while I agree that the base web is perfectly capable, has the advantage of being efficient, and is well-designed, I also believe that larger projects benefit from a more capable framework with all these features.

Amen to this. Even though we have components now it's fucking hard to get some reusable stuff going without react or other full js page builder.

I just want to write some html, add in some components for the dynamic parts and without reinventing the wheel.

So far the closest that I could get is using unpkg and https://github.com/material-compone...

@hjk101 may I introduce you to the church of <template> tags. Read my comments above to learn how I do it for two years already and I'm about 5x faster than when I still used react

@ostream I’m paid more because I’m faster

@ostream yes

@ostream the harsh reality is that react guys are disposable and replaceable. They’re dime a dozen, there is massive surplus. But people that can improvise and deliver things quickly with flexible things like native js are hard to come by. I know because we tried to hire one.

@hjk101 https://stimulus.hotwired.dev/

@kiki thanks both solutions look very interesting.

@kiki
Damn, this makes me nostalgic. Back at knockout.

@ostream
Fun fact, "nostalgic" doesn't need to mean anything positive.

@ostream Netflix
Sara Soueidan

@ostream every framework’s selling point is that you don’t have to rEiNvEnT tHe wHeEl 🤡 because the framework has everything figured out. But why stop at react? Use SAP! It has _everything_ a business might need.
If you don’t want to use SAP, where is the line then? Why not Angular?
I deny the existence of that line. Business is alive and is constantly evolving. Every framework will break sooner or later, and it’s hacks and piles of legacy code all over again.

@ostream just tell me where the line is. If you don’t, it means your choice is arbitrary, and thus isn’t rational. It means you’re a fanboy, and I don’t listen to fanboys when it comes to what needs a calculated solution.