7
8 Comments

Ask IH: Do you prefer a shiny new stack, or the "boring old" stack? What is your reasoning?

EDIT: Just to clear this up a bit - I'm aware that customers don't care about what stack you use. It's more of a question whether you as indie hackers prefer diving into the unknown vs using what you've always been using. :)

Given the constant flux that happens on the web you can almost count on for a new hip technology to come out every other week. Of course, not everything will stick, but there's always new things to try.

Do you think it's worth to have the latest and greatest in frameworks and tooling, or do you sometimes prefer to go with a more established approach of web development?

To clarify: "New and shiny" here leaning more towards a SPA/API approach and "Old and boring" referring to good old MVC framework that handles your sessions views etc.

I've personally recently come to love a bit of a mixed approach due to Laravel. (I wrote about it here: http://www.blechi.at/back-to-the-roots-with-laravel.html)

It just feels super nice to have Laravel lift so much of the backend work and then enhancing the frontend with interactive Vue components where needed/practical.

What's your opinion?

  1. 5

    How long is a piece of string?

    I think it depends on what your goals are for a project. If you are building something new in order to level up as a developer and learn relevant new skills which may make you more attractive to employers, then I'd say it's obviously useful to try out new technologies (or just established ones you are unfamiliar with).

    On the other hand, if your goal is to build a functioning or profitable business to solve a particular customer problem, then you should use the tools which will get you that solution up and running as quickly and easily as possible. In most cases, that will be with a stack you already know well.

    IMO problems arise mainly when there isn't a clear goal. There's a famous quote which goes something like 'the best programming stack for the job is the one you know how to use'.

    There are secondary concerns around scalability and recruiting developers who can work with your chosen stack, however given the extremely low likelihood of one's project becoming successful anyway, I wouldn't waste too much time thinking about these concerns for a side project.

  2. 4

    Eventually you realise that when you find a useful website, you don't wonder or care about what stack is sat underneath - and neither will your customers.

    I've shipped recently using PHP and jQuery much to the aghast of fellow developers - but it works great and no one really cares.

  3. 2

    Though most would argue the customer doesn't care about your stack, but your productivity and code quality might be affected by your stack.

    When I move from Backbone to Vue, I realize the reactivity model does helps me write better code (less buggy, less code and easy to write more responsive UI). Vue components does save a lot of time, and vue webpack template let me onboard webpack almost instantly and take advantage of feature of webpack. Yes, you can still code the same functionality in pure Javascript and jQuery, but I believe Vue does increase productivity and code quality.

    If the project is urgent and you want instant productivity, don't pick up a new stack.

    Pick up and implement project using a new stack every year is probably bad idea, due to lost of productivity (once you are productive with a certain stack, you go into learning mode again, thus you spend more time learning than building).

    If you didn't change your stack in 5-10 years, you might loose out in certain long term productivity, performance or code quality gain, or fail to tap into the new ecosystem of libraries/components/tools.

  4. 2

    To be honest I don't care if it's new or old, as long as it helps me to achieve my goals. To check if it does, I keep in mind the following:

    • Is the framework being actively maintained (that rules out the reallly old stacks of course)
    • Is there enough support available online (i.e., does a Google search for an error code give me a Stackoverflow question + answer)
    • Do I have enough knowledge of the framework to get started quickly?

    That last point can be tricky: it's always fun to learn something new, but is it still that much fun after the first part of the learning curve? Or should you have sticked to the framework you already knew?

    Keep in mind that your end user probably isn't interested in the stack. They're just looking for a product that works.

  5. 1

    This is really easy. Boring old. I have been a tech guy all my life. I am 50 now, and I have a successful app business with a dozen apps that are fully passive income for me except for my fun tinkering. I am fully independent with these apps - I have no other jobs, am not on any benefits and am developing other side businesses now. To be brief, Apps are Apple, they offer Swift and boring old Objective-C platforms. I use Objective-C and resist the shift to Swift. Apple continue to support all new functionality with Objective-C, meanwhile with Swift they update Swift every year, meaning you have to migrate your apps every year, and that means a full retest, and it has to be done otherwise they will desupport your old version of Swift. I have no time for that, I want easy code that is reliable and fully tested, I want no risk to my business, I want to remain passive.

    With new platforms, you are taking a big risk

    • Your platform may not become popular and will be desupported.
    • Old platforms all issues have already been resolved and resolutions have been posted on web for you to find.
    • Easy to find talent cheap for your old platform
    • Still fully supported old platform as tons of people already use it

    Don't be the risk taker for someone elses risk, mitigate that risk by using a standard existing platform with tons of support.

  6. 1

    I stick to "old and boring" where possible. Especially if it's a project that's more than just playing around - I want to be able to be as efficient as possible with my time.

    My "old and boring" is Laravel and has grown to include Vuejs.

    If there's a situation where something "new and shiny" is better suited to what I want to achieve then I'll use that.

  7. 1

    Boring old stack. I can move way faster without a shiny new stack and actually shop my projects

  8. 1

    I used to try and learn all the latest and greatest languages, tools, frameworks etc. Then I realized I was spending way too much time learning and not enough time creating anything.

    Don't get me wrong, learning is a lifelong process. But, when you're trying to get shit done, use what you know.

    Personally, I use a simple LAMP stack. Nothing "fancy", but it gets the job done.

    In a way, I feel that developers try too hard to impress themselves and others with their stack. Maybe it's immaturity, maybe its insecurity or maybe its because engineers like to explore. Whatever it is, it can become a huge liability. Just make sure you're aware.

  9. 1

    This comment was deleted 8 years ago