First, I’m an 83 yo hobbyist developer. I’m still at the low end of my learning curve. I chose to code my web application rather than use a generator package like WordPress after a little experimentation. I wanted more control. Put that down to my having been a COBOL / BAL programmer in the '70s. I’m comfortable with html and css (though certainly no expert) and have begun to learn JavaScript. I have no real aversion to incorporating apps into my scheme where they will save me time and provide more reliable functionality. Auth0 (login and security) and Basin (email) are 2 that I’m investigating. There will probably be others.
I have a website hosted with Ionos,com, www.hutchinsclan.com. For now, it only displays information but I’m working to make the site interactive turning it into a webapp where CRUD and other features can be implemented for users. I am learning JavaScript for frontend data validation, etc. but have developed only one backend script using .js. I want to minimize my time investment learning new skills; therefore I intend to use JavaScript in nodejs for backend processing instead of having to learn a new topic, PHP. It’s true that I have to learn about the node.js environment, but using PHP comes with the same overhead (I think).
The issue is webhosting. Webhosting services don’t all support nodejs environments. Ionos.com does support it, but it requires upgrading to a more expensive level of service (or so they tell me). I think (but am not certain) that Ionos will support my site under my existing contract (no additional costs) if I use PHP.
With that background, here are my questions.
should I just give up and add PHP to my curriculum?
other than web hosting complications, are there other reasons NOT to use nodejs?
can you suggest other web hosting services that might be better suited to using node.js?
what other things should I consider?
The time has come for me to make a commitment to one backend environment or another and to start ‘laying code’. Please help me make a decision.
Before deciding on a backend, spell out exactly what you need, e.g. features, users, data handling, and how secure/reliable it must be. Right now, that’s all too vague.
My advice is that if you’re not already comfortable running and securing a server, don’t touch Node.js for backend work. Even with managed Node hosting (e.g. Heroku, Render, Vercel, etc.), you’ll still need to understand serverless concepts, environment variables, process management, and how to keep things patched. It’s a very different world from dropping a file onto shared hosting.
PHP, on the other hand, is supported almost everywhere, deploys with a simple upload, and is more forgiving for smaller, hobby-scale apps (e.g. broken scripts only kill that request, not your whole site). For CRUD, logins, and basic interactivity, it’ll do everything you’ve described without the operational headaches.
In short: define your requirements first, but unless you actively want to learn server ops, PHP will get you running faster and safer.
I’ve not yet looked at making my site more efficient. I started this thinking that I had to produce something as I learned. I wrote the html, css and a little .js and included images as I went. Since then I’ve spent about as much time going back through my code and file naming to try to conform to what I’ve learned about ‘best practices’ and ‘semantic structure’. That journey was worthwhile for what I learned in the process even if it didn’t advance my website at all .
I put your suggestion on image resizing in my ToDo.md file. I’ll get to it, but I won’t commit (pun intended) to it for now.
An aside:
When I started this I thought that I’d just have to learn the core ‘languages’ but soon learned that learning the tools was as much a part of the process. Learning VS Code and Git has made much of the rest of the effort easier but added time to the process. I can’t and won’t say that I’m even near proficiency, but I can lay code and get results. As I learn more and get good suggestions like yours, I can always come back and make improvements. I wrote for and managed a very large application - more than a million lines of COBOL code with another tens of thousands of BAL - for more than a decade. In that process the goal was always to meet a deadline but I soon learned that I had to allocate a portion of my resources (mostly manpower) to fixing things that needed to be better after the fact. Convincing my bosses to give me the time and manpower was a different matter, but I learned to expose the P&L impact to them for not doing it. That’s a long story but I tell it to show that I know results matter but so does the quality of the effort that produces them.
A million lines of COBOL and BAL? I can only imagine… glad I didn’t have to live through that myself. That’s some stamina.
To be fair, a 1GB pageload isn’t just a little bloated, it’s monstorous. This isn’t a “one day” tidy-up job like validating your HTML, it’s a problem that can make your site unusable for anyone not on a fat, fast connection.
If you watch this it’ll show you how to throttle your own connection and experience your site the way someone on bad Wi-Fi or mobile data would:
The audio quality isn’t perfect, so you can also try watching it with subtitles to aid understanding.
This video is a slightly lengthier version of the same thing.
I did go through file compressing all .jpg and .png files and reloading them yesterday. I’ll take a look at the video and see what more I need to learn and do.
Based on what I understood from the details you provided in the query, here are some suggestions from my side.
1. Should I just give up and add PHP to my curriculum?
No because you already know some JavaScript, so you’re reusing one language for both frontend and backend. PHP is still widely used, but unless you specifically want to build with WordPress or legacy CMS tools, it may not give you much extra advantage. If your current host forces PHP on you, then yes, learning just enough PHP to get by could be pragmatic, but otherwise, Node.js is a solid choice.
2. Other than web hosting complications, are there other reasons not to use Node.js?
The main drawbacks are:
Concurrency model: Node.js is single-threaded, so CPU-heavy tasks (like image processing or complex math) aren’t ideal. For normal CRUD apps, this isn’t an issue.
Ecosystem maturity: PHP has been around longer in the shared hosting world, so finding cheap/simple hosting with PHP is easier.
Learning curve: While it avoids a new language, you’ll need to learn about npm packages, async programming, and deployment practices.
Otherwise, for modern webapps, Node.js is a well-supported, mainstream choice.
3. Can you suggest other web hosting services that might be better suited to using Node.js?
Yes—there are several hosts that natively support Node.js apps without forcing you into an expensive enterprise plan:
Heroku (Free/Low-Cost tiers): Simple for hobby projects, deploy via Git, great for experimentation.
Render.com: Similar to Heroku, modern platform, free starter tier, and straightforward deployment.
DigitalOcean App Platform: Affordable, good documentation, runs Node.js apps easily.
Cloudways (DigitalOcean, Vultr, etc.): Managed approach, so you don’t handle servers directly but still can run Node.js.
These will give you far more freedom than traditional shared hosting.
4. Other things I should consider?
Database choice: Decide early if you’ll use something like MySQL/Postgres or a simpler option like SQLite or MongoDB. Hosting choice may depend on this.
Scalability vs simplicity: For a hobby app, simplicity matters more. Don’t overcomplicate with containers or Kubernetes unless you want to learn them.
Cost vs control: Shared hosting is cheapest but often limits Node.js. Cloud platforms give more flexibility but require a bit more setup.
Backup and security: Even hobby projects need backups and basic security (SSL, auth, input validation). Your use of Auth0 is a smart step.
Thank you for a thoughtful, well-considered, and informative answer. It is good to know that I have hosting alternatives that will support node.js without up-selling me for hosting services. I shall explore those alternatives.
.
