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.

Stringly typed logic and CSS / JS somewhere miles away in directory structure making it very hard to reason about.

I very much prefer sticking to small, composable, encapsulated, actual components made in React or sth similar.

To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.

And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under the post is to force refresh entire site. Except it's not easy anymore, because facebook tries to be SPA.

So we gave up simple and reliable solutions in favour of over engineering that doesn't even work. And all that for no good reason, other then being trendy and having an SPA

- the social graph underlying every post and content producer (one of the reasons FB introduced graphql)

- the recommendation and advertising algos that are interdependent on the content feed

- the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources

Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex than a forum.

FWIW I’ve developed social networks and forums professionally; social networks are inherently more interactive. My first real exposure to front end dev was when I worked on a social network. If I had to build the same webapp today there is zero consideration of writing it as a backend rendered application or restricting to only progressive enhancement. It would only put off the inevitable migration to real FE tech.

What specific aspects of facebook's comment section under post make it that json response is so much better then a html one?

At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum.

However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking certain users from being in the message - which is a traditional messaging function not found in discussion forums. Suggestions of people or subjects to follow given on what you have done in the past, weighted based on various algorithms to determine how recent your past activity was and what your current interests seem to be.. I'm sure you could think of a load of other functions that are not traditional discussion forum functionalities.

In the parent coment alone I emphasized that I acknowledge that Facebook as a whole provides more then just a forum, but it's core content inherently doesn't differ much from being one.

Moreover, functionality like notifications or suggestions are inherently server generated, as such they don't require content itself to be served in specific way.

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.

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

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.

I swear the people writing these comments aren’t working in web development?

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

IME there’s a crazy amount of strawmanning that goes on with these “anti-react” technologies/cults. Yes of course your html and css static site doesn’t need react. But most of us who are actual software devs/engineers aren’t working on static websites like that!

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:

    <super-slider type="range" min="0.5" max="4" step="0.1" value="2" unit="em" target=".preview h1">

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.

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

In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.

I'm working on building exactly this resource alongside a series of posts on web components.

The Stackblitz example is quite good too.

I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.

The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this.

That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

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.

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 <table> rules with the default styling (css or hardcoded) from the 2D semantic HTML document attributes (I should check the hardcoded style of links and lynx for <table> rules).

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

Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.

The problem often lies with the client tantrums.

I was more talking about critical online services which have a duty of interop with Small Tech and must not force users into Big Tech engines only, that to keep the door open to alternatives of reasonable "size", and at the same time to lower significantly exit costs.

But that's smashing open doors, most are aware of those issues here on HN. The real issue is implementation: it has to happen in a regulatory framework, laws dealing with discrimination, and my lawer has been looking into other legal leverages (yeah, I have an open conflict with my administration). The regulatory framework is here, but lobby-ied heavily by Big Tech, making it ineffective and pointless.

A bit like what they have in the US with the "utilities" which then have much more regulatory duties than "non utilities". You also have anti-trust stuff: dominant corpos are much more tied to regulatory constraints, that to let alternatives to be viable (well, that does not seems to work very well in the US). In my country, anti-trust ultra-aggressive regulations did wonders in the telecom industry.

You can still have a web app with a rich GUI, an anonymous simple and stable in time public HTTP-based middleware protocol (which allows to develop Big Tech independent rich GUIs), etc, until the core functions are provided to noscript/basic (x)html browsers (if one thing must work, it is this one).

  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 `<slot>` for templating

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

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. <user-avatar></user-avatar>. Conceptually it's a web component that extends HTMLDivElement.

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

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.

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.

I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python.

There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them!

Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".

No need to break existing software. "use strict" was a great idea. Let's do "use sane"!

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.