Hacker News Reader

I totally agree. Using react is a breadth of fresh air for building web applications.

If all you need is a static site landing page that changes once a year, sure use something else, plain ol html, css, and JS will do wonders. But when you want to build an entire application and experienece for consumers, React is exceptional.

Web applications always have state and side effects, there's no escaping it. If you squint and tilt your head, ReactJS is like a pure function given the environment. React lets you model your view around your state and takes statefulness as a given and doesn't try to obfuscate it away.

As you say, its far easier to leverage FP ideas in a react application. Most react components can be pure. State can be modeled with all the fun FP tools and ideas. At the end of the day, React clearly delineates the stateful from the stateless and lets you easily model both relative to each other in a ergonomic manner.

The mental model of UI = f(state) is really beautiful. And I got it explained to me that its best to use an SPA when you have 'interrelated, dynamically updated state' from Tom MacWright and I very much agree.

The issue I had with React is that it forced a lot of mental models and API's on you to achieve UI = f(state) but after finding Svelte and spending 20 mins on the tutorial [0] I feel like I can say I 'get it' when it comes to building web apps.

Though the things you throw away when you decide to go all in on the SPA approach for your site is crazy, I hate not having access to my freaking database while building a page and having to create a ton of unnecessary code just to express a page that pulls in bits of data from my database. I do not want to complex myself with GraphQL. I much prefer the approach of dhh were we should only be paying that interactivity cost on the pages we need high fidelity on (which is probably going to be one or two pages you have for 80% of apps).

I think Hotwire looks promising where you mostly have logical split up sections of html that you want to be independently rendered across the page or on a click. When it comes to communicating and weaving state between those I'd be thinking about Svelte if it starts getting too complex.

Some examples of Hotwire I've seen so far https://twitter.com/tonysmdev/status/1355996616361205760 https://twitter.com/tonysmdev/status/1356460628819533824

[0] https://svelte.dev/tutorial/basics

> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.

I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

I see this sentiment often, that React is too complex, and I just don't understand that criticism. Is there some bloat? I'm sure. But the problems that React solves aren't trivial either.

The signature of a React application (and each component thereof) is simply `f(state) => HTML`. That isn't hard to understand, and the complexity behind the scenes is the complexity necessary to distill and optimize an application to the above. And to your point about JSX, yes, I do want that. I find it silly to write HTML using some other DSL. I have yet to find one that is anywhere near as transparent or ergonomic. How could there be?

I suppose I can agree profiling for the cause of undesired cycles could be easier, but, frankly, I rarely need to do so because I can simply reason about why a function/component is being invoked. The "flow" of a React application is well-defined (and rather simple). To your last point about structuring your code, you are probably right. Things have come quite far since jQuery in many respects, and I am sure that, if I were to try my had at it again, I would find it to be much more sane than 5-6 years ago. I just don't see why anyone would subject themselves to that though...

Kudos on your project! It looks great, and I'm sure provides the faculties important to you and your platform. I would be careful though. Given enough time and energy you may find, in the end, you have simply reinvented React!

I mentioned in another comment that I think HN's comments on front end type topics tends towards 'back end focused folks talking about front end'.

That doesn't make them wrong when they say "hey this super simple site doesn't need to be in react" but at the same time it also misses the use case(s) for react and other frameworks when they rant on the topic more generally.

> The reality is that libraries like React are so popular because they make front-end web development not suck. You can actually reason about the behavior of your UI without first committing to memory a whole of bunch of procedural, ad-hoc `let el = document.getElementById('i-hate-myself')` nonsense.

I think it’s a bit different - they are so popular mostly because of the massive crowds of front end devs cargo culting static websites into SPAs.

And then maybe because of the many cases where they’re applied to replace jquery or a few js sprinkles with unnecessarily complicated SPAs. This is where stimulusjs + turbo or similar could solve the problem with 10% of the effort and complexity.

Then, maybe in third place or further, because there are more cases for SPAs than 10 or so years ago.

I agree that the cargo cult is real and abuse of the "SPA" paradigm has never been higher! But that is orthogonal to the tool.

React does make front-end web dev not suck. It may not always be the right tool for end-users, but as a developer? C'mon. It's never been so ergonomic (and plain simple) to build a complex UI.

I googled stimulusjs[0] and you know what? From a development perspective it looks like it sucks compared to React. I'd rather just write vanilla JS than that hot garbage. Is the bundle smaller? Didn't bother to look, probably. Is it faster? Didn't bother to look, hopefully.

I get it! "Our job is to deliver value to the customer blah blah...". Engineering has costs as well. From training to velocity to, yeah I'll say it, developer happiness, you can't just ignore these costs. Working in a shitty, homegrown codebase using these niche libraries is a recipe for turnover.

On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it! Your future self will cringe a little bit when you open up the source to change something simple years down the line (I know I have!), but at least those interactions are fleeting.

[0] I apologize for my crassness if you are somehow involved in the project.

> On the other hand, if you are just whipping a some simple pages here and there that probably don't need to be looked at ever again... go for it!

Most interactions on the web are simple.

Tools like Gatsby use react to generate static websites. I’m sorry but that’s just insane.

The problem I’m speaking of is having a great slick well balanced hammer (react) which is a pleasure to work with and using it to put nails into (SPA-ize) everything in sight.

I’m not involved with stimulusjs or Hotwire apart from using them to create SPA-like experiences without much time, effort, or agony.

Basecamp use Hotwire for their cross platform hey email client - maybe take a look, it’s a pretty nice app.

You should have included the very next sentence in my quote.

There is a difference between using React and "SPA-izing" everything in sight. React is a library. It doesn't mandate an SPA as its use-case, and, frankly, I've had great success sprinkling React[0] into single pages that need that extra sparkle. Once you move beyond filtering a list or showing/hiding things, the pros quickly start to outweigh the cons.

Could some of those pages be made a bit more efficient or have a smaller download? Probably. But nobody notices and I am able to iterate on them quickly because they follow the same general structure as the bigger applications I've built.

To be clear, I'm not suggesting everyone use React for simple pages but criticizing the tool is a non-sequitur. You are kind of making my point above that all of this "modern JS is ruining the internet" criticism is being levied towards the wrong thing. Like you said, blame the bootcamps for churning out developers that know nothing else about how to develop a web page. Then blame industry for not training them the basics of their craft.

[0] Or preact (https://preactjs.com/). Which is way smaller (3kb)! At this size, it's crazy to use anything else. How big is jQuery again? 20 times that size?

I think we’re on the same page here and it’s a simple page with minimum added functionality via p/react or Vue or stimulusjs or even vanillajs and not an SPA which loads blog pages on top of each other.