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.
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.
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 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
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.
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.
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.
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.
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.
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.
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 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).
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..
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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!
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.
> 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!
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?).
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.
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.
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.
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.
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.
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.
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) ;)
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.
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.
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.
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 popular meta-frameworks focused on solving specific use cases.
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.
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!
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'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).
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.
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'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.
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.
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.
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.
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".
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).
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.
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.
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!
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.
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.
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.
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.
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).
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.)
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.
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
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.
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.
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.
296 comments
[ 3.2 ms ] story [ 217 ms ] threadhttps://news.ycombinator.com/item?id=9291215
A related page I recall seeing on HN last summer:
http://boringtechnology.club/
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.
The company I worked at previously used Erlang. It caused a lot of headache in terms of finding well-supported database drivers and things like that.
There are three classes of companies: ones who haven't tried having a buffet of technologies, ones who already have and ones who are recovering.
https://boards.greenhouse.io/spacex/jobs/4747757002?gh_jid=4...
https://expatsoftware.com/articles/happiness-is-a-boring-sta...
If it’s Somebody Else’s Money paying for the development, go nuts with whatever crazy tech their 19 year old CTO wants to roll with. Hopefully they have a VC holding the bag to subsidise the ride.
But when it’s your stuff, and it’s your weekends you’ll lose when it breaks, use something solid to build it.
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.
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.
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.
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.
TypeScript and Go and Rust are the hot ones now and they were barely on the radar a year ago.
Ofc I am inserting them into work projects as I need to learn them.
On the other hand, if a place needs Typescript, or GO, they'll mention it.
Every job I take, whatever the oldest crappiest technology mentioned in the footnotes is, ends up being 90% of my job.
[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.
Listed as "boring":
- Postgres 1986
- Python 1989
- MySQL 1995
- PHP 1995
Relatively "hot":
- Go 2007
- Rust 2010
- TypeScript 2012
- GraphQL 2012
- React 2013
Edit: Oh, it needs a (2015)
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'll take ye old PostgreSQL (with JSONB if I need unstructured data) or even mariadb.
Previous startup I was at had a stack like this:
- Frontend: Vue + Typescript
- Android/iOS App: Vue (NativeScript/Capacitor) + Typescript
- Backend: Node + Typescript
- Database: Postgres
- Deployment: Everything in Docker containers
I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you 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.
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.
I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.
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.
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.
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.
It's as far a way from a general-purpose language as it can get while technically still being one, in both scope and intended use/audience.
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.
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.
I think the more powerful benefits are definitely hiring and having a team that can work on both sides (and in that regard I think your points are perfectly reasonable), but there are definitely some more direct benefits in our case.
[0]https://support.stripe.com/questions/passing-the-stripe-fee-...
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!
Certainly not a showstopper though, passing a URI is easy enough!
[0]https://docs.browserless.io/docs/pdf.html
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!
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!
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 :)
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?).
I gave in because they are having fun and it looks good, but it could have been done in static html (maybe using a generator) way more easily.
It hurts me everytime I‘m thinking about it.
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.
Especially long term wrt security
The amount of stuff you can ram into a front-end code base is truly insane.
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])
1 - https://caniuse.com/#feat=es6-module-dynamic-import
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.
is this still a valid concern as of today ?
There... that's the problem.
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) ;)
That said, with recent and planned advances in CSS3 (and free of the IE shackles :) ), CSS preprocessors surely are slowly going the way of JQuery.
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.
One key feature is that JSX works on both the frontend and the backend.
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.
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.
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.
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 popular meta-frameworks focused on solving specific use cases.
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.
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!).
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!
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?
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.
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).
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.
300kb is a lot, but it's also a huge framework.
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.
It might help if you stick to one version until shipping something meaningful
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.
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.
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.
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.
Wasn’t any Ansible then, either, you had to write your own damn scripts.
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:
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.
If you want to be effective as a small team, choose tools built for small teams. Rails is a great example.
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.
To use/apply any tech or workflow depends on execution.
And I've seen it happen a couple of times.
Unproven technology has all that in spades.
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.
I agree with you on just about everything, but python was well-known well before YT. Django was a staple of the early web.
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
But seriously, the dynamically generated content of the early web was cgi, perl, later some python (as in scripts, not in django)
YouTube founded February 14, 2005
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!
ASP was also a favorite of the early web.
http://www.paulgraham.com/pypar.html
Seems like Python is now in the camp of Java now given the current trends.
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.
* 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?
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.
The 2nd type is my favorite type of tech.
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.
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).
Tech like postgres doesn't get that kind of hype.
Dart didn't make any impact till flutter was launched.
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.)
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.
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.
It's even biased the wrong way, tech does become outdated at some point and best avoided, but "mature" only increases with time.
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.
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.
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.
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.
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.
I am thinking someday Crystal post 1.0 would be able to put up a fight in that space.
HTTP/2 is essential if you want good SEO which makes Rails a non-starter for many projects already
And sooner rather than later you are going to need a load balancer anyway.
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.
[1] https://www.php.net/manual/en/language.types.array.php
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.
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.
I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for.
This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up.
The downside is that, the merits used may differ a bit between markets or industries, but I'm personally ok with that.
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.
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.
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 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.
It's much less annoying than "exciting" episodes and habits:
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.
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.
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.
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 )
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++.
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.
You seem likewise uninformed about functional programming and how it has been used to write extremely high-performance fintech systems.
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.
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.
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.
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.
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.
How could you have known that right when it came out?
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.
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.
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.