Home » Eclipse Projects » Eclipse Scout » In 2016, Eclipse Scout will get a brand new HTML5 Renderer
| In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1633416] |
Tue, 24 February 2015 16:29  |
Eclipse User |
|
|
|
It is our belief that the future of business applications mostly lies in the domain of web applications. In consequence, Eclipse Scout needs to provide the best possible web experience for the users of Scout applications. And to achieve this goal for the 2016 release, we already have started to write a new Scout web rendering engine. This engine is directly based on HTML5/CSS3 standards. Thanks to this substantial investment, Scout applications will be able to take advantage of the latest web technologies and comply with the new de-facto standard for web applications.
This decision also implies that future Scout web applications are no longer based on the Eclipse RAP project. At the same time, discussing this topic extensively with our customers, we found that their demand for the existing Swing and SWT rendering components no longer matches the necessary expenses to maintain these components. This is why we decided to discontinue the Scout SWT and Swing desktop rendering components after the Eclipse Mars release.
As this is a significant change, we like to start talking about it early and have also written a corresponding blog post.
The purpose of this forum post is to collect public feedback on this change. Please feel free to ask questions or talk about your concerns.
[Updated on: Thu, 03 September 2015 06:10] by Moderator |
|
| | |
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1634379 is a reply to message #1634289] |
Wed, 25 February 2015 03:34  |
| Eclipse User |
|
|
|
@Santo Mota:
Scout and desktop applications: Yes, you are right, according to the current planning, and starting with 2016 Scout will no longer provide a desktop rendering component. However, it is important to see that this might change again in the future. The clear separation of the application model from the UI rendering technology will not be touched, and the possibility to add a desktop renderer in the future remains intact. Depending on the needs of our commercial customers this topic might come up any time or not. And if we invest in a Scout desktop renderer again, this will likely be based on JavaFX.
Scout and multi-device support: This is scheduled for 2016 too. We would hate to loose the multi-device support that we have now. Therefore, the new HTML5 renderer will come with multi-device support as well. In this respect we do not expect that much will be changed, as we need the capability to write a Scout application in Java once and having it rendered in desktop browsers, on tablets and on mobile devices without any code changes.
I hope to have properly addressed you questions in the statements above, and please, continue this discussion until you feel comfortable with the answers.
|
|
| | | |
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1636557 is a reply to message #1635072] |
Thu, 26 February 2015 03:45 |
| Eclipse User |
|
|
|
Kay Dohmann wrote on Wed, 25 February 2015 16:59But for me, I think having multiple renderers is also a very great feature. I always also need a standalone version of my apps. And this can easily be done by generating a desktop app.
As you do not plan to touch the separation of the application model and the UI rendering technology, is it possible that the old Swing and SWT rendering components will still work? Or will you accept community based work on those components to make them work with future Eclipse Scout versions?
@Kay Dohmann:
Thank you for your feedback and welcome on the Scout Forum.
To be sure to avoid any misconception: with the Mars Releases (June 2015) you still will have the Desktop UIs (Swing and SWT) as you know them today. In order to inform our community early and to allow the community take part in the discussion well ahead of this significant changes we are talking about the N-Release (June 2016) well ahead of time.
Regarding the continuation of the desktop renderers: We expect that the transformation of Scout to a Java framework will break the existing rendering engines. And from our early estimates we think that the necessary work to make them work with the OSGi-free version of Scout will be substantially larger than that for normal release upgrades (and for the SWT renderer more work than for the Swing renderer).
The Scout team is aware that the possibility to create web and desktop applications is a strength of the framework as we know it today. And personally, I did appreciate this feature as well. However, the principal issue was mentioned
by Matthias: so far, we did not find anyone ready to invest in the Swing or/and the SWT renderer. The major projects of our company (applications we sell) have decided to migrate to the new version of Scout and to become web application only solutions. Some other company projects have decided to stay on a version of Scout providing Desktop renderers (they benefit from the Long Term Support that our company is offering). When we started to discuss the roadmap with our customers, we were not so sure about their reaction. This is why we were organizing 1:1 discussion with each customer and for the moment they follow the strategy of BSI.
Now if someone is ready to invest on any Desktop renderer, we will do our best to support such a project. Either by reusing the existing code and transforming it to the new OSGi-free version of Scout or by starting a new rendering engine from scratch (based on JavaFX, for example).
The best way would be to first discuss the details with us (project setup, where to host the code ...). In my opinion you should wait until the big refactorings are over. This means that summer 2015 might be a good time to go into the details of such an approach. I can only encourage you, but keep in mind that this is a lot of work.
PS: Your interest in the future of Scout makes me think that you might have worked with Scout in the past. We would love to hear more from you and who you are (check this story to understand why we are doing this).
|
|
| | |
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1645035 is a reply to message #1644554] |
Mon, 02 March 2015 04:49 |
| Eclipse User |
|
|
|
@Marco
Marco Dorfliger wrote on Mon, 02 March 2015 04:20 ... I also found the Swing deployment to be noticeably more responsive than RAP (mostly noticeable over slower connections)
This is exactly one of the focus points of the new HTML5 renderer. With the new renderer we are trying to keep as much state/processing in the browser (without breaking the Scout application model). This leads to immediate responses to user actions in many of the cases which makes the new web UI react to user input without first having to do a server round trip (over a possibly slow connection). Of course, this is not possible in cases where we need access to business rules etc. But with the new HTML5 UI we already see a much improved usability over the current web renderer.
Marco Dorfliger wrote on Mon, 02 March 2015 04:20 ... A web-only release would I suppose also mean no offline mode
As of now, we think that we will be able to wait to address the offline topic. This means that we do not yet like to specify if and in which release train we will add the offline feature. So far, we were considering a hybrid desktop approach for the new HTML5 UI that would include a local web server for the client application. With this approach we would then be able to re-create the offline setup you mentioned above. This setup would also allow for integrating client side services such as CTI, bar code scanners, etc.
As we are driven by the business of our customers, Scout's answer to offline and client side intergration might come in the next month or in two years only.
Marco Dorfliger wrote on Mon, 02 March 2015 04:20 ... and migration of existing desktop-based Scout projects to the 2016 release remains an open question
With the current RAP renderer, a migration of existing desktop applications to a web application is possible today. With this approach, it is straight forward to check for any features in your current application that might need to be adapted to a web based scenario.
For Scout applications that do need offline capability or other client side integration of devices/services the hybrid desktop approach mentioned above should allow for a good migration path.
For the case when the UI technology of your Scout application must remain on a desktop UI technology, the new HTML5 UI does not fit. This question seems to be simiar to the one posed by Kai Dohmann. Please see this message for our comments
Thanks for your valuable questions, Marco
|
|
| | | |
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696574 is a reply to message #1695684] |
Wed, 27 May 2015 06:35 |
| Eclipse User |
|
|
|
Since I already replaced the client of one of my scout applications with a HTML5/CSS3 client, I want to share some of my experiences:
First, I tried to use indeed RAP, but the unique feature of RAP (try to emulate SWT in a browser by creating HTML/CSS/JavaScript on the server and push it to the client) is its disadvantage at the same time.
For me, these were the main reasons against RAP:
- RAP's approach is more old-fashioned (coming from JSP/JSF) than modern (rest-based with html5 web app)
- adding new or special controls is awful comapared to "normal" web development.
- there are a lot of cool front-end tools you cannot use, for example a package manager like bower, build tools like grunt or simply frameworks like bootstrap, angularjs and so on.
- scale out is more complicated
My research and deliberations then took me to the following architecture. The server acts like a microservice. The server offers a REST interface that is able to handle JSON data. The client is based on AngularJS, Bootstrap and Bower/Grunt and communicates over HTTP requests using JSON and the REST interface. This allows me, for example:
- scale out by simply duplicating the server application
- use the same REST interface for other apps (e.g. native mobile)
- use all the cool already existing frontend themes, tools and all the UI/UX stuff (for example: toaster notifications, better form widgets like masked inputs or hierarchical multi-selects, animations...)
- use bootstrap to have a responsive layout. With a little more effort, the web app is directly suitable for smartphones and tablets. You can even wrap up this html5/javascript client into "native" mobile applications using cordova/phonegap!
- since the server runs jetty to serve the web-app, I am able to update the server including the web app files and therefore, I can also update all clients. (I had really problems to get synced updates for swt-clients and a scout server before...)
However, starting from scratch is no problem, since there are some cool frameworks like Dropwizard or Spring Boot and front-end generators like Yeoman (which offers different generators for different frameworks), but starting with an existing scout application is not very easy.
Another problem (which was already mentioned) are client side operations like printing or file system operations. For this, I use "node webkit" that wraps HTML5/JavaScript into a desktop-based webkit container. Since node-webkit allows to call node.js directly from the DOM, I am able to call native modules (e.g. the node file system module). Another advantage: the users have the feeling that they use a "normal" desktop application, instead of opening a browser...
Sooo, what I did so far:
I added a REST-API to the scout server using Jackson and Jersey. First, my idea was to simply annotate scout services to enable get/post/delete and so on. However, Jersey/Jackson had some problems during the (de)serialization of the FormData. So I decided to create a new REST-layer with dedicated resources and own DTOs. The resource classes build/wrap the DTOs and just calling the scout services. Since I already had a domain model before, this was not really complicated. But, integrating Jackson/Jersey/Jetty in my scout server and OSGi is not that easy (compared to spring/dropwizard with maven). For example, you have to manually start Jetty to be able to inject the resources.
I also refactored the server to be a rcp product, so that it is runnable standalone without tomcat (why putting a running jetty into a tomcat!?). So, my server is now a REST-based microservice.
Finally, I used AngularJS, Bootstrap and node-webkit to create a desktop-based web app against the REST-API.
Although there are some problems you did not expect from a java/swt-point of view (like multiple modals or stackable forms), there is nothing I am missing compared to SWT. Except of the tooling and form generators from scout 
|
|
|
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696612 is a reply to message #1696574] |
Wed, 27 May 2015 09:32 |
| Eclipse User |
|
|
|
Hi Dennis,
It seems to me that you have an interesting set-up. Thanks for sharing.
Dennis Geesen wrote on Wed, 27 May 2015 12:35Another problem (which was already mentioned) are client side operations like printing or file system operations. For this, I use "node webkit" that wraps HTML5/JavaScript into a desktop-based webkit container. Since node-webkit allows to call node.js directly from the DOM, I am able to call native modules (e.g. the node file system module). Another advantage: the users have the feeling that they use a "normal" desktop application, instead of opening a browser...
Have you evaluated Electron from the Atom project?
This project is often mentioned. It looks really similar to what you have with node webkit.
I wonder if something similar exists for the JVM? It would be nice to have something like that to be able to consume the JVM ecosystem from the browser. I am not familiar with the node.js ecosystem.
I have seen that JavaFX provides a web-view (also Webkit based I think), but I never experimented with it.
Dennis Geesen wrote on Wed, 27 May 2015 12:35I also refactored the server to be a rcp product, so that it is runnable standalone without tomcat (why putting a running jetty into a tomcat!?).
We are using the servlet brigde approach. It wraps an equinox runtime into the war (not the jetty runtime). I agree with you, the solution is not nice (and one motivation to go away from OSGi).
|
|
|
| Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696644 is a reply to message #1696612] |
Wed, 27 May 2015 11:37 |
| Eclipse User |
|
|
|
Jeremie Bresson wrote on Wed, 27 May 2015 15:32
Have you evaluated Electron from the Atom project?
This project is often mentioned. It looks really similar to what you have with node webkit.
Yes, I do and I also use it in another project. Although it is basically the same, I also think Electron has some more features. My simple problem was: I found it too late and I already started with node webkit
Jeremie Bresson wrote on Wed, 27 May 2015 15:32
I wonder if something similar exists for the JVM? It would be nice to have something like that to be able to consume the JVM ecosystem from the browser. I am not familiar with the node.js ecosystem.
I have seen that JavaFX provides a web-view (also Webkit based I think), but I never experimented with it.
Yes, I had exactly the same thoughts!!! Their main approach is to offer desktop-only applications using JavaScript only. Therefore I think it is a good approach.
Since I also not familiar with node.js, I seriously considered to implement such a "jvm-webkit" framework. Due to this, I also looked at JavaFX and its web-view and alternativesto get a simple construct.
My main conceptual problem is: How to invoke and map Java entities and functions from/to JavaScript without getting an ugly mix of Java and JavaScript. However, I started to look at exploiting the nashorn engine for that...
But at the moment I have no time for some experiments...
If there is a demand, maybe I will start the project 
|
|
| |
Goto Forum:
Current Time: Thu May 08 16:37:31 EDT 2025
Powered by FUDForum. Page generated in 0.11453 seconds |
Home
