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

111–120 of 297 posts

Re: Choose Boring Technology (2015)

#111

Post by dmwilcox »

arsenico wrote: post #66
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…

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) ;)

Re: Choose Boring Technology (2015)

#112

Post by the-dude »

cmrdporcupine wrote: post #110
kitd wrote: post #76

Earlier quoted context omitted.

> YouTube was (and still largely is) written in Python, way before it was cool and well-known. I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.

It's funny to call Django the "early web" when it first came out in 2005. That is really not early at all. Especially when you consider Rails, etc. predates that. I was an early Python adopter (1995/1996) and could not for the life of me find anybody who would consider letting me use it in 'mainstream' commercial software projects. Then all the sudden about 10 years ago it exploded in popularity big time. But I'd mov…

Wikipedia says Rails was released in Dec 2005.

Re: Choose Boring Technology (2015)

#113

Post by BigJono »

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 fucking wish this was the extent of the web stack madness in half the places I've worked.

The amount of stuff you can ram into a front-end code base is truly insane.

Re: Choose Boring Technology (2015)

#114

Post by quintushoratius »

raverbashing wrote: post #60

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.

...and that's different from new, unproven technology how?

Unproven technology has all that in spades.

Re: Choose Boring Technology (2015)

#115

Post by robert_g »

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…

There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die.

In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes.

* Created in 1995 and is a very mature platform

* Easy to learn and productive

* I was very comfortable hiring multiple ColdFusion engineers over the years

But, the community moved on and the tooling is now nonexistent compared to other programming languages. ColdFusion will live on, but as a shadow of what it once was. Which is unfortunate because I actually enjoyed the language and platform.

Re: Choose Boring Technology (2015)

#116

Post by randombytes6869 »

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…

> at some point you will have a look into your myriad of nodejs dependencies and see with horror that they rely on C++ extension

This is a big selling point of the most boring languages of all, Java and C#. Performance is close enough to C, and FFI is painful enough, that its rare to see any native code in a project. Other languages that are slower or have better FFI have a much bigger risk of bitrot if you're going to keep a backend around for decades.

Where I work we deploy the exact same pre-built artifact to our Mac dev machines, Linux servers, and Windows QA guys. With Go, Python, JS, Ruby, etc we would have to have it built specifically for the platform. They all use enough native libraries that you can't share a zip file. And its a huge pain to cross-compile for anything except Linux.

Re: Choose Boring Technology (2015)

#117

Post by randombytes6869 »

AmericanChopper wrote: post #68
choeger wrote: post #51

Earlier quoted context omitted.

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…

Whether you end up with a hellish dependency tree is more up to the developer than the language. I’d say the only reason this is more common in node projects than it is in other languages is because dependency management in other languages is more tedious, so the barrier for introducing new dependencies is higher. All of my node projects have had rather tidy dependency trees. It’s also been quite easy for me to use p…

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

Re: Choose Boring Technology (2015)

#118

Post by bob1029 »

noncoml wrote: post #10

I thought MongoDB and NodeJS are the boring technology today... Edit: Oh, it needs a (2015)

I don't think 5 years has done much of a favor for MongoDB.

Boring in this context doesn't necessarily mean 'old' technology. It means technology that is so stable & reliable that you forget it's there.

I can go weeks on end before being tangentially reminded that we use SQLite to store business entities. I am usually in the arena of business logic working with our various customers. This is what boring technology means to me. Stuff that "just works" and never causes you to spend any time worrying about it.

Re: Choose Boring Technology (2015)

#119

Post by johnchristopher »

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 totally share your sentiment (what does a UI designer/frontend guy care about Puppet/Chef/Docker ?) but there's something to be said about the fact that some pieces of css and javascript code is bundled as some angular/vue/react/whatever modules/bricks and you need a gulp/grunt/yarn/makefile to get some js/css code.

Re: Choose Boring Technology (2015)

#120

Post by wilsonfiifi »

robert_g wrote: post #115
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…

There should also be an explicit call out to both tooling and community. Even if a programming language ticks all the other boxes, Without a sizable and stable community to constantly push tooling languages will fade, not necessarily die. In my past job I was ColdFusion programmer for 15 years. ColdFusion ticks all the other boxes. * Created in 1995 and is a very mature platform * Easy to learn and productive * I was…

Do you think open source colfusion engines such as lucee[0] are worth using/learning?

  [0] https://lucee.org/
Post reply on HN