The problem with browser UIs is not their performance (although that's not great either). The problem is development productivity is utter crap.

The obvious problem is the lack of consistency between browsers, OSs, and even versions thereof. The less obvious problem is the constant churn: features that used to work no longer do, the constant need to "upgrade" your framework, the total inability to produce non-trivial visual layouts, etc.

Any idiot can make a form user interface. HTML/CSS/JS is great for this but it is literally the easiest thing a UI framework can provide. People are happy with these frameworks because the bar has been set so low. A few years ago we were blown away by people doing drag-n-drop on the web.

Come on people. It's 1990 all over again.

So again... the amazing thing about web technologies is not web technologies. It's the low learning curve. It's the fact that millions of people can now write shit code (whereas before they couldn't code at all).

If you could provide this same experience with Java, or any other technology, then people would flock to it the same way that they flock to web development today.

Ironically, the main thing keeping first-time developers away from Java is Sun and Oracle's inability to internalize the User Experience. If they invested more in client-side development they would inevitably have to care more about the user experience of coding. Had they done this they could have displaced Javascript as the de-facto web programming language.

Gili

On 2018-03-14 6:57 PM, [email protected] wrote:
Hi Christian,

You're experiencing something all the Java devs had to go through 10 years ago, 
when everyone still told us Java/Swing is so slow, and will never be able to 
keep up with real programming languages/native UIs, while we were coding really 
huge and fast Applications with it.

It takes some time until these prejudices wear off. Don't worry, it will slowly 
get better in 10 years or so 😉.

Cheers

Toni




-----Ursprüngliche Nachricht-----
Von: Christian Lenz <[email protected]>
Gesendet: Mittwoch, 14. März 2018 19:48
An: [email protected]
Betreff: AW: AW: AW: Apache HTML/Java UI instead of ... Oracle will 
removeJavaFXfromOracle JDK

So the example from Github, with Atom and the example of Microsoft with VS Code 
or Slack with the Desktop app, is not valuable enough for you? VS Code is such 
a fast DIE/Editor. And valuable against sublime for sure. It is very stable, is 
the most contributed Project on github etc. So I think yes there are such apps 
out there who are willing to try electron. And you can take a look here to see 
a lot of apps where built with electron: 
https://github.com/sindresorhus/awesome-electron. It is not because it is hip 
but it is an ecosystem for frontend developers who wants to create good looking 
Desktop apps with our Technology which is JS, HTML, and CSS. The same for GWT 
or Vaadin for Backend devs, who wants work in the frontend. I don’t say you 
have to and I don’t say it is the wholy grail, but it is a good alternative and 
not that bad.


Cheers

Chris

Von: cowwoc
Gesendet: Mittwoch, 14. März 2018 18:35
An: [email protected]
Betreff: Re: AW: AW: Apache HTML/Java UI instead of ... Oracle will 
removeJavaFXfromOracle JDK

I agree. If the web was such a great platform for desktop apps, you would have 
seen many other projects/companies porting complex desktop applications to it. 
They are not.

Web technologies are great for basic interfaces. They are utter garbage for 
Filty Rich Clients.

Don't repeat the mistake of ORMs: jumping on a technology because it looks great from 
far, only to discover that it doesn't do what you want when you're "95% done".

Gili

On 2018-03-14 6:58 AM, Peter Steele wrote:
One of the biggest limitations is the fact everything is single threaded.
This isn't related to vaadin and gwt.

I have used vaadin and like it alot, and to build certain types of
applications it is a great candidate if you are used to java. I have
also used GWT alot and have extended it for areas which it doesn't cover.
(Vaadin uses GWT too)

Another js pet hate for me is the fact it is not OO based, people have
tried to put wrappers around us but they inevitably have issues
because they are wrappers.

Chrome has a good debugger but compared to debugging support from
desktop languages it is inferior

The language is too visual basic like for my taste, it's nice and easy
to use but if you want to do anything complicated you are in trouble.
Thumbs up for closure support, thumbs down for the complete over use of 
closures.

Btw these are only my opinions, you may disagree with everything i say
and that is ok. I am in the camp of "i will never use a web based ide"
but i have no issues building apps that are designed for the web and
work well on the web (like for thin clients). Forcing everything in to
the browser is not they way forward.


On 14 Mar 2018 10:26, "Christian Lenz" <[email protected]> wrote:

Peter,

can you tell me which limitations you mean? As I wrote in an other
thread, the limitations came from GWT. The Problem is that a Java
developer doesn’t want to write HTML, CSS and JS so they are looking
for an alternative. GWT or Vaadin or kotlin to js, I can’t understand
that, but ok. So please don’t compare GWT or Vaadin with native JS.


Cheers

Chris

Von: Peter Steele
Gesendet: Montag, 12. März 2018 17:50
An: [email protected]
Betreff: Re: AW: Apache HTML/Java UI instead of ... Oracle will remove
JavaFXfromOracle JDK

Christian

I am sure electron is good, but my personal preference is to not use a
web ide. Javascript as a language has a lot of limitations. I have
written gwt code to export java to html and you are limited a lot in
how you design your apps.

On 12 Mar 2018 16:40, "Christian Lenz" <[email protected]> wrote:

Have a look into electron apps. A lot of apps are written with this
Framework like VS Code and I think this is a big Player and you can
see, that it performs very well and it is performant as hell. Only to
say one
of
those apps.


Cheers

Chris
Von: Peter Steele
Gesendet: Montag, 12. März 2018 17:37
An: [email protected]
Betreff: Re: Apache HTML/Java UI instead of ... Oracle will remove
JavaFX fromOracle JDK

What about the eclipse RCP framework which uses swt? This would seem
to be a much better solution than having a html front end.

On 12 Mar 2018 16:25, "Neil C Smith" <[email protected]> wrote:

On Mon, 12 Mar 2018 at 15:59 Jaroslav Tulach
<[email protected]>
wrote:

Forget about AWT, Swing and JavaFX - the future is HTML. In case
you
still
care about Java, then your future should be Apache HTML/Java API!

Generally inclined to agree with you - definitely on forgetting
JavaFX,
and
probably on forgetting AWT/Swing (intrigued to see what actually
happens there).  I don't think HTML is the only game in town, but
for a lot of things it's probably the right way forward.

But, if we start turning to Apache HTML/Java way, what does it run in?

Out of interest, I was looking at an example project using Vaadin
running
inside Electron recently.  Have you tried this approach with HTML/Java?

Best wishes,

Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding -
www.praxislive.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists






---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



Reply via email to