10 ms·

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 (

by l0b0 6y ago

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.

gavinray 6y ago
I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you 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.
- mettamage 6y ago
  Seconding this. I have the same experience.
- deleted 6y ago
  [deleted]
- choeger 6y ago
  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.
  - winrid 6y ago
    Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.
  - speedgoose 6y ago
    If a NPM package requires a C++ compiler, I ignore it and move on.
    - mbrodersen 6y ago
      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.
      - speedgoose 6y ago
        I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field. I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.
hackeryogi 6y ago
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?).
jakelazaroff 6y ago
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.
- arsenico 6y ago
  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.
  - jakelazaroff 6y ago
    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.
    - arsenico 6y ago
      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.
      - jakelazaroff 6y ago
        Who is supporting all of these things in one project? I’ve literally never worked on a project that’s used more than one CSS preprocessor.
ashildr 6y ago
The young people in my company made sure our webpage is a react app. 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.
- agustif 6y ago
  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.
  - bottled_poe 6y ago
    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.
    - agustif 6y ago
      It works for me, already shipped. A bit late for the advice I guess. Use what you know?
      - cutemonster 6y ago
        Works for me too -- for me, Gatsby or Hugo etc are quicker and simpler than WP Especially long term wrt security
- bottled_poe 6y ago
  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.
BigJono 6y ago
I fucking wish this was the extent of the web stack madness in half the places I've worked. The amount of stuff you can ram into a front-end code base is truly insane.
johnchristopher 6y ago
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.

by l0b0 6y ago

gavinray 6y ago

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you 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.

mettamage 6y ago
Seconding this. I have the same experience.
deleted 6y ago
[deleted]
choeger 6y ago
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.
- winrid 6y ago
  Well, in my experience you cache those dependencies via something like jfrog. That helps. But yeah, dependencies require maintenance.
- speedgoose 6y ago
  If a NPM package requires a C++ compiler, I ignore it and move on.
  - mbrodersen 6y ago
    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.
    - speedgoose 6y ago
      I do trust the C++ of V8 and NodeJS because it's used by many and well tested in the field. I do not trust a random npm package with C++. C++ is way too level and insecure and it's not worth it.

hackeryogi 6y ago

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

jakelazaroff 6y ago

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.

arsenico 6y ago
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.
- jakelazaroff 6y ago
  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.
  - arsenico 6y ago
    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.
    - jakelazaroff 6y ago
      Who is supporting all of these things in one project? I’ve literally never worked on a project that’s used more than one CSS preprocessor.

ashildr 6y ago

The young people in my company made sure our webpage is a react app. 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.

agustif 6y ago
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.
- bottled_poe 6y ago
  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.
  - agustif 6y ago
    It works for me, already shipped. A bit late for the advice I guess. Use what you know?
    - cutemonster 6y ago
      Works for me too -- for me, Gatsby or Hugo etc are quicker and simpler than WP Especially long term wrt security
bottled_poe 6y ago
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.

BigJono 6y ago

I fucking wish this was the extent of the web stack madness in half the places I've worked. The amount of stuff you can ram into a front-end code base is truly insane.

johnchristopher 6y ago

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.