Kweb: A new approach to building rich webapps, in Kotlin

by pplonski86 • 8 years ago

88 38 8 years ago

setheron• 8 years ago

Too much magic. Debugging this would be a real pain with everything happening over websockets

renegadus16• 8 years ago

It's not so bad - it seems like there is a lot of magic but the library is a fairly thin layer on top of JavaScript/DOM.

mpweiher• 8 years ago

I would expect it to be quite the opposite: it looks like a true hexagonal architecture for the web, with the thinnest of adapter for the client part, which is nearly perfect.

You can debug all your logic on the server.

I'd guess a/the big drawback would be no offline capability. But if you're fine with that (many are), then why not?

renegadus16• 8 years ago

I'm kweb's creator, I hadn't heard the term "hexagonal architecture", I'll read up on it, thank you for the kind words.

You are correct that, since kwebsites are server-driven, there is no significant offline capability.

But then the requirements of many websites often rule that out anyway, my strong suspicion is that this won't be a dealbreaker for many people.

renegadus16• 8 years ago

Note: reddit discussion here: https://www.reddit.com/r/programming/comments/a4dtp2/kweb_a_...

xytop• 8 years ago

What about mixing frontend with backend?

That’s terrible.

sambull• 8 years ago

Back to PHP3 and coldfusion days

rckclmbr• 8 years ago

There were a lot of things i really liked about coldfusion, like how easy it was to build reports, and how easy it was to get started. cfdump is still one of my favorite debugging tools. Everything else, not so much :)

renegadus16• 8 years ago

Kweb has very little to do with PHP3 and coldfusion, I suggest taking a closer look at it.

renegadus16• 8 years ago

That assuming your application's architecture should be split vertically into front-end and back-end, but what if a horizontal split makes more sense?

gpm• 8 years ago

I don't think mixing is the right way to describe this. It's just moving more of the ui logic to the server.

jnovek• 8 years ago

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.

bloudermilk2• 8 years ago

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.

renegadus16• 8 years ago

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?

nimmer• 8 years ago

Nim + Karax allow creating single-page applications without "magic":

https://nim-lang.org/araq/karax.html

Working example: https://forum.nim-lang.org/

renegadus16• 8 years ago

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

Here is the equivalent in Kweb:

  fun main() {
    Kweb(port = 2734) {
        doc.body.new {
            button().text("Say hello!").on.click {
                println("Hello simulated universe")
            }
        }
    }
  }

This compiles and works.

Matthias2472• 8 years ago

The first seems to add new DOM nodes with text on every click. The second one doesn't. So they don't seem to be equivalent.

lmm3• 8 years ago

Sounds like a similar approach to Wicket, which remains the best web UI framework (possibly the best framework period) I've ever used.

renegadus16• 8 years ago

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.

lmm3• 8 years ago

Glad to hear it. How Scala-friendly are the interfaces?

rkagerer• 8 years ago

Doesn't blurring the client/server divide induce the programmer to unwittingly introduce more latency?

renegadus16• 8 years ago

Kweb has a neat solution to this, I outline it in this Reddit comment: https://www.reddit.com/r/programming/comments/a4dtp2/kweb_a_...

sorokod• 8 years ago

Is there any documentation, API or otherwise available?

renegadus16• 8 years ago

Unfortunately that's one area where Kweb is currently immature, however beyond what's on the website there are a number of examples that should help:

https://github.com/kwebio/core/tree/master/src/main/kotlin/i...

Also, if you use IntelliJ IDEA then the IDE will do a lot of the work for you in figuring out the API.

toyg2• 8 years ago

Reminds me of the principles behind the original asp.net, all the way back in 2000. At the time there were no websockets, so it was done with constant post-back, but the principle was fundamentally the same: develop like it were a local app, the framework will take care of the rest. Let’s just say it didn’t get very popular in my neck of the woods. I’ve since moved on to other things so I don’t know what modern asp.net does, but I bet you can still code this way if you really want.

(Not that you should, imho: trying to bypass the fundamental architecture of the web is typically a way to end up in debugging hell.)

sixdimensional• 8 years ago

First, there was ASP, which was a lot like PHP, ColdFusion or Perl/CGI - mixing inline back-end code and HTML/JS/CSS/etc - but of course executing all back-end code on the server.

ASP.NET WebForms came along and is still supported, and tried to make developing web applications similar to developing desktop applications in WinForms. I did that, it worked.. it was clunky at times (but it worked). Of course, mostly this was all server-side with just HTML/JS/CSS interacting.

A long time ago the dominant model became ASP.NET MVC which is a typical server-side MVC architecture.

Recently, Microsoft offered a new "old" paradigm through Razor Pages which are a lot like old ASP was.

If you look at things like React (or the view layer in Angular, etc.), it turns out that the web component / control model used in WebForms (server-side) is quite similar to the client side model used in React. The main difference of course being, one running client-side primarily (React) and the other server-side (WebForms). It gets even more interesting as a comparison when you talk about server-side React view rendering.

toyg2• 8 years ago

Yep, I was thinking of the original WebForms.

ciconia• 8 years ago

There's also LiveView coming to Phoenix (Elixir). This might be a new trend in web frameworks.

ttty2• 8 years ago

I agree on writing environment (client/server) agnostic code, but not in this way. Js code should definitively run on the client and here is why:

- Instant feedback, no matter how bad is your connection: here if I click on something and there is no internet, I won't see a loading icon. You probably have to hack it. - I'm not sure how it will scale and if it scales will be way more expensive than just using rest api (sockets are more expensive)

probably more problems.

I'm the creator of this game http://bitplanets.com which has a lot of shared code that runs both on the client and the server side. Some validation is done on the client (so you don't even hit the server if it fails + get instant feedback that your action is successfull or failed) and the same validation is done on the server side as well (so you can't hack it).

Examples:

- When you send a ship it will show a temporary ship immediately even if the server didn't receive yet the ship. If the client validates most likely it will be a valid ship (unless you hack it, but server side will deny your ship). Then when the server comes back saying that the ship is valid then the ship is not temporary anymore.

If you had a java backend everything would be so much more complicated. This is what I mean by having agnostic code, this validation function doesn't really care if is run on your client or on your server.

renegadus16• 8 years ago

here if I click on something and there is no internet, I won't see a loading icon.

Fortunately, that's not so - Kweb has a neat way to handle it - outlined here: https://www.reddit.com/r/programming/comments/a4dtp2/kweb_a_...

Kweb: A new approach to building rich webapps, in Kotlin

Related Stories