I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable?

Vue/React/Angular don't seem like they are trying to "replace" HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.", in the "On The Web, Augmentation Wins in the Long Run" section), they are taking HTML/CSS/JS and building on top of them. If they all used canvas to render instead I might buy that argument but they don't. They absolutely push those technologies to their breaking point but it's nothing short of amazing in my book what you can accomplish with them compared to just HTML/CSS/JS and even "web components".

I was excited when Web Components were first announced but they are incredibly lackluster with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do. Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.

True

>which feels like a massive step backwards and completely the wrong choice for building a web app.

Why?

I mean, I'd agree if by 'web-app' you mean something like google-sheets.

But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"

We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me.

I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly.

At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.

But also, you can mix things togheter. You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple.

"But why would i do that, if i'd already use react for some parts, why not every where".

Becuase then it leads to abominations like reddit or facebook, where websites that are basically glorified text forums will use gigabytes of memory, have terrible UX, be slow and will crash your browser if you leave them open for too long.

They mostly publish static content: alerts, updates, reports, etc…

At most they might have a single page somewhere for submitting a payment or a simple form.

But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency maintenance.

Most of their sites could have been static HTML files on disk.

I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is worth it (I understand if you don't agree).

In the same vein, I know cross-platform frameworks like Ionic/Quasar are nowhere near as good as native apps. That said the skill set you need (and dedication to actually embracing the platform idiosyncrasies) to make _good_ native apps is not cheap or easy. Cross-platform apps might not fit in as well and might be heavier but they allow fewer people to do more with less. Heck, I have a side-business that relies _heavily_ on apps and it would not exist if I couldn't write them in HTML/JS/CSS as much as that makes some people's stomachs turn.

I disagree, at least around here. Frontend developers with react/angular experience are a hot commodity and really hard to hire, yet just about anyone from any tech tech can knock out html and some minimal css.

Doesn't even make sense to me why anybody uses them.

You cant audit static sites (ones thing I don't like about having traditional linked libraries).

Why can’t you audit a static site? Seems very straight forward. We already audit static sites for accessibility (503 compliance).

Any resources you can point to? Seems like it would be a worthy effort to make other tools compliant.

Definitely something I want to learn about.

I would say it's precisely the opposite.

Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.

There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.

Some projects require 1% of a framework, others require 98%, but the majority are in a range between 25% and 75% which currently need you to re-architect for a total perfusion of React or a competitor.

Sveltekit (its official fullstack framework) even encourages building apps that fall back gracefully for users with JS disabled.

Of course, none of that is to say that you can’t build bloated, badly performing apps in Svelte. Just that you *can* have the best of both worlds, even for simple/static sites.

I think it's more likely to see some kind of WASM-based replacement take off rather than browsers get their act together. That's not to say browsers aren't improving, they absolutely are, but when it comes to competing with the existing frameworks the only answer so far has been Web Components and it was very lackluster IMHO.

[1] There are very few monoliths among the frameworks these days, and apart from React and Angular [2] most aim for rather small bundle sizes

[2] Out if the blue Angular just released version 17 with all the goodies you'd expect from a framework in 2023

Building my first web application in react currently and this resonated with me on such a deep level.

Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.

Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.

htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.

  class superSlider extends HTMLElement {
    connectedCallback() {
      let targetEl = document.querySelector(this.getAttribute('target'));
      let unit = this.getAttribute('unit');
      let slider = this.querySelector('input[type="range"]');
    }
  }

  customElements.define("super-slider",superSlider);

My personal problem with these "native" components is, that the shadow DOM is pretty restricted compared to component frameworks like React, Vue or Svelte.

The shadow DOM provides two things:

- style encapsulation (as well as `id` attributes)

- ability to use `` for templating

You should use it if you require one of the above or both.

The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation.

Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example.

As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/-

Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.

Define _app_. React doesn't have batteries, it has composability. Web Components do too but you have to know how (it's a lot easier in React, just return (html)) but in Web Components, you can register your custom element and provide the functionality that you call "batteries". [1] So if you don't care about attributes and just want semantic composable things, just call it whatever you want to. . Conceptually it's a web component that extends HTMLDivElement.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Baloney if you ask me.

I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.

I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote:

"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis

I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why!

Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).

Achievable by just removing automatic type coercion. Throw errors instead.

Would need to be feature flagged for backwards compatiability.

The benefit boils down to progressive enhancement: because an img tag has built in behavior you simply rely on default rendering behavior and provide "augmentation" as needed via your web component.

They mention not wanting to pass though all those props:

I can believe I'm just missing something but Web Components just seem like extra work with very little gain.

Personally I think the main problem here is client side rendering to begin with, with a modern server side templating library you get a component based structure too and can abstract whatever HTML tags you want in your component before client side JavaScript.

Problem with React is that it is JavaScript first, you always begin with a JavaScript function, but in my opinion the web should be HTML first.

The article goes on to add a good little bit of JS to make everything work they way they want. They still need JS to accomplish what they want. If you turn off JS things will break in that example.

> Personally I think the main problem here is client side rendering to begin with

I mean unless you want to roundtrip for new HTML segments (aka Liveview or whatever Laravel has) you either need to have client-side rendering or duplicate your rendering logic (in something like both PHP and JS for the fast update without refreshing on each click). I'll never duplicate rendering logic again if I can help it and that means client-side render (potentially with SSR for the first render). It avoids so many bugs/issues.

> but in my opinion the web should be HTML first

This just feels dated to me. I fundamentally do not understand this desire. What do you gain from the web being just HTML? What does that even mean? With a CSR framework you are still rendering out HTML, I don't understand why some people care that the HTML was generated server side or client side. The web has moved on from being just documents, it's interactive and that provides a much better UX.

There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm.

By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever, to the browser, over Ajax or in the email. No need for buggy asynchronous SQL JOINs over HTTP and infinite state handling.

If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers. And combine that with a library like htmx you can then enhance that experience for interactive parts and still keep everything in the same backend template. And if it still a need for more complex interactive parts a programmer can can add that with JavaScript afterwards. That is a much better division of labour.

And it is not outdated, browser actually excel in rendering HTML documents, that is what they are designed to do, thus it will always be faster to render the HTML document as it is rather than building it on the fly.

And also the core idea of reaching for JavaScript before HTML will result in suboptimal solutions, I have seen so much unnecessary JavaScript code that could have been easily solved with a few lines of HTML. This change of perspective changes how we think and reason about a problem and therefore our solutions as well. That is why the bootstrapping of a "modern" web app has become more and more asinine.

Another problem with frameworks like React, Vue, Angular and et al have is that they have their own lifecycle and that has made the web closed and not open how it once was, closed in the sense that you can't enhance the HTML document from the outside after it been rendered, thus this leads to the assumption that the person(s) who wrote the site is also the person(s) that manages or uses it, that is a bad assumption.

What is that, exactly?

> By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever,

All frameworks can do that. Web Components cannot.

> If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers.

Web components quite literally don't work without Javascript. And they need Javascript to be able to do trivial things like form participation.

Component rendered before client side JavaScript.

> Web components quite literally don't work without Javascript.

That is why I'm not using them.

Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery.

Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?

It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders.

Of course, you can have a full blown Big Tech web app, but don't forget to have a interop portal with noscript/basic (x)html browsers to avoid, at least for critical online services, Big Tech lock-in and unreasonable exit cost.

That said, it may be a good idea to be able to drive the display or not of

(I am not talking about the abomination of the "semantic" web we had a decade ago)