Unpopular Opinion: Node.js + [insert SPA framework] is the wrong choice for my next Indie Hacker project
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.
After 19,314 lines of code, i'm shutting down my project
Need feedback for my product.
Don't be a Jerk. Use this Tip Calculator.
40 open-source gems to replace your SaaS subscriptions 🔥 🚀
We are live on Product Hunt
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.
Thanks @bgrgndzz.
Mind sharing what your boilerplate is (if it's a public repo)? Or, at least just mentions the key components of the stack?
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.
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.
Nice! Thanks for the reference. Didn't know about this one.
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.
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
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)
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:
Sketch how you app architecture would look under each choice you consider, and spot any problems such as:
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.
Another important consideration if you care about the long game is...
Thanks for the thoughtful response, @mcapodici! (And I won't judge you for deploying on Azure :) )
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).
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...
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.
Relevant: Hasura has built a bunch of boilerplates with various GraphQL-backed stacks: https://github.com/hasura/graphql-engine/tree/master/community/sample-apps
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.
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.
This comment has been voted down. Click to show.
How to do what? I'm doing it now. It's overly verbose.
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.
Really cool! Neat project ...
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)?
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.
100% agree, if you can stick with Django, Rails, Laravel without an SPA wonderful.
Thanks @volkandkaya!
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.
This doesn't fit with my experience. Even when over 90% of my professional experience was working with a Node back-end and I'd only being playing with Rails for a few weeks, I was able to prototype considerably faster with Rails.
If you accept that there's a difference between higher and lower level tools and that Rails is higher level, then saying
Is like saying
It sounds like good advice on the surface, but the problem is a brush too small and slow for painting most walls and you could get it done much faster if you learned how to use a roller.
Similarly, if you're panting the siding around a window, you should use a brush instead of a roller even if you're more comfortable painting with a roller, because you need something smaller easier to control at a finer level.
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.
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.
@ivtxtx, any chance you know of good scaffoldings for Node?
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.
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.
Neat project! Yeah, that definitely a strength of Node over PHP
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...
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.
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.
@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?
It'd be cool if you could do that and see what you're getting before you have to pay.
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?
It would definitely help!!
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!
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?
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.
This comment was deleted 5 years ago.
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?
This comment was deleted 5 years ago.
@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:
If Mongo natively supported relational data between documents, I'd change my opinion.
What's wrong with https://docs.mongodb.com/manual/applications/data-models-relationships/ ?
Well, nothing in theory... but here are a few things I’ve come across in practice:
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. :)
This comment was deleted 5 years ago.
This comment was deleted 5 years ago.
This comment was deleted 4 years ago.
@quique, I used to fully agree with this:
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:
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?
This comment was deleted 4 years ago.
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.