[Mikushi]

> The last line of defense against a rogue engineering team is managers who have studied this stuff.

If your engineering team is the one pushing in that direction I'd reckon the company was in a bad spot to begin with to have hired that team because it strongly indicates that the management layer (head of tech/CTO) has no technical clue.

Hire strong Lead Developers with a proven track record of delivering value to companies they worked at and you'll be mostly fine.

Also there's not much to study, in 99% of the cases in a web based startup if your stack deviates from a monolith with one of PHP/Ruby/Python/.NET/Go + Mysql/Postgres/MSSQL you're doing it wrong.

[js4ever]

What's wrong with Node.js? It's super mainstream now. We have it in production since years, I see a LOT of companies migrating from everything else to node since years and it's a growing trend from what I see at my level with startups and even enterprises

[hackerfromthefu]

It's generally high maintenance, npm dependencies, deprecations, leftpad, javascript new shiny culture etc

You can make it work with more maintenance, but you did ask the question what's wrong with it!

[chrisco255]

It's really not high maintenance at all. Leftpad issue was fixed in less than hours the same day it happened and since then the NPM tooling for package management has improved a great deal.

JS shiny new culture doesn't really exist on the back end (and even front end js has calmed down in recent years). Express.js, the go-to framework 7 years ago, is still the go-to framework on Node today.

Node and Mongo are at this point "boring tech". Their limitations and trade-offs are well known, their benefits are also well-established, and their APIs and tooling have matured.

[Mikushi]

Nothing, just forgot about it.

[onetom]

Recommended "literature":

1. 10 Things I Regret About Node.js - Ryan Dahl - JSConf EU (https://www.youtube.com/watch?v=M3BM9TB-8yA)

2. Brendan Eich: JavaScript, Firefox, Mozilla, and Brave | Lex Fridman Podcast #160 (https://youtu.be/krB0enBeSiE)

[redisman]

Sure but there are all known issues to any Senior Devs. You don’t have to pull shady hairballs from npm for every little feature you can think of. I’ve ran node in production for the last 5 years so at least to me it counts as battle tested and “boring”.

[collyw]

The language for one. There are decent choices of language for backend work. Why anyone would choose JavaScript is beyond me.

[Kwantuum]

The thing is, if you have any sort of front-end that is not entirely server-side rendered, you're going to have to work in JS at least some of the time. If your back-end is also in JS, you now get the benefit of isomorphic code for things that you may want to do on both front-end and back-end.

Then there is also the fact that JS is actually a pretty great language if you know how to avoid the footguns. Granted that's not always easy, but it's a language with lexical closures and easy and familiar syntax, it's also very expressive and has a vast ecosystem supporting it. And you can even add the typescript compiler on top if you want compile-time type-checking.

It's also async out of the box, and while that doesn't solve all problems, it scales surprisingly well with no performance tuning whatsoever, it even has decent asynchronous primitives that make it easier to write correct code.

[lostcolony]

Yeah; even without frontend code, JS is surprisingly compelling. It's easy to hire for, easy to write reasonably performant IO code in, the footguns are pretty much all well documented and generally understood (rather than requiring knowledge of the deep magic to debug), library support is top notch, and as a language it supports both OO and FP, while being pretty small in scope, terse without encouraging too much code golf.

[whimsicalism]

Oh, but Python is an ideal backend language?

Give me a break.

[dukeyukey]

If you want something mature, with libraries for everything, solid backwards compatibility and basically the best "boring" choice, go with Java. And if your devs want to mess around a bit, mixing some Kotlin in is basically harmless and easy to reverse if needed.

[collyw]

Not ideal but a lot more pleasant to work with than JS

[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.

[laurent92]

and Java?

[gurkendoktor]

The Java community has some great developers, but also a lot of Serious Software Engineers who will sabotage everything with extra complexity, and then everyone who learned Java in school and never felt like looking at another language (not even Kotlin).

Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.

[cbm-vic-20]

The GP comment mentions the need for finding engineers with "a proven track record of delivering value", yet here we have a concern about "hiring random Java developers".

Is the industry biased against great engineers who have been working with Java for the past 20 years, even if they "deliver value" (which is pretty much impossible to determine externally)?

[lostcolony]

No.

But I, personally, am biased against hiring people with only Java on their resume. Because 90% of the time what I've encountered are people who haven't examined their technology choices, questioned the status quo, tried to -improve- things.

That's not a sleight on Java, per se, but it is against anyone with only one language on their resume. It's just that if there is only one language on a resume in web dev land, it's almost always Java.

[blandflakes]

Yup - it's possible to build uncomplicated software in Java, especially in recent iterations of Java and more... restrained modern frameworks. However, there's no guarantee that you're actually going to either join a team or hire a Java expert with those tastes.

[whimsicalism]

> everyone who learned Java in school and never felt like looking at another language

A large reason I avoid Java teams.

[cutler]

Although still new I'm wondering whether Kotlin could be admitted to the boring technology category given that it was built to dovetail with Java and has first class Spring support?

[stepbeek]

I’ve found kotlin to be wonderfully boring. There are definitely some sharp knives that get abused though. I’ve met a few people who want to throw OO in the bin and treat kotlin as pure FP to their detriment.

[cutler]

Isn't that a real option with Arrow?

[stepbeek]

Kind of. I don't think arrow - however good it becomes - can really compete with a language where those primitives (like do notation) come with the compiler.

[user5994461]

Startups are more commonly on python/ruby/node/php. It's faster to start with and to iterate.

Java and .Net are more common in longer-lived, larger projects, or when performance matters.

[hackerfromthefu]

and where maintainability and tco matter

[collyw]

I think maintainability is mostly down to developer skill and the ability to abstract to the right level. A good Python dev will likely leave far more maintainable code than an average Java dev.

[jermaustin1]

> A good Python dev will likely leave far more maintainable code than an average Java dev.

And a GOOD Java dev will likely leave far more maintainable code than an AVERAGE Python dev.

[whimsicalism]

I have yet to see this in an enterprise setting, maybe my standard for "average python dev" is too high.

[nift]

Can't one always say that? Wouldn't it be more fair to compare equal level of skill?

I mean, in most cases it doesn't really matter what tech you choose as 1. Most products don't really need "massive scale" 2. It's more important to be proficient in the tech you pick rather than it being the "best tech ever". I mean Facebook still uses PHP no?