[criddell]

And what about the front end? What's the best, most boring choice there?

I was on a project for a bit using React and although it felt like an obvious way to write things, I can't help but feel you can't create something that will last for a decade with it.

[1337shadow]

Unless you're trying to make a really rich SPA, it could be something of: unpoly, htmx.org, barbajs, knockoutjs, turbolinks/stimulusjs... Anything that lets you enjoy server side rendering, whatever your framework autogenerates for you (ie. forms) is better to "just have" than "have to implement", instead of having 2 projects (one API, one frontend), or even no frontend framework at all (ie. mvp.css and plain HTML), you can do a whole lot of relevant projects with that already.

Webcomponents in plain JS are also great to not have to deal with JS class/HTML Element binding and lifecycle yourself.

Why not add a bit of Flutter or React for a few features, but for most pages it's going to be an expensive overkill.

[mlboss]

I recently started learning Elm. Elm is statically typed functional language which compiles to JavaScript.

The most compelling feature is the guarantee of no runtime exception. It language is pretty stable with glacial release cycle. It also has a ui library called elm-ui which allows to develop ui components without css.

There are lot of posts criticizing Elm of slow release cycle and that the community does not take feedback properly. But atleast for my use-case it does not matter.

I like that the language is very opinionated and just works.

Few plusses for Elm: - Static language - Informative compilation language - Awesome tooling. You just nees to install Elm compiler. No npm required. - < 1s compilation - The Elm Arcitecture(TEA) for ui event handling - Beginner friendly community

[BigJono]

You absolutely can. React is the gold standard right now. It's already been king for 6 years and it's not going anywhere. The hype for angular died down. The hype for vue has started to die down. This little bit of hype svelte has at the moment will die down.

React does have a ton of problems but they all come from the next level of dependencies down. Shit like Gatsby and Nextjs won't pass the test of time. Neither will redux (it's already pointless) and all the convoluted bullshit like redux-saga. If you learn to build stuff using just react and other basic dependencies (like express on the back end), you'll be in a good position going forward. None of that stuff is going anywhere.

[deckard1]

I've been using React since 2014 or so.

I can't speak for Angular or Vue, but I'm 100% sold on Svelte. It cuts out all of the crap that React and Redux introduced (lifecycles, hooks, boilerplate, etc.) and boils it all down to fundamentals. You can read the entire docs in a day and fully understand how everything fits together. I dare say it, but Svelte's docs are a breath of fresh air. It's rare that I read documentation and want to keep reading it.

To me, that's what boring tech is about. It's about finding the simplest, cleanest way to do what you need to do. I hope Svelte takes the path of long-term stability over features and complexity and innovation for the sake of it. What they have right now is a solid foundation.

> convoluted bullshit like redux-saga

Wait until you meet saga's bigger brother RxJS/redux-observable. Someone on HN once mentioned JIRA was using RxJS and I realized "ah, that explains why JIRA is the slow pile of absolute shit it is." From just knowing a company is using RxJS I can already guess at the type of internal communication and politics at play in the company, as well as what their code base looks like.

[atom_arranger]

I use a browser extension for checking out the tech stack of web apps.

I haven't done it so much lately but a couple years ago whenever I would check an app with nice UX it was React, and if it was terrible UX it was Angular or something else.

Also interested to see where Svelte will go. For my latest project I just didn't choose it because of lack of libraries.

[criddell]

I've been looking at this from a slightly different level. React may be the best choice for a UX on the web but I think it's still far worse than any native app. It's one of the reasons I get so disappointed after hearing about something cool and new and then finding out it's an Electron app.

I'm stuck on this idea that the best UX is a native app for performance reasons (responsiveness, memory, CPU, battery), aesthetic reasons (assuming your like your native platform) and longevity. On my desktop I often run applications that are a decade or more old. How many web apps rolling out today can sit untouched for the next decade and continue to do useful work?

[danjac]

Could it be that Angular was the tool of choice of enterprise , and enterprise UX notoriously sucks for all kinds of reasons tangential to technology?

[spurgu]

Gatsby at least spends a lot of effort playing cat and mouse with Google's Pagespeed algorithms so you don't have to. That by itself has tons of value.

[criddell]

My instinct is to build a native front end and connect to the back end over a REST (or similar) API. To me, that feels like the boring technology route.

[BigJono]

Yeah, that's totally legit, and what I would default to.

The reason stuff like React exists isn't because it's some big generic library for doing "frontends" that everyone has to use (even though that's how people see it, how it's marketed, and how people use it). If you want to know what a library is good for it's easiest to look at what it was originally built for, the very first problem it solved.

For libs like React, that problem is DOM manipulation.

For most of the interesting things you can build on the web these days, DOM manipulation becomes a problem at some point because the solution has an inherent complexity to it that becomes hard to manage. That complexity is in procedurally updating the DOM, specifically getting the order of insertions and deletions correct and keeping track of every possible state the DOM can be in to make sure your app doesn't get in a weird state that it can't recover from.

The way React (and vue, angular, svelte etc, all the modern libraries) fix that problem is by changing the programming paradigm from procedural to declarative. The declarative paradigm is just fundamentally much simpler for the exact problem of handling DOM manipulation in a large app.

If you're learning, or building something for yourself and not worried about spending time on refactors, then it's definitely worth building something in vanilla JS first, running into some sticky DOM manipulation scenarios yourself, and solving them the hard way. People make the mistake of using React when they don't need to because they don't have a good understanding of where that line is in the inherent complexity of a web page/app, where you start to get a very good returns on bringing React in to simplify some of that complexity.

That's also why I really don't rate vue, angular or svelte. React is a big library in terms of code size (over 100KB still I think?), but almost all of that complexity is internal. The exact same API and functionality is exposed by Preact, which is a few kilobytes. React has a really small API, pretty much just three functions: createElement, render, and useState. I'm a big fan of libraries that do big things with only a few functions. Do one thing well and all that. There's also the JSX transform, which is a straight line for line transform, meaning the code you write is very similar to the code that runs in the browser, you can follow it line by line with no surprises.

React is a good tool to have in the toolkit, after you've gotten comfortable with vanilla JS. I wouldn't write it off based on how other people present it. You just need to avoid the insane amount of complexity and cruft that people have built around it. All that complexity will go away when people go running after the new shiny thing, but React or something very similar to it will stick around for a loooooong time because the fundamental ideas are so simple and powerful. DOM control through declarative coding, code over configuration, utilising the JS language itself as much as possible instead of relying on DSLs, and simple transforms that maintain the integrity of your code all the way to the production build.

If anything replaces React it either have to be quite similar, or be another entire paradigm shift (maybe the whole DOM/CSSOM thing will get replaced at some stage, who knows?)

[ZephyrBlu]

React has innovated somewhat with lifecycle methods and hooks, but the main value is not in it's API. It's the ecosystem and scheduler.

Preact is a good alternative if you have a small app, but the reason it's so small is because it doesn't have a scheduler which might cause issues with larger apps.

[Aeolun]

> Neither will redux (it's already pointless) and all the convoluted bullshit like redux-saga.

I can’t speak to your own use case, but redux and saga absolutely save our bacon when working on a huge enterprise app.

I don’t even want to think about the crazy kinds of stuff we’d have to do without them.

Maybe someone will come up with a better abstraction, but I really think these are fairly good ones.

[wwww4all]

Have you tried redux toolkit? createSlices?

Redux has greatly improved workflow for integrating with React. The main issue with Redux is that it pretends to be generalized state management engine, with all the overhead, while it’s in a shotgun wedding with React.

Will React team attempts another state management, aka Flux, when Redux does 95% of features and is slowly being absorbed into React eco system anyway?

Gatsby/nextjs will likely merge into a single React static site generator. Similar to React router and Reach router merger.

React is like jquery, it’s going to be around forever. React is almost at the core web infrastructure tech level, just by consensus alone.

[acemarke]

Not sure what you mean by the "pretends" statement.

Both the Redux core and Redux Toolkit _are_ completely UI-agnostic, and can be used with _any_ UI layer or even standalone.

Yes, most Redux usage is with React, and we do orient our docs around the assumption that you're probably using Redux and React together, but there's many people who are using Redux separately.

[wwww4all]

The “pretends” comment is light hearted joke (or is it?) about keeping Redux UI library agnostic. When we all know React is the 8000 pound gorilla pulling on Redux.

The default assumption for any production React application is that it will need Redux at some point. It’s much more efficient to start the React project with Redux, than trying to bolt on Redux after React project is underway after a while. Redux Toolkit does make things bit easier.

It’s like how React pretends that JSX is optional, when we all know JSX is requirement in React projects.

Thanks for all the work on Redux and Redux Toolkit.

[acemarke]

Fair enough :)

Yeah, as I've been redoing our docs, I've really tried to emphasize the "take some time to decide if you _really_ need Redux" aspect:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

FWIW, we do take the "UI-agnostic" part seriously. We've got an upcoming new API for Redux Toolkit that we've dubbed "RTK Query", currently available as a preview release. We've got an example of it working with Svelte, and I know I saw someone else trying it out with Vue:

https://rtk-query-docs.netlify.app/examples/svelte

[pjmlp]

Server side rendering with VanilaJS for a some dynamic stuff.