Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

151–160 of 756 posts

Re: If not React, then what?

#151

Post by claytongulick »

pier25 wrote: post #102
oliwarner wrote: post #96

> React developers are web developers. This has felt increasingly untrue recently. I hope I'm just experiencing the peak of the bell curve but I've been bumping into more and more devs who only have experience in SPA React and associated styling frameworks. Ask them to actually style something and they flake out. I was used to some tribalism in backends (everyone thinks theirs in the best and equally hates PHP devs a…

It's not recent. We've had memes for years about React devs using divs with click events instead of using links.

What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically?

It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind.

Or maybe I'm hooked into a router and I need to pass some additional state, or control a transition direction, or maybe I want a navigation to happen after some async action completes, etc...

Also, not all clicks are navigation actions.

BTW, I'm not a react guy, just vanilla web components here, but genuinely curious why you see clickable divs as a bad thing?

Re: If not React, then what?

#153

Post by lucsky »

deergomoo wrote: post #147
flimsypremise wrote: post #134

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward: • A large portion of the cost of maintaining a code repository goes toward maintaining the build. • Multiple builds per repo create significant costs. • Any web application with a UI _requires_ a frontend build f…

I think the author understands that just fine (I follow him on Mastodon and this is something he is very passionate about). To me his argument is that this shouldn't—and doesn't need to—be the case. The vast majority of sites out there would be just fine, and in many cases much better, as traditional server-rendered pages with a thin layer of JS on top for enhancements and for islands of interactivity. That massively…

So he's basically publishing a 20 pages philosophical logorrhea to make the simple point that developers should pay more attention to the difference between a web SITE and a web APP and choose their stack accordingly, which is a totally fair point to which I 100% agree with.

What I fail to see is how React is responsible for any of this because this sort of reads like his wife left him for one of the React engineer or some shit.

Re: If not React, then what?

#155

Post by andrewstuart »

valenterry wrote: post #8

> Frameworkism isn't delivering. Correct. The reason is not the frameworks but the languages. What is needed is a much more high-level and feature-powerful language. Just look at react. Passing down dependencies/values is a pain. So what did react do? It introduced contexts. Similar, other react addons try to solve this problem. But they all sacrifice type-safety in the process. They simply cannot solve this problem;…

Don’t use state, except within a component.

I build all my react this way.

No prop drilling, no Redux, no context, no mobx no state.

If you need to communicate between components then send a document event.

Your react application will be dramatically more simple without state.

Re: If not React, then what?

#156

Post by eawgewag »

I honestly think this conversation gets overly complex because we fail to define the kind of websites we are talking about. These are my definitions, so I'll just share them upfront:

- a web site -- which has low interactivity requirements. Blogs, documentation sites, etc, go here. A vast majority of websites are in this bucket

- a web application -- which has high interactivity requirements. Things like Gmail, Linear, Google Calendar, and an enormous amount of SaaS apps fit in this bucket of things.

React is better at anything else at making the second. React developers happily pay the weird tradeoffs that come with it in order to efficiently develop the second.

React is pretty reasonably good at making the first, but the negative costs are more obvious.

As someone who has worked on one of the most consumed React apps in the world (Discord), I think the concerns with React are overstated. People want a good product, they don't care about the framework and it's costs. React is one of the most efficient (in terms of developer productivity) ways to get there.

I'm not a React loyalist; I would love to see someone dethrone React. My ears are always to the ground for new developments in technology. In my opinion it hasn't happened yet, but I would be surprised if it never happens.

Re: If not React, then what?

#157

Post by Kuraj »

claytongulick wrote: post #151
pier25 wrote: post #102

Earlier quoted context omitted.

It's not recent. We've had memes for years about React devs using divs with click events instead of using links.

What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically? It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind. Or maybe I'm hooked into a router and I need to pass some…

Every time I can't middle click a link to open it in a new tab I want to punch a wall honestly

Re: If not React, then what?

#159

Post by deergomoo »

claytongulick wrote: post #151
pier25 wrote: post #102

Earlier quoted context omitted.

It's not recent. We've had memes for years about React devs using divs with click events instead of using links.

What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically? It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind. Or maybe I'm hooked into a router and I need to pass some…

* Accessibility tools may not be able to detect that it's an interactive element unless you go out of your way to mark it up as such

* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked

* We already have a tag for a clickable element that is not a link:

Re: If not React, then what?

#160

Post by BeefWellington »

emmanueloga_ wrote: post #57

I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible. The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc. Imagine being able to do this without importing any 3rd party code: const content = html` Hello world! `; // New API: html Tagged…

Apart from running screaming in the opposite direction from tagged templates for security reasons, I think a more suitable approach (that fits current ECMAScript naming conventions / namespacing) might just be something like:

    const content = document.createTemplate(`tagged string`).content
You can already effectively do this, though you'll have to decide for yourself if putting the following lines of code into a top-level module translates to "Writing your own framework":

    function html(markup) {
        const templateNode = document.createElement(markup)
        templateNode.innerHTML = markup
        return templateNode.content
    }
Then your code becomes roughly:

    import html from "MyModule"

    const content = html`Hello world!`; // No New API Needed

    document.querySelector("#container").replaceChildren(content.childNodes)
You're losing the pretty printing in the console but there's options for that -- from tweaking the toString() prototype method to straight up creating a custom class that acts as an Element.

Worth noting too: you could cheat in the html function above and have it directly return content.childNodes, thus reducing the differences between the two examples to simply "patch" vs "replaceChildren".

In your example, are you envisioning that HTMLElement.patch() is doing something different than Element.replaceChildren() or Element.replaceWith()? That'd be one area that wouldn't be addressed with this.

Having it first-party would be lovely but it's already pretty doable.

Post reply on HN