Live data from Hacker News

Choose Boring Technology

boringtechnology.club

351–356 of 356 posts

Re: Choose Boring Technology

#351
post #350

Earlier quoted context omitted.

What is a new use-cases that React brought in, that couldn't be replicated with plain old JavaScript? Browser capabilities are game-changers, not a tech stack that runs on top of them. I don't need React or Angular or Node or whatever to make use of them. I can use those capabilities with plain old Java Servlets and JavaScript. React is a shiny new jQuery - that's all it is. WebAssembly, Canvas, WebRTC, etc. those ar…

Concepts and abstractions, like the virtual DOM, matter. Just because you could in an abstract sense (of course you could! It’s a JS library) doesn’t mean anyone actually could. Thought experiment: why does your argument not apply to, say, C? Why bother doing new language or library design? It’s all int 80h eventually.

I'm not saying abstractions are bad. They make writing code easier for developers. It is easier for developers to write a web-app served by Node.js rather than a standalone C program.

I'm taking the perspective of the end-user. From that side, whether the application is written in C or Java or C# or JavaScript makes no difference because the end-user never knows or cares what the underlying language their app is written in anyway. The platforms are game changers; platforms like the PC, like the internet, like the web, like the smartphone, like the browser. Those enable different use-cases. They are the ones that drive broad societal changes.

By the way, I do think the virtual DOM is either a fad or simply an overstatement. What I mean by overstatement is that batching updates is one of the most normal things developers have been doing, from that perspective there's nothing new here.

From a fad perspective, there is no reason why the regular DOM cannot be fast and schedule batch updates to optimize framerate (and with one less level of indirection). The virtual DOM may actually be a problem in and of itself because it makes an assumption that it knows about how to schedule updates better than the actual DOM - even if that is true today, why would it necessarily be true tomorrow?

Re: Choose Boring Technology

#353

Earlier quoted context omitted.

It fits in the ruby part here: http://boringtechnology.club/#33 It would be something that you are adding to the stack. Yes, you are intending to replace something, but in practice there will still be legacy nodejs hanging around. But crucially this one: http://boringtechnology.club/#43 If you are spending time (and therefore money) changing from one language to another, you are not making features for the business.…

It ain't just about speed, though. If TypeScript is able to prevent entire classes of bugs, then that lowers the ongoing maintenance costs relative to the costs of maintaining the non-TypeScript version. It'll also make implementing new features easier and faster (and therefore cheaper) in the long run specifically because of that avoidance of bugs interfering with delivery of those features. Both of those factors ca…

ES6 to TS is more refactoring than a re-write. Just start with the core library and some TS linting and fix things as you go. The time it takes to 80-20 a microservice project into TS is usually less than it takes to hunt down a confused type bug (ie. someone thought this was an array but it's a string). This is not a "re-write":

function(param1, param2) {}

function(param1: string, params2: number) {}

Re: Choose Boring Technology

#354
post #237

Like many developers I have a strong desire to work with more exciting technology, even when there's no business case for it. Strangely enough, I've found the best outlet for that energy (other than personal projects when I get free time) is configuring Emacs. It's less disruptive than putting a new language or database into production, and makes me significantly more content to work with a boring stack. Plus I get a…

I haven't used emacs so why is configuring it so interesting?

Re: Choose Boring Technology

#355

I am in complete agreement with this. (Sing it, brother!) But, " My friend Andrew wears the same brand of black shirt every day. He thinks that if he conserves the brainpower it would take to pick something to wear, he’ll bank it and be able to use it later for something else. [...] I like to think about it like this. Let’s say that we all get a limited number of innovation tokens to spend. [...] These represent our…

The anecdote sounds like Andrew is trying to avoid decision fatigue which is somewhat related but not really what the author thinks it means.

Re: Choose Boring Technology

#356
post #346
post #267

I'm only part way through the presentation, but I loved this line. "And when people succumb to this instinct they tell themselves that they’re giving developers freedom. And sure, it is freedom, but it's a very narrow definition of what freedom is." Yup. You get the freedom to choose a language and/or database with unknowns but you lose the freedom to leave work at a reasonable hour to see your family, pursue a hobby…

I'm uncomfortable with this rehearsal analogy. I'd rather have a company pay me to learn new things than spend my free time coding when I could be seeing my family, pursuing a hobby, or vegging out. From my employer's perspective, I agree that boring is usually better, but as an individual, I'd rather learn on the job than having to feel the need to "rehearse" for my job.

I didn't mean no learning on the job. The time to learn is between projects. If your employer keeps people on projects constantly, then learning happens between tasks.
Post reply on HN