Swing was at least meant to do UI. Web stack is not; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile).

Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.

> Swing was at least meant to do UI. Web stack is not;

The ancient history of the web, clearly, is different, but the modern web stack, both in terms of specs (WHATWG HTML/W3C HTML5 and related standards) and modern browsers are very much engineered for applications, not just classic documents, as a primary use case.

When you find yourself having to reimplement a blinking cursor, that's when you know you are working on a shitty tech stack.

In the minds of people who've spent long time on traditional client-server tier architectures view Javascript as a toy and view all the Javascript frameworks as "over engineering".

Yet, what they fail to realize is they are comparing a webpage to an application. An application contains information about the state it's in. Handling the application state has always remained complex and it has been two way coupling to the presentation layer making life more difficult.

The latter is why Javascript is perceived to be "over engineered" by people viewing it nothing short of "fairy dust on ugly document pages" which is absolutely incorrect way of viewing application development.

I used to be the biggest Javascript skeptic but once I realized the intent behind React/Redux/Vue.js, it changed my perspective and have started treating it with more weight and respect.

Once that paradigm shift happened in my perception, I found it a lot easier to navigate and endure the fragmented tooling and endless variations of npm modules.

Because I realized that it's going to get better eventually and it's here to stay. Young people aren't learning Java & using Maven on Eclipse or Netbeans anymore. They are on Atom or Visual Code, writing Javascript.

Why was this downvoted? I expect a rebuttal instead just silent downvotes. This just solidifies my opinion, there are lot of dinosaurs on HN and they are going to find themselves unemployable without Javascript in the future.

Javascript is essential knowledge, along with AWS. Software engineering has changed in the past 20 years like it or not.

And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits.

I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

> I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

Like Qt did with QML? http://doc.qt.io/qt-5/qml-tutorial1.html

Yeah, but Qt has licensing costs for commercial use...

Qt is LGPL, so unless you need to link to it statically or make proprietary modifications to Qt itself, you don't need to pay licensing costs.

Ah right, I wasn't aware of that.

Qt is (largely; a couple of optional components are GPL) LGPLv3, so can be used commercially without getting the commercial license.

Oh, lets be professionals and not pay for our tools like everyone else does, who needs money anyway!

Less painful according to who? From reading this thread it appears that most devs claiming it's incredibly easy have never actually worked with other UI toolkits at all, so their experience is largely worthless.

I've done web UI dev. I've also written code using GTK, Qt, Windows, Swing and JavaFX. A good modern UI toolkit like JavaFX or Qt blows the web stack out of the water on almost every metric. Developer productivity, correctness, speed ... you name it.

Intention is in the hands of the builder not in it's inherent design.

> webapps are essentially a pile of ugly hacks on top of a document rendering engine

That's your own opinion. You claimed Java Swing & FX was the correct way and that thin clients like Electron is wrong. I disagree.

If Swing was meant to do UI then it's probably the most awful and inefficient way to do it.

If Web was not meant to do UI but it's the fastest and more efficient to work with than Java.

It's a matter of opinion but with starkly different development experiences. Sure, you can build using Java Swing/FX but you are going to get a completely different demographic and developer culture...one that is still ingrained in the era it was released.

Why?

With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.

Why use JavaFX when you can change the CSS in a web app which is indistinguishable?

Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.

I was extremely skeptical of using Swing for a really large hospital application. But after working in it for quite some time, I have to say that with the right approach it is quite manageable. There is plenty of power in there and a lot of good things can be done.

(I do prefer the webstack over Swing)

> Even the end result UI design look & feel is butt ugly.

Only when developed by those devs that never bothered to read books like "Filthy Rich Clients".

Is the IntelliJ UI "butt ugly"? No, but you'll probably say it is as to not contradict yourself. Blame the craftsmen not the tool.

>Even the end result UI design look & feel is butt ugly

You know what else is butt ugly? Programmer art and UI.