[renegadus]

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:

  button.onImmediate.click {
    header.text("They clicked!")
  }

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?

[bloudermilk]

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.

[renegadus]

I appreciate your feedback.

> 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.