4 ms·

I'd argue web dev is largely a solved problem for large complex apps, but largely unsolved for simpler use cases. The problem is the amount of boilerplate and

I'd argue web dev is largely a solved problem for large complex apps, but largely unsolved for simpler use cases. The problem is the amount of boilerplate and tool complexity involved. In a large project, the boilerplate can become a small fraction of total work put in (hopefully), with most to the work spent expressing the logic of the application. In smaller projects, the boilerplate can be the vast majority of the work. Building a backend, a frontend, and a communication protocol between them (that includes reactivity). On the backend you need to learn HTTP/Websockets and a backend framework. On the frontend you need node, nvm, npm, yarn, React/Svelte/Vue. To do it right you need to implement automatic reconnect/resubscribe on reconnect, etc. Several projects try to reduce this complexity in various ways, but they all have trade-offs and I don't think we've found a sweet spot. Drag and drop tools like Squarespace and Retool are heavily biased toward expressing UI and integrate clunkily with backend logic. Backend-based tools like Streamlit and Pynecone (Reflex) get closer to a sweet spot IMO but are either severely limited in what you can do (Streamlit) or ultimately expose you to the full complexity of the frontend (Pynecone). I think further work in this space is warranted.

rickydroll 3y ago
> I'd argue web dev is largely a solved problem for large complex apps, but largely unsolved for simpler use cases. I have a good example of a small-scale problem that's a b** to solve with web technology. In a nutshell, I have an application which sends batches of data to a remote client. On the far end, I want a little web app that pays attention to the incoming queue of batches, display that list of batches in a browser, each batch with a progress bar, and be able to click on a batch to start the next stage of processing it when the batch is ready. making real-timeish display updates should be a canned function but there is a lot of frontend/backend stuff going on to make it work. > I think further work in this space is warranted. what he said.
syndicatedjelly 3y ago
Appreciate the comments. Guess what I'm frustrated with is the misallocation of smart people to real problems. But this isn't a Soviet economy, which I'm also grateful for.
syndicatedjelly 3y ago
I think there are already plenty of lightweight options for small projects. A static site can be written in HTML + CSS, hosted on GitHub, bundled with Jekyll, and deployed with GitHub actions. Django is super lightweight for small projects that need interactivity. These two solutions can address all of these examples I can think of for a "simple" site: - static blog site - interaction with a database - interaction with external APIs - simple games (Django is based in Python) - more complicated interactivity (pick a language that's compatible with Wasm)
- shrimpx 3y ago
  Good points but I think (a) this is a fairly complex stack with moving parts and multiple languages where (b) it's still pretty hard to build something as simple as "when I click this button, it reads something from disk and the webpage updates without reloading".

rickydroll 3y ago

> I'd argue web dev is largely a solved problem for large complex apps, but largely unsolved for simpler use cases. I have a good example of a small-scale problem that's a b** to solve with web technology. In a nutshell, I have an application which sends batches of data to a remote client. On the far end, I want a little web app that pays attention to the incoming queue of batches, display that list of batches in a browser, each batch with a progress bar, and be able to click on a batch to start the next stage of processing it when the batch is ready. making real-timeish display updates should be a canned function but there is a lot of frontend/backend stuff going on to make it work. > I think further work in this space is warranted. what he said.

syndicatedjelly 3y ago

Appreciate the comments. Guess what I'm frustrated with is the misallocation of smart people to real problems. But this isn't a Soviet economy, which I'm also grateful for.

syndicatedjelly 3y ago

I think there are already plenty of lightweight options for small projects. A static site can be written in HTML + CSS, hosted on GitHub, bundled with Jekyll, and deployed with GitHub actions. Django is super lightweight for small projects that need interactivity. These two solutions can address all of these examples I can think of for a "simple" site: - static blog site - interaction with a database - interaction with external APIs - simple games (Django is based in Python) - more complicated interactivity (pick a language that's compatible with Wasm)

shrimpx 3y ago
Good points but I think (a) this is a fairly complex stack with moving parts and multiple languages where (b) it's still pretty hard to build something as simple as "when I click this button, it reads something from disk and the webpage updates without reloading".