You know what the issue is? People are so focused on being able to scale their idea to billions of users before they even start building it. So someone today would start using Kubernetes for their website with 5 visitors. I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
The experience of developing a simple website using React is orders of magnitude better than using html and CSS. Reusable components, loops, and separating data from presentation go a long way even in the simplest of pages. Sure, you don't need React, you could use Jinja or any other templating library, but React is pretty good at what it does. As for Next.js, it makes it super easy to develop using React.
The biggest problem with React is the JS bloat that's sent to the browser. Though as long as you do server side rendering and don't even ship the JS to the FE, Next.js is a pretty good static site generator.
> The biggest problem with React is the JS bloat that's sent to the browser.
There's a web app I use (ClickUp) where I have to watch UI elements load one-by-one, like I'm back on dial-up or something. I'm convinced they end up with more CPU load just doing all the TLS handshakes than they would if they just sent me all the HTML in one go.
> The experience of developing a simple website using React is orders of magnitude better than using html and CSS.
Isn't this rather circular? It's only this way if you already know React well enough to be fluent. Learning React and all it's conceptual baggage is a huge jump from understanding html/css/basic js plus the HTTP request/response cycle (all things which you'll need to understand even if you do use React)
Honestly - this sounds a little like Stockholm Syndrome. I've spent a long time actively avoiding React and nothing I've read or seen has led me to think that was a poor decision. Quite the opposite - I feel progressively more vindicated with every passing year.
There is CAPRI (https://capri.build/docs/why/) which allows using both interactive (they call them "islands") and non-interactive Vue/React/Svelte components to build your static website. So I can still split the website into reusable Vue components and if the components are not interactive - I can end up with no JavaScript at all. CAPRI also supports getting your content from several headless CMS (Storyblok, TinaCMS, Sanity, Contentlayer) so once you build the layout content can be easily added or changed.
>The experience of developing a simple website using React is orders of magnitude better than using html and CSS.
OK well I've done both and I have to say no it's not, but probably my definition of simple is simpler than yours. It also seems to me that the original comment used a simpler than yours model of simplicity.
>Next.js is a pretty good static site generator.
my experience is that Next.js is a lousy static site generator, but reasonable if you want to use React.
I explained why in the rest of the comment. Reusable components, code generation, etc. are a godsend. Copy pasting sections across and within pages, and not being able to generate code is hell.
Simple is better, but bare doesn't necessarily mean simpler.
We're talking about "simple website". You can use any number of LLMs to generate you a boilerplate or use something simple and lightweight like Bootstrap. For a simple website, the things you're talking about add time and effort, not remove them - especially for someone who knows how to do neither.
This. It is way faster to build a decent looking prototype using JavaScript Framework Bloat than shipping something leaner. Performance and maintainability are luxuries that make sense to focus on later. This is in no way analogous to using k8s from the get go, which is a technology focused on being flexible and generic enough to maximize choice, rather than speed or developer experience.
Yes, yes, I you want to make a plain HTML form its fast enough, but for a startup 99% of customers want to feel assured by it having a look and feel which simply takes too much time if you are building things up without a framework
A couple of years ago, somebody tweeted something along the lines of "did you know you can POST an html form without using javascript?". The replies were incredible, because they revealed how many folks could write a full blown React app to post a form, but didn't know how to do it with just <form>.
I agree: it's terrible that kids would go straight to React without trying plain html + js first, but they do this because they often don't know any other way of doing it.
It doesn’t matter if you have five visitors or 5 million you presumably want your website to stay online so you need something that restarts the processes when they die, etc. Honestly building and publishing a docker image is super simple. There are numerous hosted kubernetes solutions to deploy it to as well. I don’t think that using next JS or using Kubernetes means you are inherently over complicating anything, and this is coming from someone who prefers minimal technology (I personally don’t use next JS, but I see the value in it for others)
You don't need to deploy orchestrators to serve static html/js files.
> In your opinion, because they’re stupid?
If they are doing that to keep nginx running, that might be the case or they are super clever to do that for a higher salary at the cost of their employer.
Publishing a Docker image is simple. Managing a Kubernetes cluster, even hosted, may be much more complex, for no added benefit.
Throw your container on a VM, make systemd or even runit keep it running. It scales fine to half dozen boxes if needed. Same for your Postgres DB. For extra fancy points, keep a hot standby / read replica, and pick up any of the manual switch-over scripts.
Should keep you running until dozen million DAU, with half-day spent on the initial setup.
SRE here. First off, updating control plane/kubelet is nightmare in itself but let's assume you are running managed Kubernetes somewhere so that's taken care of.
Kubernetes out of the box is not ready to go. What Ingress are you going to use? Ingress-Nginx. Cool cool, How is that getting deployed? Helm Chart. How do we keep track of that being kept up to date and who deployed it? ArgoCD. So who is going to teach all CRDs for Argo and how they work with each other? SREs. You understand we dislike the devs and last thing we want to do is hold classes they don't want to learn? JUST BUILD A PLATFORM. And here we go.
So out of box, most people deploy Kubernetes + 8 "plugins" and it's Frankenstein monster that's you have to manage or it will decide to kill all the workloads one day.
EDIT: I'm didn't even discuss certificates for that ingress or all monitoring/logging this cluster will need to make sure it's properly operating.
It has a terrible first time user experience. Once you accept that developer experience means user experience for 19/20 programmers, it’s imperfect. For example even though programming is all about reading, the average programmer looks more like the average person than it ever was, and the average person hates reading. So Kubernetes bad. IMO this is why so much success has been found building SaaS on top of Kubernetes.
Because you have to have and manage a Kubernetes cluster, that is not something easy. Moreover scaling is not always automatic, you don't tell Kubernetes "scale this application" and it works, if the application is a monolith. You have to write it using a microservices architecture, something much more difficult.
Also, managing a CI pipeline isn't something very easy to start with, there are entire teams in companies that only do that.
In contrast running a simple server is much more simple, you install a Linux OS (probably Ubuntu server, or Debian), install a web stack (for example Apache, PHP, Mysql or Postgres these days), copy the files of your website in the root directory (/var/www), or if you are fancy pull a git repository on the server so you can update it with a simple "git pull", if you need more websites on the same machine configure virtualhosts (or use one of the many software that have a GUI to configure virtualhosts).
The second solution is much more simple, in fact is the most used solution as far as I see. Most websites doesn't need high availability, if the website of the bike repair shop that I have 100 meters down the street goes offline for a couple of minutes or even one day because I'm doing maintenance on the server really nobody notices it.
It’s not necessarily that it’s hard, but to be effective with kubernetes you need to understand a lot of infrastructure concepts like DNS, load balancing strategies, docker, storage drivers, service discovery, what exactly a pod is, what exactly a container is, etc.
It’s a lot of up front knowledge needed for marginal benefit at small to mid scales.
There’s a lot of steps if the “write your deployment yaml” step.
If you are small or mid scale and you need lots of compute between 8
5 to 8 on Monday till Friday it basically the best thing you can you to schedule your workload.
If you need some things like load balancing and zero downtime deploys etc you probably will build your own k8s which is often worse
Or you can deploy on app engine, lambda, firebase, etc.
Kubernetes is not the only game in town.
Sometimes shipping asap is more important.
As with just about anything in tech, it’s about tradeoffs.
I may be biased, since I worked in devops before k8s came out, but building a decently scalable system architecture with load balancing and rolling deployments is pretty straightforward with monolithic systems. Especially since service discovery isn’t really a concern. Horizontal scaling works well in many many cases.
Realistically any app simple enough to be deployed by hand with a few docker containers will not be difficult to convert to k8s anyway.
> I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
Maybe the students want to learn a popular framework in order to have job? That is exactly the reason I learned Nextjs and lo and behold, it proved to be useful for me and my employer..
I used to think that but I've changed my option in the last couple of years. I think be bar for a bare bones app is starting to get so high you can no longer afford not to think of it as an entire platform from day one. I think AI will make this bar even higher.
The other thing is apps mostly work now. Even 10 years ago people (including devs) would tolerate a flaky application. Now days everyone expects five-nine uptime and zero data loss and seamless cross platform functionality.
If you start off with some "toy" version you fool yourself into thing this idea is not as hard as it sounds. Then once you hit the wall of production reality you start to realize just how hard something is going to be in production and that's why the market is still open for your idea. Its why there are so many profiles on github with tens or hundreds of abandoned projects.
There's probably a lot of greybeards out there that will say all you need on a computer is a terminal and emacs. They might be right but you cannot scale/sell it and everything in-between is just a compromise.
> I've seen many students use Nextjs for websites that could easily be written with plain html + css, and some chart library.
Students are the one case in which I'd say this is good.
The vast majority of the stuff students do is not going to be successful. The purpose here is not to build stuff, it's to learn how to build stuff, and in that case exploring technologies is a net win.
The chart library is presumably JavaScript.. so what's the fundamental difference? Next can just spit out html/CSS/js that you can host on GitHub pages or S3. But they get familiar with a popular full stack framework I honestly don't see what's that controversial with the scenario.
