5 ms·

Be aware that the paradigm of Vaadin (known as IT Mill Toolkit) is leaning toward server-side. GWT is 100% client-side (plus RPC). My guess is that Vaadin did

Be aware that the paradigm of Vaadin (known as IT Mill Toolkit) is leaning toward server-side. GWT is 100% client-side (plus RPC). My guess is that Vaadin did a bit of UI rendering (prep-ing the HTML) on server-side then send it to client.

DenisM 17y ago
That was my impressin too. Are they trying to erase the boundary between the server and the client? If that's the case it's a terribly misguided thing to do...
- slig 17y ago
  Indeed. I'd love to use my Java knowledge to write pretty interfaces, but on the server side I'm better off using Python.
  - huyng 17y ago
    Agreed, I definitely feel most comfortable with my Python on server-side, but the UI ability on this thing is beautiful. Too bad... I wish I was at JavaOne so I could ask these guys some questions regarding how easy it is to separate the two components.
    - cptobvious 17y ago
      Vaadin keeps the application state on the server, but the presentation (HTML) is 100% generated on the client side. Changes in server-side state are serialized and sent to client in compact User Interface Definition Language (UIDL). This is obviously a more secure approach to writing web apps, since the state is safe on the server. So no pre-rendering of UI on the server..
    - peppe 17y ago
      Yeah. Every component has a server side and a client side. Client side has all the rendering stuff in it while the server side has the business logic. That way the functionality can't be hacked as the client side is just responsible of sending input to the server, where all the hard work is done.
    - jonatan 17y ago
      You can ask all the questions on your mind on our forums (http://vaadin.com/forum/ http://vaadin.com/forum/). You don't need to attend JavaOne to get the hard questions answered.
- michaelneale 17y ago
  Yeah I am trying to find out. They are here at javaone - doing too much UI on the server side does seem like a real mistake for a tool like this. One of the nice things of things like this (and cappaccino) is that the server side becomes freed from worrying about what the client is doing/has open etc...
  - jojule 17y ago
    This is a matter of taste - benefits of the server-driven architecture are: no limits from the server, no GWT recompilation, direct access to server-side API and resources, better security, full Java virtual machine, full tooling and debugging support. Downsides are: more client-server traffic, more data to store in HttpSession.
    - DenisM 17y ago
      I think the most impmortnat problem is trying to hide the netowrk under an inhenrelty leaky abstraction: http://www.erlang.org/pipermail/erlang-questions/2008-May/035207.html http://www.erlang.org/pipermail/erlang-questions/2008-May/03...
      - michaelneale 17y ago
        yes that is what worries me - I like network stuff to be explicit.
        jojule 17y ago
        There are multiple levels of control: 1) for each UI component you can select to send events immediately to server or alongside the next "packet" sent to server. 2) as we are building on top of GWT - you have the full GWT-based RPC also if you want to do the communication manually.
jonatan 17y ago
Greetings from the company developing Vaadin :) Yes, Vaadin is a server-side framework. Server-side is not for everyone, but there surely is a place for Vaadin. For example issues with trusting the code that's executed on the client are greatly relieved this way. You could think of Vaadin as the Swing / SWT for web applications. Sitting in between JavaFX (plugin required) and Java Server Faces (html required). Vaadin is great for desktop-like applications in the webbrowser, but doesn't really fit the RESTful type of applications. If you have questions, just visit our forums at http://vaadin.com/forum http://vaadin.com/forum and ask away! There are plenty of experts waiting for challenging questions ;)
jojule 17y ago
Vaadin is actually sending only small JSON snippets to client-side. These are instructions to browser on what to draw. Like: "add a button to layout", "change the contents of a label to say hello", etc. All rendering is done in client (using GWT). So the client defines what the button looks like, how it behaves, ...
huherto 17y ago
yeah, I was actually just noticing this. I would lean more towards the 100% client-side + RPC.

DenisM 17y ago

That was my impressin too. Are they trying to erase the boundary between the server and the client? If that's the case it's a terribly misguided thing to do...

slig 17y ago
Indeed. I'd love to use my Java knowledge to write pretty interfaces, but on the server side I'm better off using Python.
- huyng 17y ago
  Agreed, I definitely feel most comfortable with my Python on server-side, but the UI ability on this thing is beautiful. Too bad... I wish I was at JavaOne so I could ask these guys some questions regarding how easy it is to separate the two components.
  - cptobvious 17y ago
    Vaadin keeps the application state on the server, but the presentation (HTML) is 100% generated on the client side. Changes in server-side state are serialized and sent to client in compact User Interface Definition Language (UIDL). This is obviously a more secure approach to writing web apps, since the state is safe on the server. So no pre-rendering of UI on the server..
  - peppe 17y ago
    Yeah. Every component has a server side and a client side. Client side has all the rendering stuff in it while the server side has the business logic. That way the functionality can't be hacked as the client side is just responsible of sending input to the server, where all the hard work is done.
  - jonatan 17y ago
    You can ask all the questions on your mind on our forums (http://vaadin.com/forum/ http://vaadin.com/forum/). You don't need to attend JavaOne to get the hard questions answered.
michaelneale 17y ago
Yeah I am trying to find out. They are here at javaone - doing too much UI on the server side does seem like a real mistake for a tool like this. One of the nice things of things like this (and cappaccino) is that the server side becomes freed from worrying about what the client is doing/has open etc...
- jojule 17y ago
  This is a matter of taste - benefits of the server-driven architecture are: no limits from the server, no GWT recompilation, direct access to server-side API and resources, better security, full Java virtual machine, full tooling and debugging support. Downsides are: more client-server traffic, more data to store in HttpSession.
  - DenisM 17y ago
    I think the most impmortnat problem is trying to hide the netowrk under an inhenrelty leaky abstraction: http://www.erlang.org/pipermail/erlang-questions/2008-May/035207.html http://www.erlang.org/pipermail/erlang-questions/2008-May/03...
    - michaelneale 17y ago
      yes that is what worries me - I like network stuff to be explicit.
      - jojule 17y ago
        There are multiple levels of control: 1) for each UI component you can select to send events immediately to server or alongside the next "packet" sent to server. 2) as we are building on top of GWT - you have the full GWT-based RPC also if you want to do the communication manually.

jonatan 17y ago

Greetings from the company developing Vaadin :) Yes, Vaadin is a server-side framework. Server-side is not for everyone, but there surely is a place for Vaadin. For example issues with trusting the code that's executed on the client are greatly relieved this way. You could think of Vaadin as the Swing / SWT for web applications. Sitting in between JavaFX (plugin required) and Java Server Faces (html required). Vaadin is great for desktop-like applications in the webbrowser, but doesn't really fit the RESTful type of applications. If you have questions, just visit our forums at http://vaadin.com/forum http://vaadin.com/forum and ask away! There are plenty of experts waiting for challenging questions ;)

jojule 17y ago

Vaadin is actually sending only small JSON snippets to client-side. These are instructions to browser on what to draw. Like: "add a button to layout", "change the contents of a label to say hello", etc. All rendering is done in client (using GWT). So the client defines what the button looks like, how it behaves, ...

huherto 17y ago

yeah, I was actually just noticing this. I would lean more towards the 100% client-side + RPC.