Ask HN: Freelance website builders/maintainers, what's in your 2024 toolkit?

As you might know not one tool fits all, I still have strong preferences for the following. It helps me get going faster and get things done right first time and helps in ease of maintenance.

Language: Typescript.

Frontend Framework: Astrojs [1] or qwik [2]

Frontend Library: React if it requires 3d and other frame-motion like animations, else will not use any frontend library or might throw solidjs if required for some state etc.

Backend: Cloudflare functions, google functions

Auth: Lucia-Auth [3] if required

IDE: VS code with neovim , once deployed to git, I might some time use code-spaces

CSS: DaisyUI [4] with tailwind or Bulma

CSS Library: TailwindUI [5] makes most of the components ready to use and comes from the makers

CMS: Astro content collections or Sanity [6]

Deployment: Cloudflare (Highly preferred) or linode/digitalocean/netlify

Database: turso [7] or neon postgres [8] with (drizzle orm) or cloudflare durable objects

1. https://github.com/withastro/astro

2. https://github.com/BuilderIO/qwik

3. https://github.com/lucia-auth/lucia

4. https://github.com/saadeghi/daisyui

5. https://tailwindui.com/

6. https://www.sanity.io/

7. https://turso.tech/

8. https://neon.tech/

Also huge fan of firebase and their emulators and whole eco-system.

kevinsync · 2 years ago

This list is great, and fascinating because I haven't heard of most of it and don't use a single thing on it for my personal or client projects.

I appreciate seeing what stacks work for other people, and also very much appreciate the illustration of how NOT homogenous things actually are out there in the world (despite certain blogs and developer influencers trying to convince you otherwise)

moltar · 2 years ago

Great list. I’m using many of the same tools.

Want to throw in Remix into this list. It’s been a breath of fresh air compared to many convoluted systems these days.

Cheezmeister · 2 years ago

> VS code with neovim

Do you mean VS code with a plugin that makes it look and feel like neovim, or is there a way to make both clients edit the same buffer at the same time?

p2hari · 2 years ago

Sorry for not being clear. It is a plugin with VS code.

spelunker · 2 years ago

A second vote for this being a great list. This fills in some gaps for libraries I didn't know existed, such as lucia.

I'm going to try out Astro!

No one in here is going to agree with me because I'm not cool, but I don't care, "I've seen it all!!"

I have an employer, and we work with a particular stack, but if I was doing my own thing I would work native each an every time... If you work with apps, xcode and Swift, Android? Android Studio and Kotlin/Java, Windows desktop? Windows Forms and .NET %CURRENT_DOTNET_ITERATION%... Web? pick a solid framework with tons of support and libraries, django, rails, phoenix, et al. Minimize the use of JS libraries/frameworks or remove altogether, forget about fads that mix markup with javascript and logic, and even style (these days). Do not build stuff based on a web browser just so you can call it multi-platform, you will end up shipping a crappy abstraction with a poor UI and even worse performance, because remember, you are playing solo, cant afford the optimizations of large product teams, be pragmatic... deployments/CICD/devops DIY, don't trust services that advertise themselves as a panacea for deployments, remember Heroku f* everyone sideways... learn and use stuff like Dokku or Kamal...

yau8edq12i · 2 years ago

You're going to make cross-platform native apps for the local pizza shop who wants to display opening hours and the menu on some kind of webpage? No one here is going to agree with you because the question is specifically about building websites as a freelancer, and you're replying something akin to "don't make websites, trust me I'm not a freelancer." Well okay then?

seafoamteal · 2 years ago

Native apps certainly do have their plus points, but for use cases like small local business that customers will order from pretty infrequently, a website is the way to go. I don't want another app on my phone that I'll use once and then never again for a year or so. And of course, websites are still the way to go when you just want to put some information up publicly for people to access without any interactivity involved. You wouldn't have an app just to display your store services and timings.

thih9 · 2 years ago

> Do not build stuff based on a web browser just so you can call it multi-platform, you will end up shipping a crappy abstraction with a poor UI and even worse performance (...)

In many cases this sounds better than shipping for only one platform - or not shipping at all.

KronisLV · 2 years ago

Plus, if your app idea is basically served by the features that a web app or a PWA offers, then you can write it more or less once (might need a few standalone browser checks in specific places) and deploy on multiple devices, for example, with https://www.pwabuilder.com/

I'm doing that right now. I'm having enough troubles with payment integration and proper auth and back end stuff, there's no way I could ship for web and two different mobile platforms at all without cutting too many corners.

Dead Comment

robofanatic · 2 years ago

> remember Heroku f* everyone sideways

Can you elaborate please? I hosted an API on heroku recently. I have no problem so far. Should I be concerned?

pelagicAustral · 2 years ago

They used to have a free tier that they killed out of the blue [0]. The cautionary tale is that you cannot just trust these services, they might change the rules at any given time... You can however learn to deploy your own servers and manage your deployments with FOSS tools like the ones I reference.

0: https://help.heroku.com/RSBRUH58/removal-of-heroku-free-prod...

slices · 2 years ago

no, Heroku is fine, as long as you have a basic understanding. If your service becomes a runaway hit, your heroku bill may get big, I assume that's what OP is referring to.

bdcravens · 2 years ago

It's just expensive and is less of a value add than it was when deployment tools were painful (especially for Rails applications)

karaterobot · 2 years ago

I think you are basically correct: the answer is usually boring technology. That should be everybody's default, and you should have to demonstrate why that is inappropriate on a case-by-case basis. But you should have to demonstrate it to a very skeptical and knowledgeable audience, who will probably roll their eyes when you talk about all the advantages of whatever eight month old technology you are excited to use. If the argument relies on phrases like "look at how many stars it has on github", or "here's a blog post about how great it works", or "big companies use it ... on some brochure sites" then it should not pass the filter.

emsalazar · 2 years ago

Depending on the clients' complexity and needs, I like to structure the work as:

Tier 1 (just need a basic site): Use the built-in website builders from their domain provider or hosted static site generators, like GoDaddy, Github Pages, etc.

Tier 2 (need plugins or ecommerce): If they require some more functionality like email lists or selling products then use services like Wordpress, Squarespace, or Shopify to build their site.

Tier 3 (extra data complexity): For sites that have more structured data that is not satisfied with tier 2, then use something like Webflow or Framer. These allow you to add more data types and categories to build unique pages.

Tier 4 (custom app) If they are building something unique that is complicated to build with the previous tiers, then my preferred stack to use is Django, Django Rest Framework, HTMX, Tailwind. Django-cms or Wagtail are also proven CMS to help build their site.

You should also consider serverless apps like Google Cloud Run or AWS Fargate so you don't worry too much about the infrastructure unless it is absolutely necessary to roll your own.

Tier 5 (a little bit of everything): Combine tiers with subdomains. For example, build their blog or marketing site on webflow, but have a custom API or an authenticated interface with a Django/DRF backend.

Ultimately, you need to see what level of technology your client is comfortable with and how you want to leave the project as your contract ends. Don't try to build a overtly complicated system that will give you more headaches later when the client calls on you again.

bryanculver · 2 years ago

This will sound like cheating but I argue for the time it saves me, both in creation and on-going maintenance, and delivering a quality finished project: Squarespace.

The clients are happy, if they get to the point where they want to manage the content themselves, and for less than $300/yr they get hosting, access to a payment processor if they need it, and domain renewal. It's been a no-brainer.

I don't feel that's cheating. In many ways you're a better option than a generalist, since I assume you've become an expert on that platform. I know others who focus on Shopify, Wix, etc.

debesyla · 2 years ago

I do same, but with Wordpress and Elementor builder. It's good enough for most small scale clients on nano-size budget. But Squarespace is a solid tool too!

aosaigh · 2 years ago

Some of the suggestions in this thread are completely nuts. If you are building a traditional marketing website for a client, you're doing your client a disservice if you don't use a CMS or hosted platform like Wordpress, Squarespace, Webflow, Shopify etc. You should be delivering something to them that it easy to maintain and document. If they need to get somebody in to help in 5 years, they shouldn't need to find a be full-stack web-app developer.

6510 · 2 years ago

Here!

https://wpengine.com/support/sync-new-post-and-pages/#Import...

I had to scroll up a bit to see the heading. They couldn't figure out how to jump to the #anchor apparently no one is actually looking at the new user experience. This wouldn't happen to me. It just wouldn't.

https://5help.squarespace.com/hc/en-us/articles/204965388-Im....

I would not make links like: 5help.squarespace.com/hc/en-us/articles/204965388-Importing-Blogger-or-WordPress-blog-posts#:~:text=Log%20into%20your%20Squarespace%205%20site.%20In%20the,URL%20that%20visitors%20use%20to%20visit%20that%20blog. but there it is. Ready for consumption.

https://webflow.com/updates/csv-import

Seems good enough if you can find the page.

https://help.shopify.com/en/manual/products/import-export/im...

Along with a long list of expensive plugins they will need if they want to keep the custom functionality. It will lack some thing but have other things that hopefully somewhat make up for it.

One should also have a new terms of service and user agreement ready in case of migration.

You see? If you prepare for it clients can downgrade whenever they like and everything becomes a nail.

I don’t see? What point is being made here?

philip1209 · 2 years ago

The competition to coded websites is Webflow agencies. Webflow has made websites somewhat predictable to build, enabling agencies to offer flat-rate pricing.

I think a questions you should ask is "What are the client needs that no-code doesn't serve", and explore that. Or, "What are the technical needs for deploying an hybrid coded+low-code stack", e.g. setting up reverse proxies that combine multiple backends.

michelb · 2 years ago

For marketing sites: Wordpress with a custom theme,ACF, and some other plugins, with WP-Rocket, behind a WAF. Integrate it with whatever service the client uses.

Then hand it over or maintain it for them.

Lately I have been using Framer which is awesome.

Trying to stay away from any JS framework or build system for my sanity.

This approach makes sense for even non-freelance deployments. Our primary income earner is a beast, with a custom workflow engine, orchestrated across multiple Docker containers in the cloud etc. However, our marketing site is a Wordpress site with a standard set of plugins, and I don't think I have a single line of custom code on it.

dmje · 2 years ago

Have a +1, I’m with you all the way. Of course, brace yourself for downvotes: this is HN, so by default WordPress will get voted down and so will anyone who says not to use JS as a front end :-)

I'm not a full-time freelancer, so I try to optimize the type of work I do. To that end, I'm sticking with Rails.

For my personal workflow, I put all projects in their own Docker Compose files (with local containers and/or standard images as appropriate). As much as possible, I want every project set up in such a way that my (host) machine has very few dependencies and everything is separate.

I limit the freelance work I do to the engagement; I'm not interested in managed services like owning the Github or the hosting accounts. I want to remove myself from the deployment if possible, so I push them towards CI/CD when I have the influence. (Github Actions these days, but I've used many of the standard options)

I avoid any kind of locking-in the client to me.