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

81–90 of 297 posts

Re: Choose Boring Technology (2015)

#81

Post by qznc »

namelosw wrote: post #77
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…

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…

Yes, "boring" as unpleasant associations and this is why it works much better as a title. Consider these two titles:

* Choose boring technology

* Choose well-known technology

More people will click on the first one because it comes with a paradox suggestion. Why should I intentionally choose something unpleasant? That poses an interesting question. The second title sounds boring (how ironic). Why would I click that?

Re: Choose Boring Technology (2015)

#82

Post by TomMarius »

Throwaway8588 wrote: post #9

Except the most employable technology keeps changing every few years. TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago. Ofc I am inserting them into work projects as I need to learn them.

TypeScript is in the top spot for the last 3 years at least.

Re: Choose Boring Technology (2015)

#83

Post by gcoguiec »

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…

Mature Technology? (https://en.wikipedia.org/wiki/Mature_technology)

Re: Choose Boring Technology (2015)

#84

Post by onion2k »

archived22 wrote: post #73
onion2k wrote: post #45

Earlier quoted context omitted.

I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed. You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long g…

Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience. They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech comple…

They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything..

Anecdotally, in my 20+ years of working for website and web app companies, I have never had a client who has even suggested a specific way of implementing an app. The closest has been when a client has asked for a tech proposal and had it sanity checked by a third party. These days I mostly work on "rescuing" apps that a client has had built by one company, found it hasn't gone well, and has come to the company I work for to make it work properly. All of the crazy tech stack implementations I've seen have come from developers who think they're clever, and never the client demanding something trendy.

Re: Choose Boring Technology (2015)

#85

Post by RNCTX »

archived22 wrote: post #73
onion2k wrote: post #45

Earlier quoted context omitted.

I think this is largely representative of the real problem in web dev - the tech has changed, the complexity has grown, and yet the expectation that a web app is still something one person can build on their own using all the modern approaches hasn't changed. You can still make something that works on your own, but not using all the new tech. You have to compromise somewhere. The notion of "full stack" devs is long g…

Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience. They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech comple…

It seems to me that simple devops decision making is becoming a forgotten skill outside of devops pros due to separation of concerns, whereas 15 years ago everyone knew how to install Linux or a BSD, set up required compilers and virtual environments, set up Apache or Nginx, set up a database along with database admin tools, etc.

Wasn’t any Ansible then, either, you had to write your own damn scripts.

Re: Choose Boring Technology (2015)

#86

Post by onion2k »

RNCTX wrote: post #85
archived22 wrote: post #73

Earlier quoted context omitted.

Another drawback of complex stack bites those people who have idea and money, but try to get product done through consultancy because they lack tech skill or does not have enough experience. They read lot of 'buzzword' on the internet or heard them from their tech friend and ask for everything i.e. Microservice Architecture and cloud and all and etc. since beginning. Resulting in unnecessary huge team and tech comple…

It seems to me that simple devops decision making is becoming a forgotten skill outside of devops pros due to separation of concerns, whereas 15 years ago everyone knew how to install Linux or a BSD, set up required compilers and virtual environments, set up Apache or Nginx, set up a database along with database admin tools, etc. Wasn’t any Ansible then, either, you had to write your own damn scripts.

The entire reason PHP grew so wildly in popularity was because hosting providers made it so you could just FTP a file with a .php extension to a server and it ran. Apache was the default web server for shared providers because you could do per account config like url rewriting by uploading a .htaccess file. Virtually no one was configuring their own servers or installing Linux on bare metal for websites.

Re: Choose Boring Technology (2015)

#87

Post by JamesBarney »

baron816 wrote: post #38
javajosh wrote: post #17

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, P…

React has been around for 7 years. ES2015 has been around for 5 years. React has become the de facto lingua franca for front end development. Could you imagine some CTO or technical lead saying, "We're not going to use React because it's too new and unproven." React has proven itself. Facebooks has 100K+ components. There are no unknowns there. Using jQuery or vanilla JS instead would be way more problematic and have…

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/Reporting app)

*Not counting certain types of highly interactive apps (like a Word Processor) which React excels at.

Re: Choose Boring Technology (2015)

#88

Post by readarticle »

quickthrower2 wrote: post #56
javajosh wrote: post #17

SPAs (single page applications) aren't boring yet. we really don't know how to do this well, as a community, and the cambrian explosion of JavaScript tech is almost all around trying to make this extremely un-boring application style more boring. The SPA is a gateway drug to spending lots and lots of innovation tokens, more, really, than almost any dev team can afford. For example, I would consider each of Webpack, P…

A SPA is really just a desktop app where you are forced to use JS and need to BYO front end tool kit. For that we have Typescript (mature) and React (mature). I'd say it's a boring as a WPF app in Windows or an iOS Objective C app. I think we know how to do this well in the general case for most business CRUD needs. That said I am always of the opinion of don't SPA if you don't need to. (also don't spar if you don't…

While it’d be nice to build out an app with only Typescript and React, they’re just the basics.

Is routing in react as mature and boring as a UINavigationController whose API has barely changed since 2009, for example? Is animation? Accessibility? Styling? Are the material-ui and ant-ui kits as boring and mature as the platform’s UIKit?

And I’m not even going to bother going into development environments, or the effects of all these different approaches & API changes on documentation and support!

Re: Choose Boring Technology (2015)

#89

Post by [deleted] »

gavinray wrote: post #23
l0b0 wrote: post #13

As relevant as ever. It's fascinating how big web stacks are these days, even for small-to-medium sites: various combinations of at least one styling language (SASS/LESS/CSS), frontend framework (Angular/React), frontend language (JavaScript/TypeScript/Node.js), backend framework (Django/Express/Spring/Rails) backend language (Python/Ruby/PHP/Perl/Java), and message bus (ZeroMQ/Redis/RabbitMQ). That's just the fronte…

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you…

[deleted]

Re: Choose Boring Technology (2015)

#90

Post by rdgthree »

peferron wrote: post #80
gavinray wrote: post #23

Earlier quoted context omitted.

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you…

I just built a frontend and backend with TS following this same logic. I'm super happy with TS for the frontend, but I regret picking it for the backend and am considering rewriting the backend in Clojure while it's still early. My reasons are: - I don't need to share type definitions between the frontend and backend; the frontend can generate TS type defs using GraphQL introspection regardless of which language the…

It'll depend on what you're building, but there's some value in rendering React on our backend. For example, we render documents (HTML => PDF) and emails with the same React components we use for our frontend to keep styling consistent. There are also some utils we use (in similar contexts) on both sides largely for things like string formatting or annoying math. Not a ton of stuff, but it's nice to have one bulletproof util to format phone numbers in every context. Another one is payment fee calculation[0], so we can guarantee the user sees the same number they'll be charged.

I think the more powerful benefits are definitely hiring and having a team that can work on both sides (and in that regard I think your points are perfectly reasonable), but there are definitely some more direct benefits in our case.

[0]https://support.stripe.com/questions/passing-the-stripe-fee-...

Post reply on HN