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

Choose Boring Technology (2015)

mcfunley.com

Post reply on HN
Print view View original

201–210 of 297 posts

Re: Choose Boring Technology (2015)

#201

Post by nthj »

arcturus17 wrote: post #100
JamesBarney wrote: post #87

Earlier quoted context omitted.

Despite React being around for 7 years, it still seems slower to develop, slower in performance, and buggier than an equivalent SSR app. Despite having a couple years more experience in React than SSRs, I can knock out a 10 page web app with an SSR framework from scratch in a day (security, frontend, backend, data schema, deployment) but it takes me a couple more to knock out the same app in React. (Crud/Search/Repor…

I’m in the same boat, SPA feels slower to develop than SSR to me, despite being fairly more experienced in SPA. However, I find it hard to justify choosing SSR for new projects anymore because: - React makes certain basic things (eg, fetching data, auth) more complex than in SSR, but the overall experience is weirdly addictive and exhilarating at times, especially component reusability on a well set up project. - My…

Turbolinks takes a day to learn, tops, and then you just build more SSR and it continues to work. And the abstraction rarely leaks.

Re: Choose Boring Technology (2015)

#202

Post by dahauns »

scottlocklin wrote: post #153
randombytes6869 wrote: post #117

Earlier quoted context omitted.

Trust me, its the lack of standard library. Python and Java are both "batteries included" . You can write apps decently with just 5-10 dependencies if you want. Every JS app I've worked on has like 10-20X the dependencies of projects written in languages with a good standard lib

> Trust me, its the lack of standard library. It's almost certainly not, as R has plenty of batteries, and young nitwits in the Hadleyverse are writing preposterous node-like dependency graphs. It's fashion, and it should be curb-stomped.

I don't see how R of all languages is a useful counterexample.

It's as far a way from a general-purpose language as it can get while technically still being one, in both scope and intended use/audience.

Re: Choose Boring Technology (2015)

#203

Post by yashap »

leonardteo wrote: post #184

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And thi…

You’re already making the right decision.

I think introducing new tech is fine as long as it solves a new problem for your business. If you haven’t yet used a cache, but have a need for one, introducing Redis or Memcached makes sense. If you have a new need for pub/sub workflows, introducing Kafka or a webhook dispatcher makes sense. Same with Elasticsearch or whatever if you’re building out your first search feature, etc.

What rarely makes sense is introducing new tech that heavily overlaps with existing tech. You don’t wanna end up on MySQL and Postgres and Mongo. Python and PHP and Go. Django and Flask. EC2 autoscaling and Mesos and Kubernetes. Even worse, you definitely don’t wanna start building your own versions of tech that there’s a good off the shelf solution for. If someone tries to build their own UI framework, ORM, service discovery system, etc., kill that IMMEDIATELY.

Introducing new tech that overlaps with existing tech should only be done if you’re going to migrate OFF the existing tech. Obviously this is often a major effort, so the new tech has to be a HUGE win.

My current company was pretty immature for a long time in terms of tech decisions, and the costs are massive. For service-to-service communication we use REST, gRPC and this terrible in-house re-implementation of HTTP over ZeroMQ, complete with hand written clients and server frameworks in multiple languages. We’ve been trying to migrate off that for ages, at massive cost. We’re almost done, but even then will still be stuck with both HTTP and gRPC, when we only need one. Similarly, we use PHP, Scala, Go and Python on the backend. With multiple server frameworks for each. We use MongoDB and MySQL. Redis and Memcached.

The cost of all this is massive. Developers have to learn SO much to be productive in our stack(s). Every time we want to write some middleware, tooling, etc., we have to write like 15 versions of it, because we have about 15 unique combos of backend language/network protocol/framework. Losing a few immature devs who care more about using shiny new tech than solving business problems is a very, very small cost to pay to avoid this situation.

Re: Choose Boring Technology (2015)

#204

Post by lazyant »

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

"boring" is OK "less surprises" is better, for me I think of it as "less risky". Everything is risk management.

Re: Choose Boring Technology (2015)

#205

Post by foobarian »

leonardteo wrote: post #184

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And thi…

I went through this recently when I joined a company and a small team to do a particular overhauling project. One of the developers was relatively junior, but smart, driven, and in love with shiny new tech. For the particular piece he worked on he chose modern solutions that went a bit out of the companywide envelope. I figured it's fine since if we forced the "boring" company-standard set of technologies he might get bored and leave. Well guess what, he left anyway and now we're left holding the bag. All custom stuff that could have easily been reused: scheduler, base container, code generation, language. So I guess my big takeaway is, regarding retention, they may leave anyway. If you're going to open the "new tech faucet" to slow that down, keeping it sequestered may be worthwhile.

I've seen an internal tool at a previous company that seemed to be built similarly by developers who wanted to try new tech. A pretty fancy RoR with a lot of custom changes and integrations. I am sure they had a ton of fun building it, but again, guess what, they were all already gone by the time I started there. And those who stayed hated that code base with a passion because it was near impossible to upgrade, so now we were stuck on an ancient RoR version, and since it was integrated with a lot of other systems it blocked those upgrades as well. Cautionary tale I guess.

Re: Choose Boring Technology (2015)

#206

Post by w7 »

pydry wrote: post #135
namelosw wrote: post #77

Earlier quoted context omitted.

This is pretty much spot on. People usually missing the point of 'boring' because they would think of unpleasant and ancient stuff. The key value is indeed to avoid surprises. When I read WhatsApp used Erlang back in the day, I was pretty impressed. Not only the obvious things like Erlang was the forgotten secret weapon for massive concurrent apps, but also details like they used FreeBSD back in the day when there wa…

Whenever I hear "exciting tech" I tend to think "hyped to kingdom come". I think of node, docker, mongo, golang, etc. - tech that was pushed with marketing $$$ or big names. I have an inbuilt bias against that stuff - not that it's necessarily worse than alternatives but that the marketing budget or big name backer instantly makes me more suspicious. For most developers it seems to work the other way around - big nam…

I'd honestly consider Golang "excitingly boring".

Simple C-ish syntax that's relatively familiar to most programmers, write once and compile to/from anywhere without arcane flags, easy to understand and use concurrency model with message passing, reference development tooling that can enforce standards out of the box.

I don't think there is much new here other than removal of cruft.

Re: Choose Boring Technology (2015)

#207

Post by winrid »

christophilus wrote: post #141
winrid wrote: post #63

Earlier quoted context omitted.

Using Angular 8 and seems they fixed that if it was an issue. The bundle size is like 300kb without dependencies for a prod build, but I don't know what your requirements are. 300kb is a lot, but it's also a huge framework.

Preact weighs in at 3kb. 300kb is a whole lot. I’ve written an entire SPA that is less than 300kb.

Yeah, Preact is tiny.

Re: Choose Boring Technology (2015)

#208

Post by dnautics »

the_af wrote: post #176
mlthoughts2018 wrote: post #163

Earlier quoted context omitted.

Java also seems to bring with it a lot of cultural baggage for bloated design thinking, like needing overkill factory patterns, accessor patterns, and more. If you start creating something called AbstractMonthlyBillingReportAggregatorFactory that inherits from AbstractBillingReportFactory that inherits from AbstractReportFactory all of which implement a Report interface, things have gone unsalvageably far off the rai…

This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did. The…

> Which for some reason plague Java more than other languages.

Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.

Re: Choose Boring Technology (2015)

#209

Post by dahauns »

dmwilcox wrote: post #111
arsenico wrote: post #66

Earlier quoted context omitted.

Not "new" doesn't mean boring. Boring means not using a technology (a framework, or a language) when not needed. Don't use Javascript on the frontend, when not needed, stick with one CSS pre-processor, one database, one cloud provider, one orchestration tool, one CI tool. Be frugal with your stack, and it will payoff.

Agree with the sentiment but, one CSS preprocessor (!!) Lol I must be getting old, CSS3 is amazing why do you even need one? That's a totally optional component that now needs to be updated, used in your build pipeline and Lord help you if you install it with npm and it isn't updated for a couple of years. I'd add boring really means boring, yes that kind of boring (zzz) ;)

I think Sass fits the "boring" moniker quite well when it comes to CSS preprocessors. :)

That said, with recent and planned advances in CSS3 (and free of the IE shackles :) ), CSS preprocessors surely are slowly going the way of JQuery.

Re: Choose Boring Technology (2015)

#210

Post by LukeEF »

This thing is on a 6 month hacker news circuit. And front page every time. There is a psychological conceit in the backend about using tech 'that has 20 years of maturity' - that plays out with DBs more than anywhere else. 'Let the others do the innovation' seems to be the desire.
Post reply on HN