I have a .net desktop app that I need to port to web. It’s classic RIA material. Trouble is - there are no .net technologies that allow you to do this in the way that GWT or Vaadin does, where you really don’t need to understand the full stack.
My immediate thought was to create a java-based client that will interact with our .net backend using WCF/json. I’ve tested the principles and it works a treat. However - there are a lot of common classes that are used by both server and front-end with a whole smart client cache (metadata). Consequently it means having to convert that .net code to java and then maintain it going forward.
So then it struck me - all communication between browser client and vaadin server is http and json. So wy not just replicate the Vaadin server component in .net? It could still serve the GWT/JS files as normal but the http interaction would then be with .net components.
I’m pretty sure that I would not be the only person who would benefit from such a hybrid.
So the question is - any reason this is not achievable? Still have a problem with maintenance as new Vaadin (server) releases would need to be incrementally ported. However I guess that Vaadin is a reasonably stable beast and so may not be that frequently required.
Also would not have a designer in visual studio - but I could live without that (people seem to put up with the lack of working designer in GWT).
If you think that Vaadin works similar as dekstop app you are wrong. Read chapters from about Vaadin architecure once again. Vaadin simplifies creation of the RIA apps, but not release you from issues like: mem usage per user, network usage, avoid sluggish ui, browser sandbox, etc
Porting application from desktop to web is complex task. You can’t copy and do some changes in class to Vaadin requirements. It’s not work that way.
You asking about porting VAADIN to .NET. IMHO it’s not possible due ASP .NET and Servlet API have fundamental differences and almost all DOTNET web solutions based on ASP.
What I mean by the same as a desktop app is that you can achieve a similar rich windowed experience, in as much as it isn’t page-based. Much as you would create a desktop app by creating windows and adding controls to them where it is all in one language. This is entirely different from regular web approach of creating a page and adding html controls to the page and then putting code in essentially comments in a different language. Yuk. I understand the differences in terms of where memoery is being used, network usage and sandbox. I come from a long career starting with writing assembler on mainframes so I’ve pretty much seen it all at the nuts and bolts level and despite all the new names for things there are very few new concepts that weren’t in existence when I was writing code back in the 80s!
dotnet web solutions typically use asp.net hosted in IIS. But you don’t have to do it that way - you can have a windows service sitting listening on a port and just acting as an http server. But regardless I thought all interaction between the vaadin browser components and the server components is via json sent over http. Therefore this is an interface and it shouldn’t really mater what you have handling those http calls as long as it understands what json is coming and what it needs to send back to make things happen on the client (browser). Certainly when I start Fiddler and run my little Vaadin app I can see the expected http traffic.
When I type text into a Vaadin web control an http request is sent containing that text and the server responds with anything it wants to do to any of the web controls. Simples. So replicate the server processing in .net, the thing that parses the http requests, processes and then sends an http response and you have a .net port. No?
I can’t see how it cannot be that simple given that the browser does not understand java. It has no idea what is running on the server side and it doesn’t give a damn - it just has a clearly defined interface - structured json messages sent via http.
Just because the browser to server communications is based on HTTP of JSON, JavScript, HTML, CSS doesn’t mean that the server component is not complex and can easily be ported to other platforms.
I should think it would be a huge task to convert Vaadin to use .NET because it’s written in Java (and its APIs) and assumes a Java servlet-based container. The browser is not the issue.
The assumption that .NET and Java web apps can be easily ported is not correct.
Having looked through the source the only bit that seems it would require some reworking is the servlet part - but that seems a small bit to me and similar technology will exist in .net - a web server is a web server is a web server.
The other question area is around the GWT compilation of the client side components into JS etc. Looking at the Vaadin source on github I can see there is reference to GWT and it seems to call the compiler, which wouldn’t be possible under .net but shouldn’t you be able to take the compiled items and serve them up… don’t need to actually do a GWT compile unless changing the Vaadin components?
I confirm what David said. “a web server is a web server is a web server” IS NOT a ServletContainer . This would be the first ( very large ) hurdle to overcome. Though you have similar constructs in .Net they are still very different. It will be a huge undertaking to port vaadin to .net.
A better option would be to write a java code generator, to convert .Net source to Java source for the classes that is common to the server and front end. Then write a your Vaadin front-end in java.
I have to ask you guys - do you have .net experience or are you mainly java as I’m mainly .net?
I found this on MSDN:
“Servlet Equivalents in ASP.NET
As we showed in the JLCA Conversion of Servlets section, there are two ways to replace servlet functionality in ASP.NET: using a codebehind for an ASP.NET page with no HTML, or creating an HttpHandler.”
Http Handler was precisely what I was thinking.
The obvious port is to translate many thousand LOC of our .net code to java but we then have to develop our product in both visual studio and eclipse.
The less-obvious port is to translate Vaadin server to .net - this means we still get to develop our product in VS but also makes it reusable for other people. .Net is seriously lacking in single-stack RIA.
I think it would be possible, but as Petrus said, this would be quite a huge effort. Vaadin would have lots of experience that would be usefull to implement this. And, we have had some internal wild speculations/jokes about its feasibility, and we even made an aprils fool about getting into .NET world
But, don’t hold your breath, there are no plans to jump to .NET ATM.
