I've been lucky to observe KWeb since its earliest days and some of the missing context on the website, I think, is that the author takes the position that the way we build webapps is fundamentally wrong.
From his perspective it seems that the "division" between frontend and backend are an implementation detail that accidentally became of defining feature of how we write software for the web. Websockets are a way to correct this by making the delivery channel dumb and universal while focusing application development in a single software architecture.
It reminds me of the principle of brutalist web design (https://brutalist-web.design/). Brutalist design, while not completely beautiful, makes me ask, "What were we trying for when we first made HTML? Does the tool really fit those goals anymore?" While I hope that KWeb grows up to be something big, at a minimum it asks a lot of questions about why applications for the web are architected the way they are.
The problem with this approach is that the “division” is so fundamental to the performance of web applications that it can’t simply be abstracted away. When real applications encounter latency and unreliable connections at scale the abstraction will leak. At that time teams will be forced to dedicate efforts just to overcome the deficiencies in the architecture.
I don't think there is any reason, in principle, that Kweb can't be just as efficient as any other web application.
This is because Kweb doesn't entirely abstract away the client/server separation in one important sense. When you attach a callback to something you normally do it like this:
button.on.click {
header.text("They clicked!")
}
This is less efficient than it could be because it is needlessly doing a server round-trip. So for situations where you're only modifying client state you can do:
The example you make here is exactly what I'm referring to when I say the "abstraction leaks". From the homepage:
> Kweb ... virtually eliminates the separation between browser and server from the programmer’s perspective.
In my opinion, we can't say the separation has been "eliminated" if I'm constantly having to ask myself "should I handle this event on the server or the client via `onImmediate`?"
What seems more likely to happen, is that inexperienced developers simply won't ask the question at all and months later the customer will ask why their dashboard page is taking 60 seconds to load. The senior engineers will be tasked to fix it only to find out that the page is making dozens or hundreds or thousands of N+1 round trips to the server.
This has been my experience being asked to come in to fix MeteorJS apps. Teams of web developers not understanding that the client/server interface is not free and that poor engineering practices have severe compound effects.
> In my opinion, we can't say the separation has been "eliminated" if I'm constantly having to ask myself "should I handle this event on the server or the client via `onImmediate`?"
Well, I said "virtually eliminated" :)
I think it's an exaggeration to say that the programmer must constantly ask themselves this, it's only relevant when adding an event listener. You'll get along just fine if you never used onImmediate, it just means your webapp may not feel quite as snappy as it could be.
To me this seems like a very small price to pay to avoid having to bifurcate your application across client and server - particularly given that it's not even compulsory, it's an optional optimization.
> What seems more likely to happen, is that inexperienced developers simply won't ask the question at all and months later the customer will ask why their dashboard page is taking 60 seconds to load. The senior engineers will be tasked to fix it only to find out that the page is making dozens or hundreds or thousands of N+1 round trips to the server.
An unnecessary roundtrip may add 200ms of latency across a typical internet connection to the speed with which the page responds to an event, but I can't think of any circumstances under which this would delay the page render.
Moreover, a website built without onImmediate should work just fine, it just might not quite match the performance of a well-written client-side app.
> This has been my experience being asked to come in to fix MeteorJS apps. Teams of web developers not understanding that the client/server interface is not free and that poor engineering practices have severe compound effects.
There is only so much a framework can do to save programmers from themselves. In this case the risk is that the app may feel a little more sluggish than it otherwise would, a difference that users might not even notice.
It may be possible to automatically identify candidate event handlers which don't appear to be modifying server-side state and provide a nice list to the programmer, but I'd likely only invest time in this if it proved to be a significant issue in practice.
From his perspective it seems that the "division" between frontend and backend are an implementation detail that accidentally became of defining feature of how we write software for the web. Websockets are a way to correct this by making the delivery channel dumb and universal while focusing application development in a single software architecture.
It reminds me of the principle of brutalist web design (https://brutalist-web.design/). Brutalist design, while not completely beautiful, makes me ask, "What were we trying for when we first made HTML? Does the tool really fit those goals anymore?" While I hope that KWeb grows up to be something big, at a minimum it asks a lot of questions about why applications for the web are architected the way they are.