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

141–150 of 297 posts

Re: Choose Boring Technology (2015)

#141

Post by christophilus »

winrid wrote: post #63
praveen9920 wrote: post #37

We learned this lesson the hard way. A few years back, for a start-up, we picked angular 2.0 as our choice for frontend stack, when it is released. Though it was fun to develop it, We faced a lot of unknowns and issues to finally ship it. Too many changes for each version, The bundle size was too big. Angular SPAs were not great for SEOs etc. We ended up missing the shipping deadline by a couple of months. When you r…

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.

Re: Choose Boring Technology (2015)

#142

Post by wpietri »

ryanbrunner wrote: post #105
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…

React itself has been around for 7 years, but the ecosystem around React is still developing. There isn't a straightforward answer that's universally accepted and without warts in terms of how to do server communication, how to manage state, how to smoothly implement routing in a way that avoids most of the navigation hiccups that SPAs run into, how to manage CSS, etc. There's certainly answers which seem promising f…

This resonates for me. I'm mainly a back-end developer, but for a while I've been wanting to improve my front-end skills so I can do basic things myself. React has been the obvious choice for a while. But every time I say, "Ok, let's see what I need to learn to get started," which happens maybe once a year, I end up getting different answers.

I would like React to get more boring. Because I'll never focus mainly on the front-end, I can't devote a lot of cycles keeping up with the latest trends. If I have to make 50 (or even 5) informed decisions every time I want to throw a little interface on something, I'll never get anything done.

Re: Choose Boring Technology (2015)

#143

Post by the_af »

tarkin2 wrote: post #138
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…

Yeah. Java is pretty boring but I wouldn’t recommend for the majority of cases.

Why not? Java is used to great success in the software industry. It's a good language and platform, fads to the contrary notwithstanding.

Re: Choose Boring Technology (2015)

#144

Post by wpietri »

tarkin2 wrote: post #138
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…

Yeah. Java is pretty boring but I wouldn’t recommend for the majority of cases.

Java is boring in one sense, but it's the wrong kind of exciting in another. I've had to touch it a couple times in the last few years, and there's still a ton of "enterprise" nonsense in the space. Everything feels bloated, confused, unpolished. It's like I'm walking along, step on a trapdoor, and suddenly am sucked down into a tangle of stack traces, class loaders, annotations, and XML configs.

For me, part of "boring" is being like a 2x4 or a claw hammer: simple, solid, reliable, well understood. A lot of the Java world is nothing like that.

Re: Choose Boring Technology (2015)

#145

Post by dotemacs »

The author even has this whole site, which is essentially a slide deck: http://boringtechnology.club/

But even though he talks about "boring" tech, he did go on to have a startup, Skyliner, which was written in Clojure and subsequently acquired by Mailchimp.

So I guess, you can't be using the borking stack all the time...

Re: Choose Boring Technology (2015)

#147

Post by ProZsolt »

midrus wrote: post #33
jasonkester wrote: post #29

Earlier quoted context omitted.

The solution to this is to use the New Shiny at your day job, and the good boring stuff for your own projects: https://expatsoftware.com/articles/happiness-is-a-boring-sta... If it’s Somebody Else’s Money paying for the development, go nuts with whatever crazy tech their 19 year old CTO wants to roll with. Hopefully they have a VC holding the bag to subsidise the ride. But when it’s your stuff, and it’s your weekends…

I was really hoping this was sarcasm, but sadly I've seen this happen far too many times already. There is some impunity going on where the people making these kind of decisions in some companies when things fall down they just blame it on something else and switch jobs, and now you're stuck with mongodb or a django where somebody thought using sqlalchemy instead of the ORM was a good idea or a monorepo with all comp…

When most of the companies expect you to hit the ground running with every technology they use, I can't really blame them. If companies don't want to train the employees when they start in a new position, they will train themself when they about to leave.

Re: Choose Boring Technology (2015)

#148

Post by ghc »

kitd wrote: post #76
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…

> 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.

I would classify early web (1.0) as 1993-2003 (pre-AJAX), and modern web (2.0) as 2004-on (post-AJAX). The biggest change since then has been on the backend -- moving from web frameworks in Python/Ruby to Single Page Applications with Javascript backends.

Re: Choose Boring Technology (2015)

#149

Post by wpietri »

onion2k wrote: post #86
RNCTX wrote: post #85

Earlier quoted context omitted.

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.

That was a big reason, but I think another key choice was that the output format (HTML) and the input format (PHP) could be pretty close. If you were 15 and wanting to make a dynamic webpage, you'd look at an existing web page, copy it, and change one bit. PHP made that easy. The next change and the change after that were easy too.

In contrast, competing technologies started out with, "OK, learn computer science. Now learn how HTTP works. And then learn CGI. And some Unix. And then you can do 'Hello, World.'"

The funny part for me is that a lot of us in the latter camp didn't learn computers that way at all. We started out with BASIC:

    10 PRINT "Onion2K is cool!"
    20 GOTO 10
It had the same immediacy as PHP. The ease of making something happen was what drew us in. But somehow we forgot that. While also saying, "Here's something that will touch everybody on the planet. Let's all use it!"

Re: Choose Boring Technology (2015)

#150

Post by hoorayimhelping »

wilsonfiifi wrote: post #120
robert_g wrote: post #115

Earlier quoted context omitted.

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/

No. Avoid ColdFusion - it's a language from a bygone era when Adobe was trying to be what Microsoft is now. They failed and the ColdFusion community will die. The community, while made up of great people that I am still friends with, by and large was not interested in improving, learning new techniques, or growing beyond ColdFusion. They wanted to learn a skill and cash in on it for a long time. The language is dead and their skills are becoming useless as a result.

Maybe in 15-20 years ColdFusion will become like COBOL or ADA, where there's a bunch of code running some necessary systems and nobody knows how to maintain them. But it's a long bet for a payoff that would be much higher if you spent your time somewhere else.

Post reply on HN