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 choose exclusively among the top 5 most used in the field.
The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company.
A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.
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 was no preemptive scheduling but Erlang has preemptive scheduling so it was okay. Those details reflect they were very confident and they know perfectly what they were doing.
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?
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 names and marketed heavily => it has buzz => it must be good.
Under boring there are two types - PHP and postgres. Boring tedious and annoying and boring reliable workhorse.
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.
Well, the makers of Go took Modula-2 (which, funnily, already had coroutines), removed a number of "too complex" features like ranges, changed "begin-end" to curly braces, then added the object system from Oberon (a great move).
They bolted on two principal new features: channels and garbage collection. They also added a few hacks, like the two-value return.
And lo, we have a winner based on tech form 1970s and 1980s, with only a small bit of pixie dust from 21st century proper, the advanced GC. Anybody can become productive in a weekend. (Then the productivty ceiling is hit soon, and copy-paste programming ensues, but the initial high is strong.)
In the beginning it's selling point was small binaries and neat concurrency.
The tech was "exciting" because Google released it. Pretty much anything Google releases is coated in magic pixie fairy dust (perhaps slightly less so these days).
I mentioned in a comment below that a startup I worked for previously used Erlang. It was a giant headache. They initially used Mnesia as a database but it had issues (which I don't recall because it was before I joined). Then they switched to Riak which is written in Erlang, but was unstable at the time. They then used decided to use MySQL and Cassandra, but ran into issues because database drivers were contributed by the community and not updated.
Also, It's basically impossible to hire someone who is an erlang expert, meaning everyone has new to erlang.
Because of these and similar issues the company constantly had outages, despite using Erlang which is supposedly highly reliable.
I agree with you that Erlang usually is not in the category of 'boring' technology.
It's pretty risky for most teams. Despite Erlang was old, those ideas are both alien and novel to most people. The idioms, the patterns, and the architectures are not well explored as mainstream languages. In my personal experiences, there are also many rough edges.
With that being said, the example I raised just to illustrate that the WhatsApp founders had deep understandings of Erlang despite it was a niche technology. The same applies to FreeBSD. Those are the so-called 'boring' technologies for them.
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.
I currently see it happening with Ruby. I used it as a scripting language for DevOps tooling, CLIs, and for small web apps, but without rails.
What I see is Go pushing it out from the DevOps space and Python is more popular as a general-purpose language.
Tools that were written in Ruby(eg.: Puppet) are outdated and new tools are written in Go.
I still think Ruby is a superior language compared to Python, but because mathematicians used Python and the recent ML/big data hype it got more popular and got better libraries which caused an upward spiral.
While Ruby is the language I most comfortable whit and I don't see it going away in the next 10 years. I have to accept that first-party integrations will come later and later and there will be less third party libraries. That is why I'm currently learning Go and if anyone asks me what language should they learn first I point them to Python.
This is avoidable by continuing to use Ruby. Just continue to use it and contribute to the community, it's that easy. Ruby still has big businesses using it - Github, Airbnb, Shopify. There is no reason to believe it'll go the way of cold fusion. The language ecosystem is much different than 20 years ago. There are so many languages all thriving. Even Perl is relatively healthy and is a fine choice for doing many things in the software space.
I came out a little bit negative in the end, but as I said I don't think it's going away.
All these companies you listed using it with Rails and that part of the ecosystem is alive and well, but I'm not interested in it.
A few years ago Ruby ruled the DevOps/Cloud space(which I working in), a lot of tools was written in it, but with the dawn of containerization, its former glory starting to fade. Docker, k8s, or even the new GitHub CLI is written in Go. While I am happy to write Ruby code, I can't expect the same from my colleagues.
While professionally I don't think I will continue to use it much longer, I still planning to keep up with it. Before the lockdown, I started teaching Ruby at a local meetup group, and I can't wait for Ruby 3.
IMO Ruby is already being left behind. HTTP/2 is a good example. Rails doesn't support it, and I can't find anything recent saying support will be added soon. Java is notorious for slow innovation yet language level support for HTTP/2 as added years ago and enabled for basically every popular framework. Same with Python, C#, Go, JS.
HTTP/2 is essential if you want good SEO which makes Rails a non-starter for many projects already
That doesn't make sense. AFAIK with frameworks like Rails or Django you never expose their server directly to the Internet, you put a NGINX in front of it. And NGINX talks to the backend code via UNIX sockets, so support for it in NGINX is what matters.
And sooner rather than later you are going to need a load balancer anyway.
That's not really good enough, you will have http1.1 between nginx and the actual server. Many features require actual code framework level support, like server-side push, realtime streams and grpc.
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.
If you're thinking of learning CF, only do so with the understanding that it's now a niche product mostly used in government and large companies. Learn it either as a hobby or look at the Lucee source for educational purposes. Even my last company is moving away from CF.
About Lucee ...
I actually helped the company migrate away from Adobe ColdFusion to Lucee due to a chance in Adobe's licensing. We migrated a large, 10yr old, application and all clients over to Lucee in about 1 year.
Lucee is a nice platform but I'll warn that it's not as polished as Adobe CF and there's some difference in features. You'll run into rough edges in their documentation and language implementation (especially the scripting languages). One nice thing I really enjoyed was being able to download the source and figure out how my CF code was actually being compiled into Java. It took me a few days to understand the parts I needed but I actually figured out some issues I was having. I also was able to build Lucee from source, just for learning, which was really nice.
> YouTube was (and still largely is) written in Python, way before it was cool and well-known
That's a good point. I wonder how many successful apps used tech that only appeared boring after the fact. Rails is a fairly boring stack today but back when GitHub started, it probably wasn't.
If you know you need to cut a hundred trees to foot-long logs in a certain time-frame, you don't pick the new fancy gadget you just got from Kickstarter. You know, the one with a WiFi notification system and a cloud SaaS service etc.
You go with a regular hand-saw, axe and a proper chainsaw. You'll get your stuff done - on time and on budget. You might not get the thrill of using the latest and greatest tools, but you'll get paid.
After that you can grab the Solar/Hydrogen-powered Indiegogo-funded whizbang and go test in on a tree or two on your own time.
People use "boring" in opposition to "hyped" or "trendy", which like you said totally misses the point. I jumped on react right away when it came out, but not because of it being trendy, but because like you said I could be productive with it right way, I knew it'd be around for 5+ years and that I could hire engineers.
Agreed. I find "boring" to be an unreliable metric for decision-making in software. A boring tool could result in damage to the long term development of software if it is inflexible, for example. Migrations between tools are easily some of the most expensive technical debt costs any software organization may face.
I also agree that the better measurement of good software is that which is unsurprising. Code should be easy to follow, and the decisions for the software tools that are used should be given the same treatment. You should be able to explain your code or infra to most developers without any raised eyebrows. That doesn't make it boring. In fact, it's very interesting when a problem that looks complex on the surface can be solved by relatable means.
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 moved on to working on other things by then, I no longer enjoy writing in Python.
Wow, this sounds like the classic "I was into that band before they popular" indie snob, hah!
I was using python with SCons back when it came out, sí around 2000. I was also surprised at the statement that python wasn’t well known, but I agree that the Java web scene was much more mature. It was, however, very focused on configuration. There was nothing like LAMP getting people up and running in under a minute.
Rails was popular before anyone ever heard of Django. Rails jobs were already common when it reached 1.0 at the end of 2005 (In early 2006 a law firm offered me $30 to do rails work as a summer job off campus). Django took another couple years before reaching 1.0, though I did do work for some early adopters (0.95) circa summer 2006.
The staples of the early web, in my mind, are html and perl CGI scripts. php might make the cut as early web, but web frameworks, like those in ruby and python, feel to me me much less like the early web, and much more like the web 2.0 days.
Matts Script Archive was mid 90s. Mod perl maybe just squeezes into 'early web', I think /. used it in the late 90s.
Perl wasn't the only CGI in the early days - a large internal web application I encountered as late as 2004 had it's CGIs written in C, running on IRIX
PHP is certainly the newcomer as far as I'm concerned
Like a number of languages, PHP was around for quite a while before it really took off. PHP is probably most associated with "Web 2.0" as it became the model for web interactions in the mid-2000s.
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.
PHP silently transforming all string keys of a map to integers when they are all integer strings ("123", "456" etc.) is exactly one of the reasons I'll never choose a language that pulls the rug from below my feet and replaces it with parquet.
When you are actually coding Java -- yes. But as a sibling commenter pointed out, there's a lot of "XML as code" in the Java world. That's really hard to work with.
I haven't dealt with "a lot of XML" in Java for ages. I've been using it in my day job for a decade, and about the only XML I touch is pom.xml (that's the build file for Maven). This is like complaining about stuff in Java 1.4 -- sure, but we haven't been using it for ages.
Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counter reaction.
Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.
You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense!
You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.
Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.
The problem with judging a language by how it was a decade ago is that you're going to be left claiming absurd, outdated things. Imagine if I claimed I didn't like Java because it lacks generics, or because it lacks lambdas, or because I really, really dislike working with EJBs, or because working with Java means "working with a lot of XML" (this would flunk you in an interview, by the way).
Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook.
Imagine if I complained about Windows and the most recent version I had used was Windows 95.
That depends on what you want from the judgement doesn't it?
If you want to be able to know the theoretical things you could do with the language, I think your definition is right.
If you want to know the most likely experience you would have using the language, I think mine is right.
I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.
I am judging a technology by its amount of foot guns. That's why I am more fan of languages with only one way of doing things (and even that gets increasingly rare).
Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.
I don't disagree with you there are better languages which have learned from Java's mistakes, and I don't think I've argued it's the best one. Just that it's extremely successful, a good platform, and that programming in Java doesn't have anything to do with flinging XMLs like someone claimed.
I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists.
And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.
That gamble exists in one way or the other with any tech platform. I double dare you to take on a codebase written with NodeJS, Golang or Python without checking its sanity first. This isn't exclusive to Java.
XML as code can (and often does) work as intended.
It's much less annoying than "exciting" episodes and habits:
- let's see if our SSL certificate has been actually updated on all servers in the cluster
- let's find out what I need to restart after deploying my web app update
- who knows what the classpath loading order will be this time; if it's broken you can try a restart
- finish the test quickly before the sysadmin committee begins an application server upgrade and everything goes offline for as long as it takes, hopefully only a few hours
Not sure how what you said fixes the points you enumerated? XML as code simply wraps other people's libraries in a different DSL and if they have bugs and/or operational complexity, no DSL on top of it will change that.
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.
> 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.
TBH, this is exactly what the Java world is like. There are not many surprises in Java land. The language isn't getting fantasy land changes on a daily basis. There are libraries that haven't been updated in years because there hasn't been a need to update them - they just work. People want to leave Java because it's boring.
Is Java perfect? Of course not, no language is perfect. But, Java is the closest thing to a boring 2x4 the programming world has ever invented.
Java the language is decently boring, (although I appreciate how Kotlin has tried to advance while staying pretty boring). But not Java the ecosystem. When I returned to using Spring a couple years back, I thought, "Well, it was rough then, but I'm sure they've worked out a lot of the kinks." Nope. It had become more complicated and less reliable. I know a lot of Java-land stuff seems fine to people who live in enterprise-land, where people have a very high pain tolerance and no particular urgency around getting things done. But for me that's not the right kind of boring.
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 rails to be useful any more.
It’s fair to say you could do this same thing in C++ or Python etc., and sometimes that does happen. But just anecdotally observing this in many companies, it happens _on purpose_ with Java all the time, but much less so in other ecosystems. In other systems it’s just much easier to get things done without resorting to tons of inheritance misdirection, and many great common libraries already solve problems in those ecosystems with minimal inheritance bloat, giving lots of easy to follow examples.
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.
These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.
I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set up to do easily.
Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks.
For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )
A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.
If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems.
It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice.
Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.
> A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software.
and
> Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender.
You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform.
I'm not interested in debating your theoretical preconceptions.
Well, it really, really doesn't show. I'll have to take your word for it. I suppose your company is doing badly, since Java is really not suitable for its needs?
You seem likewise uninformed about functional programming and how it has been used to write extremely high-performance fintech systems.
No, mlthoughts2018 doesn't "seem" that way. You have decided they are, and are camouflaging your personal chosen interpretation with false objectivity.
Sorry, I'm even less interested in arguing with what you think of another user who doesn't need your help defending their point.
In any case, that Java's OOP cannot be successfully deployed for business software is counterfactual. Anyone insisting on that point is unfamiliar with Java.
> 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.
I'm not saying it's exactly a mystery. Java had the misfortune of being ubiquitous when XP and design patterns became all the rage. Every intern using Java had to learn "patterns", and schools where teaching them too. Heavyweight frameworks like Spring (and before that, EJBs( were all the rage too. It took a lot to extricate modern Java from that situation.
Yeah, boring vs exciting is a false dichotomy. Early-2000s Enterprise Java is neither - it's intimidating, because the code is so bureaucratic that it's impossible to properly understand the implications of any given action, and bureaucratic software is inherently buggy in my experience because there are so many interactions that inevitably something will trip over an unexpected edge-case of some other thing.
> 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.
Strong disagree. This is exactly what most of the Java world is like: well understood and reliable. I wonder if people who say things like you did actually use it for their day jobs, or rely on things people using other technologies claim in their blogs.
Wonder no more! Two years ago I did a 9-month contract in Java. I have used Java for consulting gigs going back to 2000. I honestly expected it to be a pleasure to work with this most recent time in hopes that things were usefully boring. That was not my experience.
Java is very similar to C++. Its boring in the sense that most things have been around forever and really old code is terrible but you still have to deal with it because backwards compatibility is so good. If you don't consider Java boring I wouldn't consider C/C++ boring either.
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 frontend and backend. Then there's infrastructure: pick at least three infrastructure as code components (Puppet/Chef/Ansible/k8s/Docker/Docker Compose/VirtualBox/WMWare/heaps of shell scripts), at least two web servers (Apache/nginx/traefik/your language's built-in server), and at least two TLS certificate providers because someone's nervous about moving everything to Let's Encrypt. I'm well aware that these don't have identical feature sets, but that's the point of the article: choosing a small and boring set of technologies is an advantage, not something to be ashamed of.
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 get Javascript/Typescript on the backend as well, so the entire stack is just JS/TS the whole way through with a single UI/design language.
It was really easy to hire developers this way and the transferable skills were high.
However you look at it, this is sort of the deal with JS these days. From a productivity and development velocity perspective, it's really difficult to rationalize using other technologies when you can just holistically build your entire stack in one JS/TS UI framework for the clients (or Flutter, nowadays) and then JS/TS on the backend too.
This is why I'm mentally shoehorned into using Typescript for everything. I enjoy it a lot, but there are other languages I enjoy too, it just doesn't make as much sense to throw them in the mix because then you've increased technical complexity and made it that much more difficult to source talent.
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 backend is implemented in.
- The backend is doing a lot of data manipulation, which TS is not very good at. For example, there's no built-in group-by function, and group keys must be primitives since TS doesn't have value equality for objects or arrays.
- Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.
- I miss clojure.spec for validating calls to external services.
Plus a few more situational reasons:
- I work in a team that's already familiar with Clojure. I don't think it's a huge barrier to hiring either; I didn't know Clojure before I joined, they just recommended me a book.
- I personally don't find that using the same language everywhere helps much in reducing context switching costs. Using different languages actually feels more engaging, especially when one is as pleasant as Clojure.
Put all these together and I'm seeing real benefits in using different languages.
Have you tried Ramda for the data manipulation functions you miss from Clojure? It used to not work very well with Typescript (lots of inference issues), but now it's gotten quite good.
You can use something like https://github.com/vriad/zod to get both runtime validation and static types (via inference) at the same time. The downside is defining your types in a DSL instead of plain TS, but I think it's worth it for the runtime validation.
It probably depends on your project, but I find type checking to be at least as crucial on the backend as the frontend (probably moreso), and being able to share types/have editor auto-complete across the whole stack is a godsend. While node isn't my favorite backend environment, it's not too bad (async/await are fantastic for io), and code sharing/type sharing makes it the most productive choice overall imho, all things considered.
Clojure's a lot of fun though, and it has taught me a lot, so I do see where you're coming from!
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.
I wasn't very clear with my earlier description; the frontend is a SPA served by Node.js, while the backend is a completely separate GraphQL API service which I'm considering to rewrite in Clojure.
So the frontend can actually do SSR to render PDFs or emails. However, it would definitely be much harder to to ensure that any phone formatting or fee calculation done directly in the user's browser matches what the API returns. So yeah, definite benefits in sharing a language there. Thanks for the examples!
Makes sense! We have the same setup. FWIW, it's nice to do the React rendering on the backend because it's a bit easier to pass values to those templates directly (as opposed to using URL params or something). We render the React to a string there, then just pass that HTML string to a Browserless[0] instance.
Certainly not a showstopper though, passing a URI is easy enough!
> Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.
We found @nexus/schema to be excellent for this particular problem, but only after you set it up correctly to feed in type information via its typegenAutoconfig options.
I agree it is less frequently helpful at catching type errors, but the errors it does catch tend to be more important to get correct than the frontend errors!
take a look at elixir/phoenix if you're considering a rewrite. The Absinthe library is excellent and well documented. I'm using it for my startup and the app is speedy as hell on minimal hardware.
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.
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 popular packages. If something breaks and hundreds of thousands of devs are impacted by it, it’s going to get fixed pretty quick. Which has been my experience in the rare occasions that in of my dependencies has broken, it’s been fixed before it even had a chance to impact me.
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
I'm currently learning Go and it's at the other end of the spectrum. Most of my apps have only one to three dependencies and one is usually a database driver. It's a really good feeling when there is something missing from the standard library and you questioning yourself that you really need that thing.
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.
It's a useful counterexample because the problem didn't exist for the 20 years before legions of nodejs bros descended upon it and bestowed upon us the mess of hot garbage it is today. At this point, there is an entire half of the ecosystem which is unusable unless you drink the 400 dependency kool aide.
To be fair though, there isn't as much good introductory resources on base R, that aren't very discipline specific.
I do completely agree otherwise, but those people will learn through bitter, bitter experience that those dependencies will break over time and will see the light that is base R.
Totally agree, I'm currently learning Elixir and it has been such a delight to work with compared to Javascript. I'm writing a simple static site generator and I've not used any external libraries yet, because everything I've wanted to do thus far has been easy to build with the functions included in the standard library.
Choose “proven” technology, or “boring” tech as the original article calls it, applies here too. Popular libraries that are embedded in multiple language runtimes are written in C. SQLite comes to mind. Choose boring dependencies written with boring integration interfaces.
> 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.
V8 (and other Javascript JIT compilers) are written in C++. Whenever you think you run Javascript code, what you are actually running is C++ code that will emulate and compile your Javascript into machine code, update the DOM with C++ code, access sockets using C/C++ code etc. all running on an OS written in C/C++. Your code is a very small percentage of the code that runs "your" application. C/C++ runs the world. Including Javascript, Python, Java etc.
There's languages better than TS/JS for back-ends. I don't mind Typescript but I only use it because some flavor of JS is mandatory these days.
The non existent standard library and pretty nutty dependency management makes JS a bad choice for back-ends. There was a article a few days ago on how Deno is aiming to fix most of this and other issues, but I wouldn't use it for a couple years.
Back ends tend to stick around far long than front ends. Every company I've worked at is still running their original back ends, some decades old. Front ends are easier to replace because it tends to be just UI stuff, not a lot of business logic. I apt to take a lot less risk on the backend. It's probably going to be around forever and customers don't have to see how crusty it is :)
While I completely agree with your _sentiments_ I think there is a conflation between choosing _the right tool_ for the job vs using 'too many things'.
I shun the unnecessary - completely with you on that.
But I'd prefer gaining relative mastery over _1 decent tool_ in each of the areas that you pointed out so that I have enough tools in my toolkit which prevent me from using the wrong tool for the wrong job. For example, I'd hate to use shell scripts to do something that ansible does really well.
A modern solution, fortunately or unfortunately, is built up of multiple smaller tool sets as you pointed out - and, if used correctly, each enhance productivity tremendously. Writing a frontend app (something that I've only recently started doing since I'm on my own) is immensely more productive if working with something like react rather than with a relatively old framework based on the jvm.
What I'm trying to say is - tech we use is ultimately a tool - we should optimise for productivity. In that case, Boring Technology helps being more productive since we know a lot more about it which makes it easier for us to bend it to our will as well as debug/diagnose the unknowns.
But it also doesn't mean we continue to use `grep` when silversearcher/ripgrep is out there in the world :)
That's the lens that I look with when I come across new tools/technologies (regardless of how long they've been around) - do they have the potential to be net-productivity enhancers over a long-ish period of time && by how much (0.5x? 5x?).
Ask them how they’ve addressed SEO. I doubt there’s a good answer. In my experience you’re better off just using Wordpress for a marketing website. It already does the vast majority of what a marketing website needs. Now, a rich web portal/SaaS product is a different story. Choosing the right tool for the job only comes with experience.
You could suggest them to use React/NextJS, but publish a static export (yarn export) which is the buildtime compiled HTML+CSS+JS from react, but without needing anything else.
Works well for static pages, this is what I did so II could use next/react and deploy to a boring LAMP server we have for our landing pages.
Don’t do this. I’ve just been through the process. Trust me. For a marketing website just use Wordpress and save your time for something more valuable.
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.
Most of these things are actually necessary, though. Other than the frontend framework and language, basically all of those layers have been required for decades. You literally can’t make an “app” without either a frontend or backend language.
You're saying exactly what the message above states - either, or. It is totally possible to have a boring JS stack, or a boring Ruby stack, or a boring Python stack. And for most of use cases, that is more than enough. One of the best examples is Basecamp, but only because it has a very strict frugality around technology, which, as we see, pays off in the long run.
Sure, but what I was trying to get at was that it strikes me as very weird to count “CSS” or “a load balancer” or “a backend language” or “an SSL certificate” in a list of examples of how web development stacks have gotten out of hand.
CSS in itself is not getting out of hand. Supporting LESS, SASS and Stylus and vanilla CSS in one project is getting out of hand. Same for everything else.
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 this is real. I have dev friends who have left great jobs just because they wanted to move to some new tech and their company simply wasn't ready for the change yet.
In the past I have been told that I "don't trust developers" (despite being one myself), and it has nothing to do with that. It's that some of us are left with the consequences of those decisions and having to maintain those NIH-riddled skeletons in the closet when those individuals leave - and the next person comes along, finds the skeletons and we end up having to rewrite/reimplement that whole part of the system.
Creating an environment where we can thrive and be creative is really challenging. We've implemented the 20% time now where everyone in the company has 1 day a week to just experiment and do whatever they want, just to give the breathing room to be creative and try some of these new technologies. We finally got there. But for years, we just couldn't afford to do it as we were in survival mode.
But the retention issue is still a big one. I feel the tension between having to empower people to make decisions that are for the greater good of the business, while balancing that those people can (and will) leave at any time and not face the consequences of those decisions.
>"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."
That's fine, let them go. There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home. The stack doesn't really matter. The "mission" doesn't really matter. Even the product barely matters. I've found that people who are leaving a job for the new shiny thing are either very early career, or the dilettantes who leave behind messes to be cleaned up by professionals.
Massive companies have been built around a Spring/Rails/Zend monolith with a few jQuery plugins on the frontend. Anyone who thinks they need more than that is probably wrong.
>There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home.
No there aren't, in fact there aren't plenty of "great" (or pick any adjective related to competent) devs in general, so if you're a small shop and can't compete on wages, work conditions (tech stack included) is your only competitive edge. Because you know what there is plenty of ? Enterprise gigs that need competent people to maintain a legacy cash cow or business backbone - and working in those environments has competitive advantages compared to working in small companies - corporate pace is usually 1/2, company stability, climbing the corporate ladder - if you're a 9-5 guy these things mean a lot. Even those places need to mix in flavour of the day tech to keep their devs from leaving the mind numbing work they feed them.
Yes, there are. Such a ridiculous statement to think people can't be great at something just because they don't tick some arbitrary box you came up with for evaluation.
If that's the case, then there are no great 9-5 anything... but the odd thing is, I've met plenty of them.
You aren't getting what I'm trying to say - the market for competent 9-5 is also missing developers - it's not that there aren't any - it's that demand > supply - which is why OP is worried about his employees leaving - it's not like he can go out there with a job posting and have 5 competent applicants in a week. You will have to pay recruiters serious money and hope to get lucky on competent leads - so "there are plenty" argument is BS.
Just like your argument, which pulls claims out of thin air. You haven't made any points at all, simply rambled about competence without backing anything up.
I've learned more often than not, that when someone claims "competence" what they're really saying is "I'm not finding the exact skills I'm looking for, which are hyper-contextualized around the problem I'm currently facing, at the exact moment I need them at the cost I think is best. Which will change in six months, at which point a different cohort of people will be labeled incompetent."
Can I be honest? I fucking hate developers. We're like magpies of the worst variety. How many times have I had to argue against bringing in ${NEW_TECH} or ${NEW_TECHNIQUE} because it would be more trouble than its worth. No, it doesn't look as cool engineering-wise, and yes, our work may be a little harder because of it. But then they win the argument and we implement it and hey! Those problems I told you about? They're real! And if they had done it my way we could have moved on to the next thing and not had to worry about this.
Fuck the latest thing. Fuck resume driven development. Fuck magpies. Choose the boring path. Fuck developers!
The worst thing we do is obsess over the latest, coolest tech. Everyone is stepping on their brothers and sisters in this field because they want to be the loser that invented ${NEW_TECH}. We spend so much time optimizing for 'developer happiness' (a.k.a. the new shiny thing) that we forget about architecture.
Why would you say something so controversial yet so brave?
Developers may be the least humble type of engineers. There are many great things that we do, but we need to be taken down a peg every once in a while. Many developers are forced into this mindset out of fear of our marketable skills being made obsolete so I understand why many do this, and it is a compounding problem. Developers seek out jobs with the shiny new technology or push for their company to adopt it to be able to show that technology on their portfolio, then there are fewer positions with the boring but reliable technology and even more are forced to adopt the new technology.
Is that fear real though? I mean there are still job listings for VBA or ColdFusion engineers if that's really your thing.
I think our problem (and my our, I mean American) is that we are too obsessed with tech. This is coming from someone who grew up obsessed with computers, and not just writing code. You can tell this is true from looking at our ads, which are always touting the shiniest newest technological marvels. Even beauty products -- they sound so sciency without actually saying anything. Tech is our dogwhistle.
My father-in-law who is a 58 year old software developer feels stuck at his current job because he has spent so much time on old and archaic technology that he doesn't feel confident enough to be able to go out there and get a new job in case he's laid off.
Personally speaking I spent far too much time working on a certain technology for four years and I felt trapped because getting a new job was difficult in new technologies.
There are clearly some Evergreen Technologies such as C/C++, but there are a lot of Technology switch don't land in that category and they evolved fast (js ecosystem for instance).
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.
IMO giving Engineers “space to learn” and “work with new tech” is one of the greatest challenges any Engineering leader faces. I have a pet theory that the soa/micro services trend has in large part been driven by this problem - giving a space to work with such new tech with a limited blast radius, also at the expense of overall velocity and maintainability.
If you are early stage start-up, all your employees including engineers should be onboarded with the idea rather than technology choice. If you have someone joined you for any reason other than the excitement for idea, there is higher chance that you will find them going off track too often and it will drag you back
If you are mid-size company, I will assume that you can afford giving some breathing space for everyone to explore but still focus on the goal. You should ideally retain them with the culture.
These are the suggestions based on my experience. I may be wrong.
There are also small software companies that are not VC-funded startups with flashy ideas — e.g. small bootstrapped consultancies and niche software shops.
In these companies you still have to hire developers for reasons beyond excitement for The Idea.
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.
Ironically I was watching a talk on youtube yesterday by Richard Feldman of NoRedInk[0] that was basically explaining why and how they implemented Elm in production. The most interesting part of the talk to me was how he said it shaped their recruitment pipeline, going from needing recruiters to basically having it full and they can take their pick, and this mostly due to the fact that they were willing to use newer technology stacks. So the long and the short of it is I think you're right, this would affect retention and probably recruiting as well.
I'm a new developer looking for my first job and so I'm making side project to learn in the meantime and what I primarily want from a job is the ability to increase my skills, to get better and to improve, I feel like the kinds of places that are willing and able to experiment will not only have more of a learning culture but will attract others like that as well, so they are more attractive to me as a developer. I imagine this could be countered by things like proper mentor-ship programs or side project time like you've already implemented.
Be happy to see them go. They are the wrong developers for you to employ. Their focus is all about self-indulgence and not on creating a viable long-term business. Don't ever hire anybody who calls them self a "ninja developer" or equivalent. Instead, ask them to send in their CV again when they are grown up.
I'm against letting juniors or random devs introducing stuff you don't want to maintain in to your codebase for the sake of using the latest fad tech, chances are they will leave anyway and you will be left holding their mess. If they know what they are doing (ie. you hired someone with experience in stack Y and they want to help you migrate) then I'd say go for it if you can afford it. But picking a "safe but boring" stack puts you in the same hiring pool as everyone else picking that stack - can you compete on other terms to attract employees ?
Let's say you decided to write a webapp a few years back when RoR and AngularJS/CoffeScript was the popular stack. You wanted to write it in Clojure but you though "I can't hire Clojure devs reliably and RoR is popular so let's go with that". You are a small business/not high growth - you grow your app steadily - you now have a sizeable codebase on a legacy code stack that nobody really wants to touch or learn, there are plenty of job openings on that stack you have to compete with. Meanwhile people enthusiastic about Clojure were probably above average developers who would be happy to take below market rates just to work on a stack they enjoy and you could easily find people even today.
In a market where demand outpaces supply I'd say the "safe stack" is not a correct choice for small companies - if you have the know-how to pull off something more cutting edge. If you don't then ofc. use what you can to get the job done.
You cannot ignore all progress, but not all motion is progress.
Technology selection is a very underappreciated and largely unreported skill set.
I think it relates to the Principle of Least Surprise. You can pick tech that has a lot of upside and isn't riddled with gotchas or demanding of eternal vigilance, or you can pick stuff that makes you feel like you're alive all the time.
The latter is risk-taking behavior. It's thrill-seeking. Several other replies exhibit disdain for this behavior, as I think we all should. These people are risking your company for cheap thrills. As one responder puts it, fuck 'em.
Ask them live support your app, esp code they didn't write. Or some kind of dev log from the ops people hunting down their bugs. Tricky fun frameworks then become a pita.
I am in the same situation as you. My plan is to build the best personal growth organization that I can. Developers who value that and long-term growth should want to stick around. Developers who want something shiny can look elsewhere.
I've boot-strapped and lived from a web-application for over ten years, some of which have involved less than one day per month's worth of work. I credit this to boring technologies.
Looking back, the best technical decisions were:
- using an SQL database with lots of constraints and foreign keys and indexes. It's like typing for data.
- emphasis on shell scripts and leaning on UNIX features (since these continue working in ten years rather than being abandoned)
- deleting as many libraries and dependencies as practical (over a ten-year time frame, 80% will disappear or change in ways that require huge mental RAM on your behalf)
- a preference for paying for hardware to solve performance issues (vs. complicating the code with fancy solutions)
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, PostCSS, TypeScript, React, Redux, RxJS, to be rather exciting, and that's only a few of the exciting parts of a mature SPA project. And of course this doesn't touch REST, GraphQL, CI/CD, testing, metrics, telemetry and all the other excitement.
So, yeah, I would say that if you take the article seriously for a webapp, you'd limit yourself to a really boring Java (8) server-side architecture using Jetty, JSP, Spring, a service layer, over Postgres. Maybe an nginx proxy if you want to get a little spicy and have good SSL and static serving performance, and an option for simple load balancing later. Oh and the only provisioning you get to do is individual VPSs or even better, bare metal on prem servers! Git and Jenkins is probably boring enough to use, though.
But yeah, no Docker, K8s, OpenShift, no AWS other than EC2 and maybe S3. Probably no CloudFlare. Google Analytics, sure, but only if you don't care about your users privacy. Sentry is too exciting.
And then on the HTML side I'd argue that your templates should produce plain old HTML5, CSS3 and ES6. No transpilation, no source maps. No official support for IE 11. And even for those languages you can cut out the most exciting features. Do you really need the "class" or "new" keywords in ES6? For JS modules, use the boring, built in browser module system (you knew it had one, right?![1])
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 more overhead than using something more experimental like Elm or ReasonML.
You should almost never use classes in JS, but when you do, they're much easier to work with and understand than defining properties on the prototype. The "new" keyword has been around since almost JS's inceptions (it's available in IE 3, which came out in 1996).
Some of your technologies require no learning to start using (PostCSS). Some can require a whole new mental model/programming paradigm, but can be incredibly useful if used sparingly and in the right places (RxJS). And some things you just need to do to not have a garbage application (testing).
Look, just make assessments as to what your needs are, what are common practices, what your current team is capable of being productive with, and what you're going to be able to hire from.
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.
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 clients love it. I am 100% in the camp of “users don’t give a shit how the sausage is made”, but I constantly get praise on how “smooth” the UX feels. I know there are SSR technologies (eg Turbolinks) that can emulate this, but at this point I’m having a hard time justifying learning them properly and risking missing out on that maybe superficial, but addictive, customer praise.
- It is indeed what I know best, so what the hell...
I believe a competent web developer should know both SPA and SSR and apply what best fits the requirements at hand, but I can also appreciate why devs form biases one way or the other and how this has become a hotly contested topic, and I think we may still be in the same spot in three to five years.
It depends on the project. I’m way, way more productive with a React frontend environment (webpack, babel, tailwind, next) when working with handcrafted designs. Even when the interactivity is trivial. And I know from experience that interactivity inevitably becomes more involved very often.
One key feature is that JSX works on both the frontend and the backend.
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 for all of those areas, but it seems to me that in every React project I work in, "use React" is the easy part - it's the 50 other decisions that need to be made as a consequence of that first easy decision that waste a lot of time and energy.
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.
If you're just wanting to get your feet wet create-react-app is the right choice. Go strictly by their docs: they do a good job of leading you to third-party solutions when required.
In a way React suffers from it's own popularity. For example Next/Gatsby can be confusing for new developers but they only exist because React is popular enough to have meta-frameworks focused on solving specific use cases.
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'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").
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.
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!).
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!
If you’re primarily, say, a Python/Django developer, then I can see how adding React is spending innovation tokens i.e. only do it if you have to (even in 2020).
However, if you have React devs in your team, then this is NOT spending an innovation point at all. The same would hold true for even MongoDB here.
Also: please, please pay attention to the fundamental design decisions that underpin the technology you're choosing!
Set aside the GitHub stars, contribution graphs and HN reviews, and boil the tech down to its fundamental principles. Then ask yourself how a perfect implementation of that design would solve your problems. It it solves them well, you're golden as long as the project is reasonably healthy. If it doesn't solve them well, you might be setting yourself up for serious pain down the line, and need to make a very conscious choice about whether the short-term benefits of that technology choice are worth it, and how an eventual migration to a better-fitting design would look like.
Job description these days become reflection of complexity in new age tech stack. Know C++/Java/Scala/Enter_Your_Lang_Here with python and React/Angular/Blah/Blah with Big Data Technologies - Hadoop, spark, etc. with Docker/K8 and with Azure/GCP/AWS.
It is time consuming process to become expert of one thing, requires couple of years of continuous focus.
I don't know How many people are actually expert of all these and how they are going to perform when some issue pop up in production. Try that judging it 30-to-60 minutes of interview.
Almost no one. And you don't need an interview for that.
As you said, it requires a few years of continuous focus.
And most jobs won't give you that. So it's even more time.
And if a person with 5 years of experience sais he is an expert in a,b,c,d,e you don't need an interview do understand that this person doesn't even know what it takes to be an expert in one of these, because he obviously can't evaluate his skillset properly.
Nowadays you need very little to qualify to be "expert" or "senior".Sure there are exceptions, but in most cases, all you need is be able to use the technology. In most cases, people don't even understand how it works under the hood.
Just like with full-stack developers. Most of those whom I have seen know some front-end, some back end, and very basic database knowledge. And considering that in these cases both front-end and back-end are written in js mostly, "full-stack" here is a huge overstretch.
As lot of businesses do not reach that scale where architectural or design or quality issues may pop up, "full-stack" devs keep moving the wheel. I think that is good enough and good enough is OK.
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 gone. Making modern web apps is a team sport. You literally can't be an expert in everything you need to build a robust, scalable, fast, accessible web app anymore.
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 complexity. An idea or poc which could had been easily done and tested in market with small techstack/small team. No wonder lot of these products fail.
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.
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!"
How many people had rented servers for games? A lot. Now video game companies have turned game servers into a SaaS, whereas then they just released Linux server binaries. In the early 2000s there was a bare metal server rental company on every other street corner.
How many people had Linux/BSD network appliances? Also a lot. There was such a time when all you got from the cable or telco for your broadband service was a modem, and you had to roll your own router/switch. There were a multitude of run-from-a-floppy (or USB stick) BSD and Linux router distros back then.
Also, you're not correct on PHP. The entire reason PHP grew so wildly was because it was server side rendered, and both AOL and Microsoft intentionally hindered their browsers' javascript capabilities in lame attempts to monopolize the internet.
Sure you can, if you reject libraries and tools that were designed by large companies with a ton of specialization to serve the needs of those companies.
If you want to be effective as a small team, choose tools built for small teams. Rails is a great example.
One of the more frustrating things is that you can have a team that reads this article and all agree about the goal but disagree about what is actually boring and safe and worth doing.
There are a lot of people who confuse “boring” with “well-known”, and they’re not the same thing.
Example: you decide to write C++, but the C++ you write looks a lot like C99. You rationalize it as though you’re avoiding the overhead of all that nonsensical modern C++ and doing the simpler and thus more-boring thing. In reality: you’re writing shitty C++.
For the technology you choose, you should buy into it. Full stop. Don’t half-ass it.
Your example is controversial. What if that C99 coding style is company-wide accepted and everyone is comfortable with it. On contrary, newer, more shiny thing, like c++20 is not supported in tools and adds significant mental overhead.
I think the problem is that not all programmers are motivated by successfully building things.
Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to.
If you pick a 'boring' technology, you have less of those two things, and you are stuck with boring process of developing one feature after the other with boring technology until sufficient number is developed and you can go do something more interesting.
I believe you are correct, at least judging by myself and several others I've talked with. We are creators and get bored of our creations pretty quickly. In that regard we aren't unlike painters or even book writers; something sparkles our interest, we work on it for a while but then we get tired of it and really want to do something else.
That can easily be seen as unprofessional from the outside and I'd agree you shouldn't conduct yourself like that when there are money involved but that also leaves something to be said about the productivity of the tools we work with.
> I think the problem is that not all programmers are motivated by successfully building things.
> Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to.
I kinda realized this about myself recently, and now I'm wondering if I need to leave the field.
But in all seriousness. Software development does not only need builders. Builders build stuff well but at some point they make mistakes or overestimate their knowledge of technology. Then obsessive learners and investigators are godsend.
Just know your limits and don't hope to do well at solo projects when you are in it for learning or bug hunting.
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 really want/have to `ship it`, pick any technology you and your team have delivered something before.
When you have time to explore, pick any new shiny technology, and concentrate on learnings.
I'm literally browsing hacker news right now to procrastinate work on an Angular task. I can't think of a less boring technology, I've been writing it for a couple years and it's still not simple to work with.
Switch to React if you can. I've been using Angular for years and the solution to problems is generally "more magic". Its so convoluted these days I don't think its even realistic to build an Angular app outside of angular-cli.
I like ionic a d it deffinitely is better than plain Angular. But Ionic is VERY immature technology: they keep moving the goal post and changing things. The latest version again changes crap with the replacement of Cordova.
And if you search their forums on how to do something (like take a video in mobile and then showing it on the ui) it depends on each version and there are no clear answer.
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.
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.
I am all about the boring technology. I dislike the churn of learning something only to discard that knowledge in favor of something else a few months later. I would rather get better at the things I know how to do rather than learn how to do something new and hope to get proficient at it. It feels like time wasted, learning something that I know is disposable.
I get it, in the end everything is disposable but I like to minimize that churn and polish what I have that works for me. It isn't as fashionable or as cool but I try to avoid those circles if I can.
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.
I actually get why engineers, especially young ones prefer new techs sometimes.
Think it this way. You join a company and get two choices. One is to use a reliable albeit old system, read tons of legacy code and figure out how to do things other guys' way. The other is to build new things from ground up when you have a much bigger feeling of ownership, but risk breaking things up.
Which one do you choose? Note that you are a junior engineer, not a lead, not an architect.
Somewhat this is more like a class struggle instead of choosing the right tech.
This is something I've lived by for the majority of my career. I wish I could share in the excitement of my peers when they discover a new shiny thing and push really hard to have it incorporated, my inability to share in that excitement has even shaken my confidence at times. What's worse is that it has resulted in friction at some of the places I've worked, even more so when the issues I've raised end up biting us hard in production.
The most recent MVP I created: CakePHP, MySQL, jQuery (UI/UX called for minimal dynamic UI IMO), and bootstrap. Very boring full-scale MVP released in under three weeks. I designed as client-server in case the need arises to go SPA with React down the line or go with a mobile app option, but I doubt the need.
Non-tech co-founder was worried from what he read on PHP etc.... Non-tech co-founder is not worried today.
If I use APL and Lisp, does that count as spending innovation tokens? Is boring technology old, or is it widely used? Most people I know don't consider J, kdb+/q, Haskell, or OCaml boring, but they are all awesome industrial strength languages/technologies.
Boring is boring---i.e., no surprises. Whether it's been tested by a lot of other people, a lot of years, or even just a lot of your time. APL is not boring to me, but it might be to you.
I’ve found boring in this context to be a function of 3 things (in no particular order):
- Your experience using the tool in question to solve this problem or very similar ones
- Your teammates’ experience using the tool in question to solve this problem or very similar ones
- The world’s experience using the tool in question to solve this problem or very similar ones
The specific drivers of this tend to be a mix of problem-solving pattern matching ie “Hey, we know what the usual suspects are know when things are slow/crash”, and ecosystem robustness — what is the probability of you being the first to trip a bug in a dependency / has a library been used to solve 10000 problems or just 3 — It’s more likely that APIs have been sorted out, bugs have been closed, etc. or that your team knows the quirks.
As an example, OCaml might be a relatively boring choice for writing a theorem prover, but for something like a RDBMS-backed web application, things are a lot more “interesting” as you go off the map much sooner.
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 found that they call a collection of Linux containers a dyno. So we have droplets (confession: never used these), pods, clusters and now dynos. If nothing else, should we not at least standardize the vocabulary?
“Droplets” as in DigitalOcean? Those are literally just single virtualized servers — nothing fancy or property happening there, despite the cutesy name.
I still stand by everything I said in that comment, and it has served me incredibly well on every project I've worked on since. At least in the cases where I followed my own advice :-\
tl;dr: if you're trying to build and ship something quickly, don't use any new technology. If you want to use your project as an excuse to learn a new technology, limit yourself to only one technology so you can better isolate issues when they crop up.
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 you’ll lose when it breaks, use something solid to build it.
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 company's frontend code and its 14Gb of source code for scripts to make the tooling work in such monstrosity.
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.
There are more Java and C++ and Python jobs than Go or Rust or Typescript jobs, and I doubt that will change in 18 months.
By the time new languages become the new industry standard, most developers will have had plenty of time to learn them. I've never heard of an industry change that happened so fast that it made the majority of working programmers obsolete in 18 months.
I think the lesson here is "don't be a commodity"?
In this light, PHP coders are real commodities. They are paid lowly, treated as expendable, and get no respect by peers. I think they're going down the same path of "HTML experts" which were once lucrative business in early 1990s.
Java/C++ programmers fare better because (I guess) there is some fundamental difficulty to be proficient at them. So, despite being old and boring, being good at Java or C(++) is still a good business.
Learning Go/Rust is another way to avoid being a commodity. Although they have a smaller job market, employers need to treat you with respect, because they can't easily find another worker with a matched skill in the market.
Java and C++ aren’t popular because they are difficult to be proficient at. They are popular because they fit the needs of enterprise software better than other languages, and enterprise companies committed to them a long time ago and have huge amounts of software written in those languages.
PHP devs make good money, maybe not what their peers in "good" languages make, but a good Senior PHP dev is making six figures in most markets these days.
I guess that depends on your specialization. If you build backend services with Java or C++ the job market is pretty big. Probably bigger than if you're a Go expert but don't know Java or C++.
The risk of this attitude is that you may never get enough experience in a technology to approach expert level. If we're constantly reinventing the wheel, it means we never really have a chance to use that wheel to go anywhere.
If you do something like Java you can find jobs just as well today as 10 years ago. Another good thing about boring technology is that it’s less likely to be dumped for a shiny new toy once people realize it wasn’t a silver bullet
It's funny that he mentions Rumsfeld, without mentioning Rumsfeld's very public glaring omission that was ultimately responsible for everything that went wrong in Iraq.
He cited "known knowns", "known unknowns", and "unknown unknowns", but completely missed the biggie, unknown knowns -- things you are convinced are true, but in fact are not.
"It ain't what you don't know that gets you. It's the things you think you know that just aren't so." (Often mis-attributed to Mark Twain, but Josh Billings is a better choice.)
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".
I like to learn new things and solve new problems, but "Don't fix it if it isn't broken" are words to live by. Challenging myself with a new problem is rarely boring.
So many new technologies seem like something new just for the sake of it. By the time they mature into something as practical as 'boring tech' they have many of the same pitfalls if not more.
Perhaps many engineers lack agency in choosing the problems they solve, so they seek to change the tools they use instead?
I'm constantly invoking this principle, but I have a small tweak: combine it with the (now anachronistically named) Python Paradox to get "use a tool from your toolbox".
Restricting the number of different technologies in your toolbox gets you most of the benefits described in TFA. But contrary to "boring", it's actually preferable for some of those tools to be bleeding edge. That way you also get to enjoy the benefits of the Python Paradox.
Of course, you need to have good enough taste to pick new techs, and sometimes the bleeding edge will cut you. But because you amortize that cut over the whole org it doesn't hurt much.
> you need to have good enough taste to pick new techs...
So you see tech as you see fashion, i.e it requires good taste?!
When you choose a new tech, perhaps you should consider what problems it solves and whether its costs are worthwhile for you, not whether its a hot new fashionable thing to "wear" in parties (conferences).
Having to build stuff from basic blocks with no hidden magic is the best part in Go.
It's SO boring, but also very efficient. Yes, you type more words, but that's why you got the fancy clicky keyboard.
You get stuff done and other people can actually understand your code, because there are no hidden gotchas, everything is just as you typed it out. Even the boring and repetitive if err != nil stuff just fades away, but you DO notice if it's missing somewhere.
There are many parallels here for the selection of medical drugs and implants.
Use treatments with a good evidence base, predictable outcomes and known complications (preferably with known solutions).
Don't insist upon the latest new treatment, unless you fully accept the rôle of guinea pig - for better or worse!
This article reinforces one of the most important lessons I’ve learned as a developer - be careful, even suspicious of shiny new things - only after the sheen has faded after extensive use and they no longer are the new coolness is it usually safe to consider them for anything other than a toy project.
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).
I definitely wouldn't put Go and Rust on the same basket. Go is definitely boring at this stage (as in, it's proven and widely used - everyone knows its problems etc)... But Rust is still evolving, specially its libraries (if you follow the Rust ecosystem, you'll know what I mean), and I am not aware of it being used for lots of critical projects (though it's popping up everywhere where innovation is not frowned upon).
Rust may be “hot” but there are far more Java jobs than Rust jobs and I highly doubt that’s going to change anytime soon. And indeed Java developers have been highly employed for quite some time.
Yeah, every time I job hunt it’s 10x the enterprise Java opportunities (don’t really want those) versus Ruby, Go, and even native mobile. I don’t have .net in my work history but gather it’s similar for that. Between them they’re a huge percentage of all software dev jobs, writing boring bigco software for bad-for-FAANG-but-good-for-everywhere-else pay.
[edit] oh and the small/startup space is overwhelmingly Node + some front end framework + a bunch of cloud shit they probably don’t need and have mis-used and mis-configured. Take out Node, .net, and Java and hell, the next biggest segment I see is probably low-paid PHP (Wordpress mostly) work followed distantly by Ruby (mostly Rails, ugh), Python, and native mobile. Go, Rust, Haskell, Clojure, all that, rare as can be.
I've found in general the places that use Java don't look for a Java developer. Its like they just assume you can pick it up. You might see things like knowledge of OOP, SQL, etc. on the job listing. For example, lots of large companies like Google, Microsoft, Amazon, Twitter, Netflix, etc. have a ton of Java, but their job descriptions don't really mention it.
On the other hand, if a place needs Typescript, or GO, they'll mention it.
I think job descriptions are just marketing materials for developers at a lot of places. Advertising your COBOL just gets you people that want to make more COBOL.
Every job I take, whatever the oldest crappiest technology mentioned in the footnotes is, ends up being 90% of my job.
Sure. If I want to only work with the hot tech then yes, my choices are limited to companies using hot tech. But the reality is that the vast majority of development jobs are using the old standbys.
I was curious about the relative time range, when something is considered "hot", and how long it takes to become "boring". Looking up the public release dates..
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...
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 choose exclusively among the top 5 most used in the field.
The key thing here is to avoid surprises, unknown unknowns. You won't have the time to learn from a novice level while building a new company.
A number of wildly successful MVPs were implemented with obscure (or then-obscure) technology which authors knew very well, and which boosted their productivity. ViaWeb was written in Lisp. YouTube was (and still largely is) written in Python, way before it was cool and well-known. The initial Rust compiler was written in OCaml.