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.
Interesting. Just for fun I created a side-by-side with Kweb of one of their simple examples.
Here is kerax:
var lines: seq[kstring] = @[]
proc createDom(): VNode =
result = buildHtml(tdiv):
button:
text "Say hello!"
proc onclick(ev: Event; n: VNode) =
lines.add "Hello simulated universe"
for x in lines:
tdiv:
text x
setRenderer createDom
Whenever the DOM gets rerendered, it iterates over the the lines (or the "model" in general), and creates DOM elements from it. At least it looks very similar to React and Angular code, and they do exactly this.
I used Wicket for a major project way back in 2007 and worked with the creator of Wicket for a while - so it's almost certain I got some inspiration there :) Wicket was probably the first time I saw a web framework and thought - "wow, this web stuff can be elegant".
Wicket suffered because it straddled the transition from pure HTML to HTML+AJAX. It could do HTML+AJAX, and their solution was elegant, but it was an afterthought and Wicket wasn't really designed around it.
Kweb was designed from the ground-up for this world and this affords it many advantages.
Hmm, I'm not sure, but my guess is "not very" as I didn't really design it with usage from other JVM languages in mind.
The reason is it depends on some stuff like coroutines - and since Scala deprecated their delimited continuations plugin way back when, I don't believe Scala has any equivalent feature.
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:
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: When the user clicks it will be instant, as the instructions to modify the DOM are "preloaded" to the client on page render.Does that alleviate your concern? If not, can you elaborate on where you think the bottleneck is likely to emerge?