Hacker News Reader

Comment by nfw2 | Hacker News Reader

The thing I've found about working with React (and the web frameworks like Vue and Svelte), is that once you embrace a component-centered model, it makes virtually all web development easier, even relatively simple projects.

There certainly is a decent subset of web development work where HTML/CSS/JS is still reasonable and viable, but it tends to be less complex, and low-code/no-code tools like Wix or Retool are quickly taking over that space.

View on HN

But you also get yourself dependent on fw devs. And they most certainly don't care about you, your needs and your customers. Wix? That Wix that broke support for all old browsers and devices? Lost views and customers? Thanks, but NO, THANKS. And you, as a site owner, can do NOTHING. You rely on what you're offered. They break it - you're screwed.

If you mean framework devs, I disagree that they don't care about you. Frameworks are generally free and open-source, so creating a valuable product for the community is arguably all they care about. Maybe meeting the specific domain needs of an individual user is not compatible with their implementation or roadmap, but it's not because the devs don't care.

I was not recommending Wix, and obviously there are plenty of downsides to using something like it. The fact remains that it has captured a lot of the market that would have used vanilla HTML/CSS in the past. That is what the OP was asking about.

Doesn't the browser now have native web components and this will replace React as time continues?

Ya, but you gotta roll your own process for the stuff React and co. provide easy methods to do. It's just a lot of boilerplate for small projects. I don't know if web components will really be a "library killer" in the same way browser APIs have done with jQuery.

https://github.com/mdn/web-components-examples/blob/main/pop...

React is about a whole lot more than just web components. It's also a strategy for state management, life cycle, etc. I don't expect web components will ever replace react, but I think it's possible we'll see a new generation of react-like competitors that use web components under the hood.

> It's also a strategy for state management, life cycle, etc.

As a backend dev who can do a bit of traditional style frontend, I fail to see the need for all this complexity. Most apps are running same database queries and displaying it on a webpage.

SSR always supported components.

hush now, that's supposed to be a secret they only learn once they start working outside of node.

You're right. :)

The purpose of a React component is more than just rendering HTML nodes. Furthermore SSR can only do so once per page load

Just like SSR frameworks have been doing for 20 years, including JavaScript integration.

https://www.primefaces.org/showcase/index.xhtml

What I originally meant by the "component-centered model" of React is not that it gives you a prefab list of elements to include on a page. I meant that it gives a framework for organizing custom logic to coordinate the behavior of some DOM subtree.

Also the library you linked can hardly be considered vanilla HTML/CSS/JS

Just like JSF was doing 20 years ago.

It surely is more vanilla, as originally it was designed to work with JavaScript disabled, if so desired.

If JSF has abstractions that encapsulate arbitrary units of logic running on the client, then it is a frontend framework, by definition of frontend framework. If it doesn't, then we aren't talking about the same thing.

Also vanilla HTML/JS does not mean html that works if JS is disabled. It means you are literally writing out the document that is delivered to the user without transformations or a huge runtime library included.

This JSF is not vanilla HTML: <p:commandButton value="Update event2" update="@obs(event2)" icon="pi pi-check"/>

You are using the old syntax, there is also the HTML 5 one with data attributes, just like all those lovely SPAs.

Still the point holds, component frameworks exist for 20 years, it isn't an invention of cool kids JS SPAs, and they work without JS if needed.

I don’t understand your comment completely. The “traditional” SSR frameworks (PHP, Rails, Express) didn’t make it easy to componentize things, instead trying to divide logic by broad category (MVC, etc.). I don’t know whether it’s orthogonal to Web development or caused by its complexity, but the emergence of components as a primary unit of abstraction is meaningful IMHO.

The traditional frameworks like JSP tag libraries, JSF, ASP, ASP.NET Web Forms, Cold Fusion, Zope, AOLServer, our own Safelayer, live from components.

PHP was always a anything goes, Rails never impressed me having used AOLServer and being part of a team that created a similar architecture with TCL (Safelayer mention above, the founder of that startup created Outsystems), express is basically a servlet engine in terms of features.

Reply on news.ycombinator.com