Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology

boringtechnology.club

Post reply on HN
Print view View original

301–310 of 356 posts

Re: Choose Boring Technology

#301

Post by grumdan »

rexpop wrote: post #245
amelius wrote: post #243

Earlier quoted context omitted.

> Happiness comes from shipping stuff But Buddha says that the road is more important than the destination ...

Does he?

I know the comment you replied to was in jest, but he did actually say quite the contrary (at least according to Theravada, one major Buddhist tradition): He in several places said the point of all his teachings was to help people put an end to suffering; he only taught the particular things he taught because according to him, they were the best/only way of reaching that goal.

Some schools even go so far as to say that the Buddhist path is something to let go of as well at the very end of the process in order to truly reach enlightenment. It's only a tool to get there.

Re: Choose Boring Technology

#303

Post by sopooneo »

lvh wrote: post #77
macspoofing wrote: post #32

Earlier quoted context omitted.

You're talking about a tech stack, which is not the same as, for example, a modern web application. You can build a perfectly modern web app with 'old' Java/JEE stack, backed by an unsexy SQL-based database. You don't need Node.js with MongoDB. Techstacks very very very rarely enable new use-cases. They are the equivalent of fashion statements by young developers who haven't learned what it means to support software…

Do you similarly feel like frontend stacks have seen no meaningful innovation? I think your argument works fine-ish for backends but it's bananas to suggest that jQuery is the same thing as React or Svelte. I do security for a living and maybe 100% of all jQuery sites have XSS. If I find a React page I can just grep for dangerouslySetInnerHTML and I'm 80% of the way there. (I am exaggerating, but hopefully my point i…

Doesn't XSS require a backend that can receive and then transmit malicious javascript from a hacker using the site to a victim accessing it? And wouldn't that be the case whether the front end was done with jQuery or React?

I'm very hesitant about my assumptions here, and I am confident I'm missing an important point. So if you can clear up my understanding I appreciate it.

Re: Choose Boring Technology

#304

Post by lvh »

sopooneo wrote: post #303
lvh wrote: post #77

Earlier quoted context omitted.

Do you similarly feel like frontend stacks have seen no meaningful innovation? I think your argument works fine-ish for backends but it's bananas to suggest that jQuery is the same thing as React or Svelte. I do security for a living and maybe 100% of all jQuery sites have XSS. If I find a React page I can just grep for dangerouslySetInnerHTML and I'm 80% of the way there. (I am exaggerating, but hopefully my point i…

Doesn't XSS require a backend that can receive and then transmit malicious javascript from a hacker using the site to a victim accessing it? And wouldn't that be the case whether the front end was done with jQuery or React? I'm very hesitant about my assumptions here, and I am confident I'm missing an important point. So if you can clear up my understanding I appreciate it.

Stored XSS requires some sort of backend, yes, but reflected and DOM-based XSS does not. Furthermore, all XSS is some variant of a contextual confusion where something that wasn’t intended to be interpreted as JS suddenly is.

jQuery makes XSS more common in several ways, and some of them are really just the influence jQuery on the frontend has on how the back end works. Some of those ways are pretty subtle, eg CSP bypass gadgets in data attributes (which are very commonplace in jQ libraries). By contrast, React, by building a DOM, has contextual information that jQuery lacks. Go’s HTML templating is unique on the server side in that sense since it too actually understands if it’s in a text node context, a script context, an attribute context, or an inline JS (such as onclick) context, and hence the correct way to treat arbitrary input.

Of course, it’s not because you use React you’re immune. I got XSS against every site that used ZeitJS for example. But the pattern that lead to that (generated code dumped into a script tag) is a common pattern for pre-React frameworks.

Re: Choose Boring Technology

#305

Post by yellowapple »

KaiserPro wrote: post #139
sethc2 wrote: post #107

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before. My hope is for those who agree with the author's p…

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 can (and often do) easily outweigh the upfront cost of porting everything.

Even speed alone, though, can help substantially reduce other more tangible costs; if your TypeScript backend is faster than your non-TypeScript backend, then that translates to needing less server resources to achieve the same result (and/or being able to handle heavier loads without needing to upgrade or expand your server resources).

Re: Choose Boring Technology

#307

Post by Rafuino »

Working on new hardware technology, it's really interesting for me to think about OP's call to only use "proven technology," but how do you get a technology to the proven state if everyone is only using previously proven technology? You can force it if you control a platform (e.g. stuff wireless hotspots everywhere and have wifi capability attached to new laptops), but that's pretty rare in hardware. https://www.siliconvalleywatcher.com/intels-centrino-and-how...

Re: Choose Boring Technology

#308

Post by dd36 »

jasim wrote: post #89
stinos wrote: post #67

Earlier quoted context omitted.

For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well. Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click…

I've found that systems usually get robust over time - most issues in commonly run code paths get ironed out in production, and if we don't keep modifying the code, and the system's relative external world remains stable, things chug along. It is the greatest feeling though! We have a DOS application (inventory, accounts etc.) that has been in operation at a couple of retail stores for about 15 years now. No major ch…

It’s like a plumber or a home builder. You only go back if something isn’t right.

Re: Choose Boring Technology

#309

Post by jp_sc »

liveoneggs wrote: post #93

I proudly used "boring" to describe a massive simplification of my work's architecture that I have been working on for the last few years. It has been a successful culling of tech down to the bare minimum (as always- still a work in progress). Anyway my boss got so so offended and angry that I would use the word "boring". I spent the rest of the day trying to explain it and calm him down. Anyway use caution with the…

I don't think the word is the toxic one in your story.

Re: Choose Boring Technology

#310

Post by tensor »

xwdv wrote: post #86

There’s a certain amount of ladder kicking involved in telling people to choose boring and beige technologies after you started up your career chasing after new and exciting shiny things. Every developer should spend some time working at the bleeding edge, so they know how it feels to get cut. The best time is absolutely at the beginning, when you’re a fresh grad and have the energy. You have the rest of your life to…

The problem is that a lot of shiny new technology is not cutting edge, nor bold. It's just new, and often done more poorly than boring old technology. Also, for someone fresh out of school, you should understand what the status quo is capable otherwise you can't possibly understand what a new technology is really offering.
Post reply on HN