Developers November 30, 2020

Is your Hipster web development stack overkill?

Commander Fun @commanderfun

Is it just me? Or am I out of touch and behind the times?

I'm confused by the popularity of complicated web development toolchains and tech stacks. I understand their benefits once you reach a certain scale ... but do they make sense for indie developers or small teams?

I'm FAR more productive using a basic CSS framework (Bootstrap, Tailwind) and plain vanilla JavaScript (or jQuery) on the front end combined with a basic server side framework like Node/Express.

I don't feel like I've ever had to sacrifice or dumb down the "slickness" or interactivity of a front end UI when using just the above combined with simple REST endpoints that return JSON from the server.

It seems like a lot of new developers are wrestling with overly complicated front end toolchains (Gulp, Webpack) and JS frameworks (React, Vue, Angular) and over architected backend deployments (i.e. Kubernetes).

In my opinion it's WAY more important to move fast, ship a product and get customers than it is to spend all your time fiddling with some complicated "hipster" build, test, deploy stack.

Background: I ran a web dev agency for 15 years and have worked with just about every combination of the hipster front and back end stacks.

If you're a solo developer or a team of <= 10 people then I you don't think you need anything complicated.

After you've pulled yourself up by those "hipster suspenders" and hit 50K MRR then you can go back and make things more complicated. However, until you get there why not just (KISS) keep it simple stupid.

What are your thoughts on this?

  1. 21

    I think familiarity with a tech stack is going to be anyone's best bet for moving quickly. A lot of IndieHackers are folks who have/had day jobs working as software engineers, usually using tools like React.

    I don't think there is anything "hipster" about React, Vue or Angular. These are all huge tools with massive communities around them. I think in reality you're just more comfortable with how building web apps 10 years ago was so you feel more productive using technology from 10 years ago. For me personally I can build an app 10x faster using React than I can with jQuery. That doesn't make jQuery invalid, it just means I am more familiar with React.

    Honestly, I think we're getting to a point where building something in jQuery would be considered "hipster", like the current resurgence of film photography.

    1. 4

      I second what @ean said.

      I would add it's not always about hipsterism and more about setting the foundations for growth in your stack and limiting the tech debt over time.

      Obviously it depends on the type of project you're building. You might not want something hyper fancy if this is a personal project. However if this is a commercial project things might go quickly very fast. You will not always have the time to refactor things in the future. So it might be better to start with more complex technologies that scale with your traffic and team.

      Also it's important to consider recruitment in the stack you choose. According to Stackoverflow yearly stats, you are more likely to find developer willing to work with React than JQuery. So just from that point of view, it's worth investing the time to learn and setup your frontend with React rather than go with JQuery.

    2. 3


      I think that the takeaway from the post and your comment should be:

      1. Use something you are familiar with, and
      2. Don't make it too complicated.
    3. 1

      Agreed. It makes sense to use the tools that work best for you. If you love React and it makes you more productive then you should use it for sure. It's an amazing framework and I don't mean to disparage it. I think my main point is about the overall simplicity of the entire stack as a whole. Keeping it simple in the beginning helps meet your business objectives faster.

    4. 1

      I agree with you on React( or Vue, Angular).

      Developing a frontend in React is extremely fast for me once I understood how react works and I had a basic template I could start with. There is nothing "hipster" about React.

      On the backend however Kubernets or any other container based approach is overkill imho.

  2. 7

    One reason I love working with Elixir (or anything Erlang VM) is that I just don't have that problem.

    I often see a setup like this:

    • HTTP server: Nginx
    • Request processing: Node.js
    • Long-running requests: Golang
    • Server-wide state: Redis
    • Persistable data: Redis and Mongo
    • Background jobs: Cron, Bash and Ruby or Golang
    • Service crash recovery: Upstart/Systemd

    My setup looks more like this:

    • HTTP server: Elixir/Erlang VM
    • Request processing: Elixir/Erlang VM
    • Long-running requests: Elixir/Erlang VM
    • Server-wide state: Elixir/Erlang VM
    • Persistable data: Postgres
    • Background jobs: Elixir/Erlang VM
    • Service crash recovery: Elixir/Erlang VM (though to be fair, I'm also using Systemd as a backup fail-safe)

    If I needed to scale to far more users, well guess what language is great at distributed systems and currently powers Discord's servers? Yup. Elixir.

    The only time there's a real need to leave the ecosystem, at least for web dev, is more intense number crunching. Then it's necessary to dish the work off to something written in a lower-level language.

    1. 2

      This is compelling. Any resources for a developer unfamiliar with Elixir/Erlang?

      1. 5, which is what @alchemist runs.

        I can vouch for both Elixir as a language doing what he says, and for his site as a good place to learn about Elixir.

        My own 2 cents:

        Elixir is functional, which if you haven't done that before might seem scary, but it isn't. Functional can mean many things, but most practically it means that if you want to do something, you write a function and that's it. There are no objects, which basically means that data doesn't have methods/functions, or do things. Instead of $object->do_the_thing() you would write do_the_thing(data). Then there's a bunch of side benefits of functional that result in really excellent performance and certain guarantees that will take to long to get into here, but most of them you don't have to think about, you just get them for free. The syntax is very ruby-ish.

        Elixir is built on top of Erlang, and gets all of it's 34 years of effort for free. Erlang was initially written for landline phone networks in the 80's. It's designed to be ridiculously concurrent because all phones need to be able to call all other phones at any given second. It's ridiculously reliable because phone networks can't afford downtime or maintenance windows. Those two principles dominated every design decision of the language and that makes it amazing for web work in particular, or anything that needs to be distributed. Because they had to build it to operate on hardware available in the 80's, it's also very performant (though some langs like Rust will beat it out in some areas like intense math computations).

        Erlang has been around has been around for so long and used in a practical business setting (telecom) that it's already solved many of the problems we've discovered for web dev:

        • Built in supervisor/restarting. Taking down an Elixir app completely is very, very hard to do unintentionally, and I've never actually seen it myself. You can easily apply this at every level, from the entire app to a single task.

        • Built in super-fast cache with ETS (Erlang term storage). Similar to Redis, but it just comes with the language.

        • Cluster/node/distributed features built right in. You can horizontally scale Elixir apps natively without extra tools, they're designed with it in mind as a first class citizen.

        • Really well supported and designed HTTP(S) serving with the Cowboy package. You can run it on it's own without anything else to serve it.

        • Many more but this is getting very long

        Finally, Elixir has Phoenix and Liveview if you're into web dev. Phoenix is Rails/Laravel-ish in that it's very easy to pick up and simple to understand. It treats websockets and realtime channels as a first class citizen, right alongside http requests, which is amazing.

        Liveview is my favorite thing so far about Phoenix, it lets you build single page, realtime app features but written only with Elixir. I can't do it justice without making this post twice as long, so just check this out: The author of Phoenix and Liveview creating a Twitter clone in 15 minutes

        1. 2

          Damn this has the web dev side of me very excited. Thanks for taking the time to write this all out I enjoyed reading every sentence of it.

          Where are the rough parts? Being functional?

          1. 3

            The roughest parts for me have been:

            • Deployment to production, but that's changed really rapidly in the last year or two. It was mostly because Elixir apps need to be compiled on the same arch/os that you want to deploy on. i.e. If you want your prod app to run on Ubuntu 18.04, it's best to compile it on that, though you might have dev'd on a different OS. These days with docker or tools like Github actions, it's trivial. In fact I was half way through building a tool to compile releases for any OS/Arch combo, when the tools all caught up and I don't think that tool is even really needed anymore. Now you just spin up a docker container and run mix release --prod and it'll spit out all you need.

            • Syntax was a bit strange to me at first coming from PHP/Laravel (uses do and end instead of { } brackets) but Ruby devs will feel right at home.

            • Functional I found to be shockingly easy to get my head around, mostly because it's a very no-bullshit way of doing things. You don't have to wonder "Should this object be able to save itself?". You just write a function like save_the_thing(data_for_the_thing). Everything is just a function, a basic data type like integer or string, or something that holds data like a list or map (like an array). Data types don't have methods/functions, they're just data.

            • Wrapping my head around immutability (sort of). When people think of immutability, they think "okay so if I set this variable's value to be 100, I can't change it after to be something else". This is technically true under the hood (I think?) in Elixir, but practically you can re-assign it a new value just like you would in most languages. You still get all of the benefits of immutability that make things like concurrency really easy.

            All in all, after about 6 months of playing with Elixir on the side, I was more productive than with PHP/Laravel or JS - which I spent 6 or so years using every day for work. It's just easy to write. I don't worry about objects, inheritance, instantiation, or whatever else anymore. I just think "Okay, I want to do a thing with xyz data" and then I write a function or a few functions. And because I can do nearly everything in Elixir itself, I context switch way less.

            1. 2

              You don't have to wonder "Should this object be able to save itself?".

              Coming from a lot of python work I can totally appreciate this sentiment.

              Ok, learning Elixir/Erlang is officially in my TODO.

    2. 1

      I last looked at Elixir/Phoenix over a year ago, but one thing that I found very frustrating was the lack of good tooling and best practices around deployment - recommended solutions tended to be badly maintained and/or documented. This was in stark contrast to the development experience, which was otherwise excellent.

      It reminds me of the early days of Rails: lots of promise and good ideas, but be prepared to reinvent a lot of wheels until the ecosystem picks up steam.

      1. 1

        I've heard that one a lot, but it never made any sense to me. You could literally deploy a Phoenix app just like a Rails app 5 years ago. Just copy the files up, run your DB migrations and run mix phx.server.

        You could also build a release with distillery and run it. Having a self-contained release made the deployment side of things much simpler than in Rails.

        I did that in 2016 as I was learning the language and the only hassle I hit was getting Linux to let me run it on port 80 (solution: use setcap or iptables or put it behind nginx).

        In contrast, Rails deployment is one of the most complex out there. You definitely need another server in front of it, you have no option of building the whole thing into a release and you're going to need some kind of more complex setup with chef, capistrano, ansible, docker or some mix of the above.

  3. 4

    I share the sentiment. I can cite a few reasons for choosing a "complicated" stack :

    • Many coders enjoy coding more than shipping. They 'll find any excuse to learn and try new techs.
    • Fomo caused by social media where everyone is bragging about using brand new stacks.
    • Premature optimization and the desire to make things the "right" way from the start.

    Having said that, I'm grateful for the "hipster suspenders" haha because many of them make tutorials and contribute to the ecosystem of each stack.

  4. 2

    I agree with the sentiment, but you're not the right person to be preaching this.

    A developer's job is to keep current with industry trends. Industry trends are not 'hipster', they are the standard, and a standard for a reason.

    Check, jQuery does not even come up as a primary framework so few people actively work on it and promote it. Heck, even WordPress, has moved away from jQuery for its admin side.

    Older tech may work well for you, but good luck hiring good developers to scale your project when you're dealing with technologies that are the butt end of industry jokes.

    I'm going to make the assumption that you haven't spent the time to learn these frameworks and how to use them efficiently. If you're serious about your projects lasting many years and having other people work with you on them, I'd encourage you to spend the time learning the industry standards. If you like jQuery then Vue is going to be the easiest thing to pick up.

    I gurantee you if you have the same proficiency in Vue and jQuery, Vue is going to win every time.

  5. 2

    For me using Vue is exceptional easy and intuitive, I can't imagine going back to using pure JS for anything that involves DOM manipulation.

  6. 1

    I love technologies/frameworks that stop me from writing the same code over and over again. I would only not use a framework when I only need a static website, otherwise I'm picking up a framework.
    Same goes for the back-end.

    But I get the good point of this post, don't overcomplicate stuff when it's not needed.

  7. 1

    Using Vue or React is easier than dealing with vanilla js or jQuery

  8. 1

    One thing to mention here is that a lot of fancy technologies are for building one page apps. Not all projects need one page apps and for some being able to load super quickly is more important – like blogs.

  9. 1

    Honestly it all depends on what your goal is. If it can be done with vanilla JS and Bootstrap then don't waste your time wrestling with tech you're not familiar with.

    You kind of lost me when you said that you use simple CSS frameworks and then mentioned Tailwind as an example. There is nothing simple about Tailwind, a matter of fact the learning curve is much higher than most other CSS frameworks.

    However, once you learn Tailwind your productivity increases significantly.

    And the same thing applies to most of these "hipster" technologies like React, once you learn how to work with React you will notice a huge increase in productivity.

  10. 1

    That's why I set up to develop for quickly getting a static site online. I find most stacks to be overkill.

  11. 1

    My two cents: build stuff using what you’re most familiar with. That gets your product up and running faster. Especially if you’re in the early stages of validating the idea/prototype/MVP.

    Like you said, once the product hits a point where scaling up is needed, that’s a good time to re-evaluate your architecture/framework/tools.

  12. 1

    The best tool is whatever you are fluent with. Even with hourly client work I'm really cagey about taking on jobs using stacks that I don't know well (or don't care to pick up and learn).

  13. -4

    This comment has been voted down. Click to show.

    1. 3

      Is vue really slow ? What makes you think that ?

      Also, Vue can be integrated as a script tag just like jQuery. For Js heavy pages, it make sense to have something more powerful than jQuery in my opinion.

      1. 0

        I'll answer both replies i this comment.

        How do i know its really slow?
        First page load.
        Yeap, it has to get the whole compiler and compile first view on the Client-Side.
        You might say "but after that its fast!"
        What if there is no "after that"?
        What if average viewer is pissed off by waiting page to load 2MB of files just to see first pixel?
        And no, no amount of good content will help bad first impression.

        1. 1

          Vue is 33.3kB when included as a script tag (See[email protected] ). To compare, the minified version of jQuery is 30.5kB (See[email protected]/dist/jquery.min.js)

          Where do you see "2MB of files" ? A correctly configured webpack build with vue3 and tree-shaking, can result in a even smaller bundle size like 10kB or so. It's even smaller that jQuery at this point.

          And keep in mind that both are very popular (See,%2Fg%2F11c0vmgx5d) as a result it's very likely that the browser of the user already have a cached version of Vue because he visited one of the many website that use it. So he doesn't have to download it at all.

          And yes, you are correct, Vue.js has a bit of overhead, but it's like around 50 ms vs 20 ms for a vanilla js script. (See Most users will notice images loading long after the Js has already loaded.

          1. 1

            Ok 2MB might be because of lack of tree shaking.
            But still Vue still is slower in usage: vs
            Both use same api, try navigating one and the other.

    2. 2

      Vue is actually pretty fast:

      And Vue 3 is supposed to be faster still.

      1. 0

        You compare stupid with stupid with slow. Which one do you choose?

        Now, vote it down so no one can see it.

Recommended Posts