Bun is designed as a drop-in replacement for Node.js. It natively implements hundreds of Node.js and Web APIs, including fs, path, Buffer and more.
The goal of Bun is to run most of the world's server-side JavaScript and provide tools to improve performance, reduce complexity, and multiply developer productivity.
If it can replace node and pnpm at the same time then this sounds quite good actually.
While Vite currently works with Bun, it has not been heavily optimized, nor has Vite been adapted to use Bun's bundler, module resolver, or transpiler.
So it can also do tooling like vite but it primarily aims to replace node as a better and faster js runtime since they're rewritten most js api in zig and c++ from what it shows on their github. I'll give it a try sometime and see if it's really all that fast and easy as it claims.
I’m always kinda surprised when I see htmx. What’s the perks? I already have my stack, why should I change? I looked into it recently and it looked really unappealing
More important than learning a framework is to learn how things work beneath the frameworks. Try doing a project without frameworks. Who knows. You might even like it.
I'm glad this style of frontend coding (where you use a prebuilt JS library that handles common interactions through simple configuration, rather than writing custom JS) is coming back into fashion. It was common 15-20 years ago, and as web apps became heavier and heavier, I started to think it was a good idea again.
Also, if memory serves, plain old HTML4 allowed you to load partial html files within a main page and they'd render as expected, which completely beats the reasoning behind the "why use web components" on the piece (reusability, maintainability)
For a static site, I would personally choose Astro or SvelteKit—both of those are highly optimized for static sites. In my opinion the syntax of these frameworks feels closer to plain HTML/CSS/JS than React and will naturally teach you more about the fundamentals as you go.
If you’re just starting out, the most important thing is to really make sure you learn your JavaScript Web APIs and other HTML and CSS fundamentals as you go. The better you know these, the better your websites will be regardless of which framework or tools you choose. These fundamental skills will have the highest reward for you in the long term.
This seems more like a business analytics kind of question than a programming question. But I'd imagine you'll get less sales without a guest checkout option than with if that answers your question.
You might manage to mitigate that a bit by letting folks fill their cart and start the checkout process and only require them to sign in at the last minute after they're already pretty invested in checking out.
as always, the answer is it depends. I've worked on B2B websites where you can't even see the real pricing until you sign in so it is impossible for that application to add a guest checkout. it really depends on your requirements.
From the whole blog post, the thing that caught my eye was the side remark regarding SPAs vs MPAs. It was one of those things that people don't tend to think about it but once someone touches on the subject, the problem become obvious. It seems that modern javascript frameworks focus on SPAs and try to shoehorn the concept everywhere, even when it clearly does not fit. Things reached a point where rewriting browser history to get that SPA to look like a MPA is now a basic feature of multiple pages, and it rarely works well.
Perhaps it's too extreme to claim that MPAs are the future, but indeed there are a ton of webapps that are SPAs piling on complexity just to masquerade as MPAs.
HTTPS is already end to end encrypted. It's literally what it's for. TLS is everywhere: SMTP/IMAP (emails), even OpenVPN.
What about it are you trying to improve on? There ain't much you can do on a website, if the connection is intercepted then everything falls apart because the attacker already has the ability to modify whatever your server is sending, so any encryption you'd do in JS is compromised before it even runs.
If you can make an app, then you can do something called certificate pinning which effectively gives the client the public key of the server to expect. It guarantees that the client will only talk to the right server, and if that is broken, then literally everything is broken and nukes are probably about to get launched.
Most encryption uses the same primitives: RSA/ECDSA/DH to derive a stream cipher and then it's pretty much always AES these days, or sometimes ChaCha20, and usually SHA1 (broken) or SHA256 for message authentication.
E2EE makes senses when you're building say, a messaging app. There the E2EE is that the user's device holds the keys, so even the server can't see the message even as it stores it and sends it to the other device.
I may at times only have access to HTTP only (No HTTPS) which is one of the reasons why I want another form of encryption.
Encryption with most VPNs are more secure than HTTPS. Yes, the connection between the VPN server and the web server is not encrypted with the VPN and only HTTPS. However the encryption between the VPN and personal device is superior, not because it is relayed. My understanding is that HTTPS is "secure" for basic use, just like Windows 11 is secure. But not secure from five eye agencies unlike VPNs and other like systems like Tor and I2P.
My goal is to have a user connect to a web server and have it not possible for the web server to know what is going on, nor can anyone snooping the packets in transit know what is going on. Not know the HTML structure, form field data, etc.
And you cant use self signed certificates because?
They provide the same level of encryption. The benefit of a domain and a trusted CA issued cert is that browsers/os will automatically trust that the server is who its said it is (ie you dont get a warning).
But if you import your servers root CA to your OS, then your OS (and browser) will automatically trust any cert issued using that root cert, thus you dont get a warning.
With or without a warning, it will still encrypt at TLS1.3
That sounds like a pretty straight forward and simple conversation.
Do you do code reviews? Have code owners? If you (or a set of people you trust) were required to sign off on changes on the base files that aren't supposed to be changed willy-nilly, you could catch it before it went to main
Yes, certainly. It sounds like some/most members of the team don't understand the stylesheet architecture of your project and it's vital to sort that out ASAP. The more time passes, the harder it will get to get everything back on track.
Try to avoid finger-pointing and this shouldn't be a very hard conversation (assuming they aren't super stubborn).
As a side note, the fact that you first address this issue on the Fediverse and not in your team makes me think that maybe there are some underlying issues regarding trust and open communication. You might want to further look into that. Take it with a large grain of salt though. I don't really know anything about your team so it's likely that I overdramatize the situation.
Web Development
Oldest