3 ms·

>unless you're a java shop hell bent on NOT learning modern frontend development. Sorry, but that statement is dripping with irony. Irrespective of whether GWT

>unless you're a java shop hell bent on NOT learning modern frontend development. Sorry, but that statement is dripping with irony. Irrespective of whether GWT was the right implementation, the Swing model is far superior to any of the piles of tangled JS/HTML/Made-Up-Things that comprise "modern frontend" frameworks. I know that's not a popular statement, as everyone seems to have their favorite framework, and I'm referencing all of them. So, we took a step back and had a bit of a mess with frontend development on the Web, then "solved" some of the problems with new frameworks. They're still miles behind a true event-driven, component-based UI model. We solved this problem long ago with Swing and other native window-based UI frameworks, and none of the current frontend Web frameworks is even close. Don't know if the subject of this post is the answer, but I do know that one day we'll look back and laugh at the time we thought, say, JSX was a good idea.

le-mark 9y ago
The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different.
- unclebucknasty 9y ago
  >The address bar and back button change everything. >the web is different It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general. The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use. So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.

le-mark 9y ago

The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different.

unclebucknasty 9y ago
>The address bar and back button change everything. >the web is different It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general. The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use. So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.