Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

191–200 of 374 posts

Re: Choose Boring Technology (2015)

#191

Earlier quoted context omitted.

I have been writing it full time about 13 years. I love writing in this language, and TypeScript even more. I am just frustrated by what appears to be some combination of insecurity, false expertise, and a vehement lack of passion in the work force. If I want to be happy I should move on to a different technology stack, but I really enjoy making products in this language.

It's funny, I have about 13 years experience, have been senior in both enterprise, start-ups and everything in-between, and have basically the exact same view about front end dev as your original post. Except I fucking hate using Typescript, and totally wasn't expecting to see you mention you like it, given all the other stuff. IME all the same people that overengineer everything with god awful dependencies are the s…

[deleted]

Re: Choose Boring Technology (2015)

#192

Earlier quoted context omitted.

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 w…

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.

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?)

Re: Choose Boring Technology (2015)

#193

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

You are clearly not a JavaScript developer. It really feels like everybody has just given up and thrown in the towel. There are no good developers, let some giant monster framework make all your decisions, and frequently chase shiny shit. Of course this means starting over, from scratch, in small sections of the product every couple of years. > The industry constantly mints senior engineers who have been bitten by co…

I always wonder how package managers go along with software engineering maturity level > 1 requiring repeatability.

Re: Choose Boring Technology (2015)

#196

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

> The engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies?

Sounds like the bored engineers need to be allowed to go home early, or have some 20% projects.

Also, as John Gall teaches us with his tounge-in-cheek, yet never-the-less true principles[1] -- a principle so obvious most never give it any thought:

"New System, New Problems"

Can someone please just ask "what do we expect some of the new problems to be?" If you get blank stares and no good answers, then you know they haven't thought it through.

[1]: https://en.wikipedia.org/wiki/Systemantics

Re: Choose Boring Technology (2015)

#197

Earlier quoted context omitted.

That's definitely part of it. I also think developer sometimes aren't sufficiently critical when picking technologies and solutions. They fall into the trap of looking at how bigger companies operate, without considering if they actually have the same requirement, budget or even problem. For example, you need a search feature. ElasticSearch is big in search, there's lots of article about people implementing ElasticSe…

Great point. I’m working with a client right now where 90% of the operational pain and low impact dev could be resolved by admitting that the project does not need to resemble a FAANG system.

The problem is the client doesn't want to admit it - if you ask the client how much volume they're realistically expecting and they insist on a ludicrous number; what do you do?

Re: Choose Boring Technology (2015)

#198
post #52

My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and…

Welcome to politics :-) My only suggestion is that one must consider both pathos as well as logos when making rhetorical appeals.

Re: Choose Boring Technology (2015)

#199

Earlier quoted context omitted.

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.

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 w…

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.

Re: Choose Boring Technology (2015)

#200
Hell yeah, I still love working on my 9 years old MySQL+PHP side-project. No build process, no issues with updating to latest package versions, it just works and you are not fighting with the language or tooling itself.

I did add meanwhile some extra parts on top to improve the development and releasing process, but those parts can be changed and removed at any point and the project would still work as expected.

Post reply on HN