Web Development

If you plan to offer a service tied to a website you make for your client, what are the advantages of self hosting compared to relying on third party services?

Static sites, CMS, newsletter, emails, form handling and more..

An easy example is forms: you can either use formspree or install one of the countless foss form handlers you can find online..

In my mind it's definitely cooler to offer all the services your client needs + you can also charge for them without having to pay for 5 different plans on other platforms, just your VPS or dedicated machine, more income and less expenses. But I see it can be hard to manage outages sometimes or issues that can come with self hosting.

It's offering a service vs being just a reseller.

My experience with self hosting stuff on my own (for my own use) so far has been quite good. I don't use containerization and I carefully config everything needed the first time, then I reverse proxy through cloudflare, after that I rarely have issues and if I have I simply rely on logs.

In my mind it doesn't seem too hard to install a couple of services and make accounts for my clients + fixing something not working every now and then.

My only concern with that is if one day I will want to stop being a developer, how will I handle the quantity of people relying on my server and everything I will hold.

Interested in your thoughts and experience about self hosting vs relying on third parts!

TLDR; for my project i wanted the signal protocol that would work in a browser. following a previous post i made about looking for the signal protocol in javascript, i couldnt find something suitable... so empowered by AI, i tried to create something myself. i dont want to inspire undue confidence.

IMPORTANT: this project is not professionally audited or production ready.

for my p2p messaging project (a webapp) i wanted to explore an usage of the Signal protocol.... the investigation is still in progress and far from finished. its clear that the Signal protocol is not intended for a p2p architecture with it needing things like pre-keys stored on servers. so it seems nessesary to adapt it.

i looked around for a suitable implementation i could use. compiling the implementation in lib-signal-go to a wasm seemed like an option that worked... but given AI is everywhere, i decided to see if it could put something better together. i started off creating something using browser-based cryptograpy primitives. i would have like to keep it that way, but an ealier AI audit disagreed to using those primitives and so here is an attempt in rust that compiles to wasm.

https://github.com/positive-intentions/cryptography/tree/staging/src/rust

i added several unit tests and and got AI to try create better securty audits, and i think its working well. (or at least well enough). AI's security audit points me to many things i can improve throughout (so i will when i can).

this is fairly complicated stuff and i know better than to ask people to spend their own time to review my experimental project... im not sharing for you to review my code; im sharing this here if this is interesting for anyone to take a look.

(note: the repo is getting a bit too "full" and i will be splitting it into a separate repo for just the signal implementation.)

One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable “Always Use Secure Connections”. This means Chrome will ask for the user's permission before the first access to any public site without HTTPS.

I'm an experienced backend developer. To me, the backend world seems super simple compared to the frontend world.

It seems like there are a million options and I don't have the experience to say what's good and what's not. I'm hit with major choice paralysis, basically.

I don't have any special requirements - I "just" want to build a pretty standard, responsive, modern-looking UI. Ideally without too much boilerplate, in a framework that "feels good", in a way that might at some point attract other contributors as well, if I get to the point of open sourcing.

Of course I could just reach for the most popular thing i.e. React, but that doesn't seem to be the "hip" thing to use nowadays (or maybe I'm wrong? What do I know, I'm a backend dev).

But even if I choose a framework, there's a million other libraries out there to choose as well. For instance, which UI library to choose? What about observability and state management and authentication and so on?

Sorry if this is a bit ranty. I am honestly just looking for an experienced frontend developer to point me in some direction (i.e. some set of frameworks/libraries; a "stack" if you will), so I can get out of this choice paralysis.

What would be your go-to stack for a new frontend project today?

Okay so, context, I've come across this video last night. It's a short comparison between React and Svelte. Point 9 - Shared state (6:20) mentions that React doesn't really have a primitive way to share state between nested components and that you basically need to use something like Redux to get that working.

But... I've been sharing state between nested Components in just React for a while now and didn't know that I can't?? But I also don't remember where I learned to do it, so the chances are high that I just hallucinated up this method as a Junior.

Basically, when I want to share state I just make a new Context and ContextProvider, wrap it around the highest level Component I need it in, and use it lower down in the component tree.
If I need a state, I put the two outputs of the useState hook into the context (which feels nice because when I look through the code, I can see right away which children only read the value in the state and which children actually take the setter and have the capacity to change that state). Sometimes I don't even hand out the actual setter from the state, but a new function that also does some input validation before calling the setState itself. Doing it this way has always felt pretty clean to me.

From the React documentation, it seems to me like that's exactly how you're supposed to use Context. But I've also never seen anyone else do it like that. So is it incredibly ill advised and I've been shooting myself in the foot this whole time?

As a more specific example, my most common use case is that I need to render fetched data in a grid. This data can be filtered, but the component that sets the filter state is either on the same level as the grid (the grid's built in filter menu) or above it (a button that sets a predefined quick filter) or even further above that (a useEffect that looks for query parameters in the URL and sets those before the data is fetched for the first time).
So what I'd do is const [filterModel, setFilterModel] =useState() at the highest level and pass it to <FilterContext value={{filterModel, setFilterModel}}>. Then, I'd just use const {setFilterModel} = useContext(FilterContext) within all the components that write the filter and const {filterModel} = useContext(FilterContext) everywhere where I just need to read the filter, like in the hook that actually fetches my data. Does that make sense? Is there an easier/safer way to do it that doesn't involve adopting yet another external library?

After years of developer frustration and questions on online forums, it’s finally happening: CSS is getting an if() function to apply styling when a condition is met. For the first time, developers can make logical decisions directly in stylesheets, without separate code blocks. This opens up whole new possibilities for web designers.

Ordinality may be used to migrate scheme in your postgres database, to migrate from a JSON file to a database and back, to copy files from SSD to a S3, etc.

Ordinality let you manage any changes in your system via declarative actions, and a storage that remember applied actions.