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

51–60 of 297 posts

Re: Choose Boring Technology (2015)

#51

Post by choeger »

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…

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript.

However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what that is, a C++ compiler flag.

Re: Choose Boring Technology (2015)

#52

Post by ozim »

bsaul wrote: post #47
baron816 wrote: post #38

Earlier quoted context omitted.

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…

i'm still under the impression that SPA are still not very good for SEO ( unless you also add server side rendering ability, which is probably a bit more involving and "not boring"). is this still a valid concern as of today ?

I have a different question. Why do you want to SEO an application? I understand you want to SEO your landing page or blog but SPA should be dynamic content which you don't even want to be crawled by google.

Re: Choose Boring Technology (2015)

#54

Post by jakelazaroff »

hliyan wrote: post #31

Rapid progress and multiple options (like we have with front-end libraries, tool chains and cloud infrastructure) are great, if standardization (at least of the interfaces and vocabulary, if not the implementations) comes in their wake. Otherwise, only fragmentation, unpredictability and pain you will find. Edit: Just an hour ago I was learning Heroku (having primarily worked with AWS, Linode and bare-metal) and I fo…

“Droplets” as in DigitalOcean? Those are literally just single virtualized servers — nothing fancy or property happening there, despite the cutesy name.

Re: Choose Boring Technology (2015)

#56

Post by quickthrower2 »

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 need to!).

Re: Choose Boring Technology (2015)

#57

Post by bsaul »

ozim wrote: post #52
bsaul wrote: post #47

Earlier quoted context omitted.

i'm still under the impression that SPA are still not very good for SEO ( unless you also add server side rendering ability, which is probably a bit more involving and "not boring"). is this still a valid concern as of today ?

I have a different question. Why do you want to SEO an application? I understand you want to SEO your landing page or blog but SPA should be dynamic content which you don't even want to be crawled by google.

Yes you're right, my question wasn't for apps, but as a response to using react as a universal web frontend tech.

Re: Choose Boring Technology (2015)

#58

Post by winrid »

choeger wrote: post #51
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…

You basically have arrived where lisp was some decades ago. Logical next steps are to write the OS and the editor and the VCS in JavaScript. However, at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extensions. Then you learn that your precious stack is just a GCC upgrade away from not building anymore. And noone in your company even remembers what t…

Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.

Re: Choose Boring Technology (2015)

#59

Post by darkwater »

rooam-dev wrote: post #43

Boring tech is subjective, it depends on the team. A tool for the job needs to be in right hands to be right. Some may be fine with 1 hour after hours deployment, some may want a fully automated CD pipeline.

Nope, boring technology implies mature and tried enough ecosystem where the users community found out and know almost every failure scenario. Your team skills are not relevant in this definition, if a tech is "new" and "exciting".

Re: Choose Boring Technology (2015)

#60

Post by raverbashing »

Yeah, this motto works. Until the "boring technology" breaks in your face or have a gotcha that everybody "forgets to mention" (which you might be able to work around, with various degrees of cleanliness).

And I've seen it happen a couple of times.

Post reply on HN