Developers March 16, 2020

Unpopular Opinion: Node.js + [insert SPA framework] is the wrong choice for my next Indie Hacker project

Spencer Jones @jones_spencera

Some background: I have multiple years of production experience working as a senior level Node and JS developer on projects that range from one developer, mid-sized team (20-25 people), and large (100s). I consider JS my primary language and am very comfortable with various Node frameworks and SPA frameworks like React and Vue.

The problem I've found is that the development experience with Node.js + SPA framework is overly complicated and takes a lot of time to configure and wire together, especially when you're a solo-dev and want to spend your time solving the business problem. At first, you can use a CLI tool like create-react-app to get setup quickly, but over time, adding new features becomes increasingly complicated and slows development.

The JS ecosystem is characterized by a very robust community producing amazing open-source tools ... that require significant time to setup, configure, and maintain. It's configuration over convention. The closest thing I've seen on this front is Postgraphile which generates a GraphQL API by introspecting your Postgres schema.

Contrast this with a framework like Rails in the Ruby world or Laravel in the PHP world. My last experience with Laravel was a few years ago, but I remember being able to setup quickly and continue adding features easily; a similar experience with Rails (which pioneered this approach).

I guess, I'd love to be convinced that Node.js + JS is the right choice for my next project as a solo dev—but I'm looking elsewhere.

For the Indie Hacker hivemind, I'd love to know if ...

  • do you agree/disagree with my assessment about Node tooling vs Rails or Laravel? If so, why?
  • am I missing something in the JS ecosystem? If so, I'd love to hear about it.
  1. 7

    It is exactly the opposite for me. I agree that React or Vue is not the way to go for very simple applications. However, I have never used a simpler tool than Node.js. I can kick up an app in a day and deploy it within minutes. It all boils down to how you manage the code. I work in an extremely modularized way and can easily see what leads to where and what effect a change will have. Adding a feature to an application of that kind does not require reading a lot of code as the feature is less of an integration and more of an addition. I keep a boilerplate setup that I have been perfecting for years and it has never felt overly complicated. How do you manage your code? Maybe if you revise that, you can get better results.

    1. 4

      Thanks @bgrgndzz.

      I keep a boilerplate setup that I have been perfecting for years and it has never felt overly complicated.

      Mind sharing what your boilerplate is (if it's a public repo)? Or, at least just mentions the key components of the stack?

      1. 2

        I take the classic model-view-controller approach with some of the libraries I frequently use already setup. I use pug for views if I don't use react and express for routing. Every function is a separate middleware that is combined together by routers. The main app.js file separates the app into routes. The router files in routes/ folder separate it into paths with multiple middleware. For example, the register POST endpoint is located under the auth.js router file accessed from the /auth/register path; it includes one middleware for verifying the inputs and another for saving them to the database. If a problem arises, I only need to search for the file that corresponds to the function that is not working. Many people seem to use one file for each path, but keeping many functions in one file makes it very hard to develop and debug those paths. I couldn't explain it very clearly, hope you get the gist.

  2. 5

    I can create a new SAAS app in 15 seconds.

    I clone this - https://github.com/saas-developer/saasify
    Then run
    rm-rf .git
    git init

    I also have a course for building a
    SAAS app in a Weekend. Link is in my profile.

    1. 1

      Nice! Thanks for the reference. Didn't know about this one.

  3. 2

    The problem is not nodejs but the way you group code together

    Using react and graphql usually means having an api and a client that talk together, this means you have to keep them in sync for every feature you add

    Using rails instead you have a single codebase, to add a feature you are hleped by the languange type system and conventions

    You can get the same thing with nodejs and react, i personally use mongoke (same as hasura but for mongodb), react and an api in node
    Then i generate the types from the graphql so i can keep in sync all the pieces
    To add a new feature i usually modify the graphql schema, generate the types, write the resolvers and write the react components to consume the graphql query

  4. 2

    I think you use whatever you're familiar with and don't worry about what happens down the line. If you're like most companies and start ups you'll never get to the point where it becomes a problem. If you do, you'll have the money to fix it.

    If you're familiar with Rails or Laravel, I see no reason not to use them along with React or Vue? My stack is React, and Laravel for the API. I have some node experience, but not as much as PHP, so I'm going with what I know. I think Laravel is a good long-term choice too, but even if I didn't think it was I would still use it, because I know it.

    If I were more comfortable with node, I would go with that. React shouldn't take a long time to set up if you have a lot of experience with it. If you don't, then maybe it's not the right choice. Honestly I work on a product that is OLD SCHOOL. Codebase is 13+ years old. Legacy everything. Not a lot of tests. But it's crazy successful. Users don't care what your code looks like. They just want a product that helps them solve a problem.

    Build with whatever makes you build it the fastest.

  5. 2

    I totally agree, having done both approaches, all my solo projects are gonna be rails + stimulus js unless I find something where I NEED an SPA. It's just a lot easier to work with.

  6. 2

    I completely agree with you and also come from a background of years of professional experience using Node + a SPA (first backbone, then later react)

  7. 2

    This is in the realm of software architecture, and it is sensible to think about what architecture you should use given your requirements.

    From a solo hackers point of view things to consider:

    • What features does the MVP require?
    • What technologies do I know very well?
    • What technologies might help alot but require me to learn?
    • Are there any off the shelf no-code or cloud solutions that can help me get there faster?

    Sketch how you app architecture would look under each choice you consider, and spot any problems such as:

    • Will it will be hard to extend later because I've painted into a corner? Does that matter? Is this an MVP test or the permanent project?
    • I'll spend more time learning the tech than using it to build?
    • Beware the shiny new object - if you are used to RoR, NodeJS might seem simple but you'll be slower as you need to get to know all the base functionality and it's quirks and bugs.

    Don't try to save money! If spending $100 a month saves you 10 hours of dev work for the MVP it's probably worth it. It'll either work meaning continuing to spend $100 is OK, or fail fast, and you can stop paying it. Although that may depend on your available cash to spend on the idea.

    In general making SPA is more complicated than a server generated solution because the SPA still needs a back end, but now you need to use stuff like bundlers, worry about bundle sizes, choose frameworks etc. I would err on the side of avoiding SPA for a IH project unless it is so painful not to have it you are pulling your teeth out.

    Also personal point of view, take with a pinch of salet etc - I'll use ASP.NET for my back ends because of strong typing, I am familiar with it, and it has a much better base class library than NodeJS, and compared to Ruby it is well typed. It might take a bit longer to get a project set up but it will pay me back with a maintainable, easier to deploy (yes on Azure, but who cares?) app.

    1. 3

      Another important consideration if you care about the long game is...

      • What technology would I like to learn well
    2. 2

      Thanks for the thoughtful response, @mcapodici! (And I won't judge you for deploying on Azure :) )

      In general making SPA is more complicated than a server generated solution because the SPA still needs a back end, but now you need to use stuff like bundlers, worry about bundle sizes, choose frameworks etc.

      Yes, exactly. Suddenly, now you have a front-end AND a back-end to maintain. The front-end has it's own build process, state management, testing, etc. A server-side rendered framework like RoR (sure, you can use it for a JSON API, but that's not the standard case).

      Beware the shiny new object - if you are used to RoR, NodeJS might seem simple but you'll be slower as you need to get to know all the base functionality and it's quirks and bugs.

      In my case, I feel like I'm leaving the sexy, shiny object (Node, React, Mongo, JAMStack, etc) and considering RoR which is now comparatively old.

      I slot this whole discussion under your question...

      What technologies might help alot but require me to learn?

  8. 2

    Agree. I'm working on my first NodeJS app now after coming from a Java / Spring world and I could literally do everything in the codebase in 1/10th the amount of code with Spring. I could do 90% of what the app does with Hasura and some configuration, then put the rest out into serverless functions.

    1. 1

      Relevant: Hasura has built a bunch of boilerplates with various GraphQL-backed stacks: https://github.com/hasura/graphql-engine/tree/master/community/sample-apps

    2. 1

      Don't know Hasura. Looks worth a look. Thanks!

      I only had one small and mostly negative experience with Java/Spring. There's a steep learning curve for an outsider, but I appreciate that once you know it—there's a lot of power in there.

      1. 1

        Right, Spring is a lot, but it's very powerful. Similar arguments can be made for Rails, etc. It's just that Node.js doesn't seem to have this yet and it's just a lot of typing and keeping things in sync.

    3. 0

      If you are interested in learning to do this in Node and React, please check out the Udemy link in my profile.

      1. 1

        How to do what? I'm doing it now. It's overly verbose.

  9. 2

    Yeah, I agree a whole lot with the sentiment here. I love working with JavaScript, but I found that every new project I started working on had a whole lot of setup time involved, and there wasn't really great guidance on best practices for even a lot of the most-popular tools. So I started working on a scaffold I could use for projects going forward until I realized that probably a lot of people have this common issue.

    Since then, I've transitioned it into a proper SaaS starter kit and have landing page up at https://nodewood.com/. I'd love your feedback about if that helps solve your problem, what kinds of configuration options/features are critically important, that kind of thing.

    1. 1

      Really cool! Neat project ...

      choose a language, pick a framework, set up your development environment and build system, build a secure user creation, authentication, and management system, build a skeleton UI, set up state management between your API and your UI

      Definitely speaks to my pain points, per this thread.

      That is a lot of the things I don't want to have to setup every time, but usually feel the need to. I hope Nodewood delivers on that promise!

      Couple questions... why Vue? Can you sub-in React (or insert X framework)? It uses Knex.js so I assume that Nodewood supports all the DBs that Knex supports (Postgres, MySQL,etc etc)?

      1. 3

        React and Vue are both excellent choices for JS frameworks, but the reason I went with Vue is that it's just... easier. React is great if you have a large team and want to manage the complexity of working with them, but if you're smaller, Vue has a lot fewer moving parts to keep track of and it's quicker to start up with. Plus, it's probably easier to move from React to Vue than vice-versa, so that doesn't hurt.

        Vue is pretty foundational to Nodewood. The scaffold app, admin panel, all the UI that it comes with are all built in it. If you're dead-set on React, one of my competitors does a real good job with it at https://usegravity.app/, but I think Vue is really just a joy to work with, honestly.

        As far as databases, this actually points out a thing I should mention on the landing page somewhere. I've gone with MassiveJS(https://massivejs.org/) for the database layer. In Nodewood, you create Services that you call from your Controllers, and those Services have access to a preconfigured MassiveJS table object that lets you interact with the DB and return Models. Those Models don't have any database code in them at all, so you can use them in the backend or frontend just as easily, cutting down on code duplication. This makes your code simpler to write, which reduces errors and means you can move faster.

        This, however, limits you to PostgreSQL, but I don't really see that as a downside. If you know SQL, you can become comfortable with PostgreSQL really quickly, and the framework will come with Ansible scripts to both launch a Vagrant VM for development, or deploy to any server you have SSH access to, so you won't have to know how to set up or configure a PostgreSQL server yourself.

  10. 2

    The first question I ask myself when starting a new project, which I believe also applies to you is: "What is your goal?".

    If you're looking at your next side-project as a potential business opportunity, I would suggest you pick whatever programming language / framework you're most productive with. Whatever gets your MVP out the door and into the eyes of your beta testers the fastest - that should be your #1 choice.

    In my case for example, I'm actually not the greatest JS developer, but I use it in most of my side-projects mainly because of the huge open source community around it. This allows me to focus on where I think I can make a difference, and not have to worry about the tedious things which come with any project (logging, authentication, asset management, deployment, etc), as these are all solved problems already. Also, there's a high likelihood that whatever you need to build, is available already as an open source library. IMO if you're hoping to just ship something out as quickly as you can, this factor cannot be overlooked.

    Best!

    1. 1

      @quique, I used to fully agree with this:

      If you're looking at your next side-project as a potential business opportunity, I would suggest you pick whatever programming language / framework you're most productive with. Whatever gets your MVP out the door and into the eyes of your beta testers the fastest - that should be your #1 choice.

      But, I'm questioning now. A node framework + SPA will be much faster for me to start out because I'm familiar. Eventually, those, get slower and slow, especially in a few areas:

      1. unit, integration, end-to-end testing (not important necessarily for a beta, but important for ongoing maintenance as a solo dev. probably worth a separate topic thread)
      2. authentication
      3. role-based-access control
      4. multi-tenancy
      5. payments (thank goodness for Stripe!)

      What I'm wondering now—if I want to be an indie hacker for awhile, is investing in a framework like Rails worth it for development speed on future projects?

      1. 1

        I think you'd face similar challenges in Rails. Don't you still need to add auth, RBAC, pament and deployment scripts, etc?

        Perhaps what you're looking for is a SaaS starter boilerplate, ie an opinionated stack that includes most things (but not too much) for you to get productive fast.

        I'm actually prototyping a minimalist React + Auth0 +Express + Mongo stack. It's already taken me 12 hours and I still don't have the database :D

        1. 1

          Yeah, you’re not wrong Is your boilerplate open source somewhere? I’d love to take a look.

          I think a framework like rails with an active community means a lot of those things are implemented either out of the box at the framework or with an open source package that’s easy to integrate. Laravel also has helpers built in to scaffold large parts of that.

  11. 2

    What do you think about something like divjoy.com that handles a lot of those details for you? This is basically the problem I'm trying to solve for the React community and would love your critical feedback.

    1. 1

      @Gabe thanks for sharing! Didn't know divjoy before.

      Looks like it's got a lot of power in the options, but I don't see much about a database tier?

      Choose your stack and template above and we’ll let you customize in our built-in editor. Tweak styles, add pages, and drag in new sections from our visual component library. When you’re ready to move to code you can download your codebase or one-click export to CodeSandbox.

      It'd be cool if you could do that and see what you're getting before you have to pay.

      1. 1

        Thanks for checking it out! Database integration is coming next week, starting with Firestore, but will be adding others like Mongo DB, Postgres, etc. I've been getting a lot of requests to see code before paying, so definitely need to do something about that.. Here's an example project I just exported: https://codesandbox.io/s/divjoy-example-project-luhwq. Do you think being able to view that CodeSandbox (maybe embedded in Divjoy) would be enough to make a purchase decision?

        1. 2

          It would definitely help!!

        2. 2

          I love divjoy and used it prior to the introduction of paid downloads so I know the code is of high quality. But if people need to see the coding style, prominently promote your usehooks site as what the code will be like. The codesandbox is also a good idea!

  12. 2

    100% agree, if you can stick with Django, Rails, Laravel without an SPA wonderful.

  13. 1

    Have to agree! My most recent professional experience had been with Java/Spring and Angular. But before I used Rails and decided to go back to Rails for my indie hacking projects for the same reasons you outlined. I know I can configure and wire all this together but I don't really want to spend my time that way, I can't afford to as a solo-dev.

  14. 1

    I totally agree that Rails or Laravel (biased more towards Laravel since PHP is better supported in the server world) are the only two options when it comes to building an indie hacker project from scratch.

    However for node and other languages, you often times start with a solid scaffolding which you reuse every time instead of creating from scratch so I guess it comes down to what you are most productive in.

    1. 1

      @ivtxtx, any chance you know of good scaffoldings for Node?

  15. 1

    Agree, Laravel or Rails are super easy to setup and work with.
    I built my project of interactive presentations in Laravel because of mentioned advantages. However, I found out PHP is not a good solution if you need to use real-time communication and websockets. So, I consider switching to NodeJS actually.

    1. 1

      Part of why I moved to Elixir+Phoenix is that you get both the unified framework community, code generators, and tooling of a Rails or a Laravel and considerably better real-time and websocket performance than Node.

      If you're building an app involving chat or WebRTC, you'll get to a production grade app faster and more easily with Phoenix. It even has presence built in. Your scheduled workers, concurrent tasks etc, will also all be inside your app instead of needing to dish them off to something like Sidekiq, Redis, cron jobs, etc. which is also a big time saver.

    2. 1

      Neat project! Yeah, that definitely a strength of Node over PHP

  16. 1

    I've used PHP back in the day with Zend Framework (does that even still exist? lol) and i can say PHP is pretty much tailored to the bone for web development. I've dipped into JS and Ruby a bit, but i can safely say that you can easily build a complete forum software using Zend or any other framework within like 2 days. And PHP is still fast enough to keep up with JS and Ruby for most applications (unless you're building massive scale applications, then scaling can be a bit daunting...)

    That being said, if you already have so much JS experience, would it really make sense to switch to a completely different language?

    For SPA look-and-feel you'd still have to use a frontend framework or at least AJAX functionality using vanilla JS...

    1. 1

      if you already have so much JS experience, would it really make sense to switch to a completely different language?

      Exactly! This is what keeps me up at night (not really, but so the saying goes).

      What I've found is that the tools in the Node/JS community paired with my experiences only get me so far. It's definitely faster to start, but once it comes down to a few months in—things get much, much slower.

  17. 1

    That's interesting.

    I have only experience in node.js ecosystem, because I come from front-end development world.

    Do you think in my case it would make sense to start learning one of those frameworks from scratch, or ROI is not high enough, if I feel very comfortable in JS world?

    In my case I always had more trouble with maintaining databases (proper database design, migrations, backups), rather than writing api code in node.js, which I can do extremely fast.
    I would imagine that even in frameworks you are mentioning, cost of maintaining say - postgres database would be similar?

    1. 2

      Do you think in my case it would make sense to start learning one of those frameworks from scratch, or ROI is not high enough, if I feel very comfortable in JS world?

      I guess it depends on the nature of the project you're working on and what you're hoping to get out of it... on the one hand, it can never hurt to really deep dive into that stuff. On the other, maybe you want to put a project out and make money quickly in which case it's probably not worth spending a bunch of time to learn how to manage Postgres.

      I'm always an advocate of branching out and learning broadly, but choosing conservative, stable, mature tools when you need to move fast.

  18. 1

    This comment was deleted 5 months ago.

    1. 1

      I found it was tough to beat NodeJS, Mongoose/MongoDB, & an SPA.

      This is the stack I've been living in recently! (I'm prejudiced against MongoDB ... but that's a different story.)

      Which Node.js framework, if any?

      1. 1

        This comment was deleted 5 months ago.

        1. 1

          @benjibuiltit, sorry for not being clear—I was meaning things like Express.

          My personal opinion here ... Mongo is great for getting started quickly in Node.js and haven't had many problems on small projects that don't change much, but here are a couple of things that cause problems over time:

          1. Lack of foreign key constraints means updating/deleting relational data can be really problematic, which leads me to ...
          2. So much of application data is relational; doing relational data in Mongo is just awkward in so many scenarios. Not everything makes sense in a data or denormalized.
          3. Data denormalization is often the wrong choice for an application, but encouraged in Mongo schema design
          4. Schema validation is usually done with mongoose and there's a lot of holes. You can implement it using Mongo's JSON schema validation, but there's not great tooling around that.
          5. Migrations... good luck :)

          If Mongo natively supported relational data between documents, I'd change my opinion.

            1. 1

              Well, nothing in theory... but here are a few things I’ve come across in practice:

              1. Writing aggregation pipelines is pretty tricky to get right and really verbose. (Anybody know of an elegant Node wrapper?? I feel like there should be one)
              2. Updating and querying deeply nested subdocuments and arrays gets complicated really fast, and there are limits to what Mongo can do once things get too deeply nested. Also, if a single document becomes too complex and large, you hit the Mongo limits for document size.... so not all datasets work.
              3. You can reference objects in other collections, sure, but there are still no foreign key constraints.
              1. 2

                If you have documents hitting the mongo limits then the design is flawed or mongo is simply the wrong choice for the task. With the other points I agree, use the right tool for the right job. :)

          1. 1

            This comment was deleted 5 months ago.

        2. 1

          This comment was deleted 6 months ago.

Recommended Posts