Show HN: 300k lines of Java UI code running native in browser at desktop speed
reportmill.com
reportmill.com
If we would travel back in time to the nineties and tell them we have technology that compiles Java to JavaScript they would put us straight to a psychiatric hospital :D
Do you have any insight or ideas on where the performance increases and size decreases are coming from?
Also, did you have to work a lot to get it working in TeaVM? The last I looked at it (which was admittedly over a year ago), it still required some non-trivial changes for the Java app I was working with at the time.
My app cross compiles to JVM and browser easily now, but I did a lot of work on the SnapKit UI framework, which is like Swing but abstracts out graphics and user input. My app used to be all Swing - that would be almost impossible with TeaVM. There is product called CheerpJ which does Swing with almost no modification, but it has a larger runtime.
This post links to the TeaVM version. TeaVM is also awesome - but it has a reduced runtime, conditional compilation and better built-in DOM support. The whole app + runtime is 1.2mb (compressed) and loads in seconds (instantly once cached).
This will not be easy to fix. AFAIK, if you're using Canvas or WebGL, the only way to make the application accessible is to construct a parallel accessible HTML tree that's completely covered by the canvas via CSS. Note: Don't use "display: none" to hide the accessible HTML tree, because then screen readers will ignore it.
I'm reluctant to rain on your parade, because as I said, this is an impressive piece of engineering. But for the best accessibility and performance, I believe it's better to accept that the Web platform won, and target it directly with a UI that's native to that platform.
There is a public domain within which most disabilities should be catered for but you can't expect that every non-private thing is made public so it's usable by all.
Just because something is 'in the web' doesn't mean it's a public service, access to which is a basic right.
It's good to be reminded to take into account disabilities, of course, since those are not obvious to people who do not have disabled people nearby.
Of course it's a good thing to be mindful of from a humanist perspective, but if fear of lawsuit is driving the change, it's not a very "love thy neighbour" kind of thing, but more of a fascist dictation, no? Especially if you are not in the US.
I'll be doubling down on my efforts to ensure better compliance nevertheless.
I presume the web standards you mention are part of some US legislation, yes? :S The web is becoming a crazy place, it seems that every country is writing laws that affects the whole web... and we as developers are assumed to know them all, from UI requirements (US) to security implications (Australia), to privacy concerns (GRPR)...
> The WCAG 1.0 was published and became a W3C recommendation on 5 May 1999. They have since been superseded by WCAG 2.0.
That said, the current is 2.1:
> WCAG 2.1 became a W3C Recommendation on 5 June 2018
[0] https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guid...
3 November 2008, though it had been available long before in as draft going back to 25 January 2001.
Lots of European companies have similar requirements if they want to sell to the public sector (which is probably even bigger as a market over here, I would expect).
Imagine using this for a new B2B app and then losing sales because prospective customers have ADA requirements or blind employees who use other web apps just fine. It’s extra engineering work sure, but it’s hardly a crazy ask, and it’s the right thing to do for large to medium size companies who can afford it IMO.
Implementing good a11y apis allows the variety of vendors to make assistive technology that can navigate your page for all sorts of user categories.
So the real question is always whether the technology to make something accessible exists and whether it can be deployed reasonably in the particular instance involved.
But if you do want to press on with sprinting events, note that they have been using start signals with both an audible and a visible component for a while, to accommodate people who may not be able to perceive one or the other. Back until we had electronically-triggered lights, you "couldn't" have a deaf competitor compete, modulo smoke from the starting gun. Now you can.
Plus years of stupendously painful physical therapy and Herculean will.
BS, we can and already have. here's a paraplegic person dropping in on one of the steepest in-bounds runs in the US.
quit being so dismissive.
I was not implying people with disabilities should stop doing things, rather, that it shouldn't stop a non-disabled person to do a thing just because a disabled person can't do the same thing.
There are actually accomplished quadriplegic pool players. They use a bridge and learn a grip that works. Disabled people are extremely adaptable out of necessity.
This is not correct and may result in very costly class action lawsuits.
Furthermore, now that this toolkit is available, companies will use it for applications that are required for job functions that ought to be perfectly accessible to blind people. An inaccessible application can lead to a blind person losing their job.
Also, I mentioned other disabilities. A person that can see but has a severe mobility impairment should still be able to use this app.
That's almost exactly what this tool is for.
I'm not being dismissive I'm just wondering how far your beliefs go.
It really didn't seem like he was all that inflamatory, either. He just pointed out the accessibility challenges that I myself face every single day because, what, blindness isn't all that common? Great, so either kill me off[1] or give me enough UBI to not need a job, because there's really no other path for me and my uncommon condition other than, it seems, to constantly assert my existence. Should we make hammers accessible to the disarmed? Ugh, should I have to waste any more of my time because someone on the internet put up yet another straw man for me to knock down?
Look, I'd get it if his initial message was like mine, and I fully expect and don't care that I'll get downvoted for this. And to be clear, this comment is more about the intolerance and dismissiveness I've seen in the replies of what appeared to be a fairly constructive piece of criticism of someone who does accessibility work professionally and gave out free advice. Hell, how often does a Show HN get pissed on because the design looks outdated, and that's just taken as par for the course? People criticized the Thoughter design a few days ago (I don't recall how it was spelled and don't want to look it up) and no one said "Damn, the guy made a product and all you can do is complain about how it looks?" Yet someone voices accessibility concerns and look what happens. I myself have held off on posting some Show HNs because I can't make a website look good. But someone makes a constructive comment about a thing not being accessible along with tips on what might fix it and it's like "OMG get teh blinds outa here!" And now we know why I don't even seek out tech work anymore. Queue up the "maybe you'd have better luck if you behaved better" comments. :)
And to be more constructive, I am a bit worried about the "render everything to a canvas and call it progress" trends I've seen with Web Assembly lately. It isn't just this, but the projects to compile QT and other native GUIs to wasm. Do that and you lose access to the native OS accessibility layers these tools use. I've wondered if there might be a way to create parallel HTML versions of these same widgets so your GTK button might compile to a <button/> with GTK-like styling. But I don't know anyone working in that direction, and I'm not smart enough to pull it off myself. I'm just worried that one day we'll have a pile of thin clients all running in their own canvases. My girlfriend's law firm uses timekeeping software written in the 90s with a web interface. I imagine it's a GUI app running on some basement server with a VNC client in front of it. That's an outlyer, but wasm makes it likely that it won't be, and Matt's concerns as an accessibility professional are completely on-point.
1. To be clear, not a cry for help or anything, but it sort of blows my mind that on one hand people dismiss disabilities because they're not that common. On the other, a large subset of society expects us to try harder to compensate for that apathy. So you either do, and become exceptional, or you just give up to some degree or other and accept that you'll likely never have the nice salary and such. On the gripping hand, most of you are likely to have one of these "uncommon" disabilities when you age. Hope you enjoy whatever you do while you can do it. It's going to be fun learning how to keep coding in your 70s when half the tools you took for granted aren't accessible to the screen reader you use because your glasses no longer cut it. :) I don't expect folks to bow and scrape when a thing isn't accessible, but to shit on someone for politely pointing that out is quite an unfortunate reaction.
In a parallel universe, someone might have said "You're right, it isn't accessible. That wasn't my goal, and if this ever does take off then I might have to investigate other options."
But that isn't what happened, it's a bit of a double standard, and that double standard has real consequences for some of us. The bulk of the pile-on doesn't seem to be coming from my friend, but rather from a bunch of folks criticizing him for daring to politely suggest that there's another perspective worth considering.
If your response is "because more people care about the visual design of a technically sound concept than whether it is accessible because looks matter," then I'd agree with that, and we can just leave it there without casually dismissing an entire group of real people who matter. But again, that isn't what happened here.
I wish I could post web apps I've made here without contending with the half dozen "your design sucks" comments I'd likely get. But if I got them then I'd expect them, and that frustrates me to no end.
FWIW, I'm not actually all that upset. I'm kind of used to this, actually. And I know you're just trying to explain why things are what they are, which is exactly what I'm doing. :)
It is. HN rains on a lot of parades. It's a bit notorious for it. There are people who have posted that they have things they want to Show HN but don't particularly want... well, exactly this.
Full disclosure: I know Matt and think he's a good guy, and he reached out to me wondering if he'd done something wrong. And I can actually kind of see both sides of this situation. But unlike him, I know I'm kind of a hard-ass about access issues not because I want to be, but because today's cool idea might be tomorrow's "no job for you, Nolan," and not because anyone wants that, but well, what do you tell someone who wants to work for a company but can't because most of the tools they use aren't accessible, so you literally can't do the job they need? And yes, this has happened to me before. And we can sit around and talk about privilege or who is at fault all day, which may certainly be a worthwhile discussion to have, but at the end of the day, the discussion I most want to have is "are you going to change your company's workflow to account for the fact that I'm qualified to do this job but can't as things stand?" and the answer is usually "nah, easier to find someone else, sorry."
So that's where Matt and I are coming from, and I wish folks hadn't piled onto him for trying to express that. And while I'd like to be nice and polite about that, well, what do I get when I am? A cookie? I'll try to pay the rent and do fun stuff with that cookie, thanks. :P
Enough novels from me. Got stuff to do. :)
Social settings are "attention economies." Piling on to the argument adds attention to the thing you nominally want less of, yet are fueling. I generally try to not add to such situations.
I used to say "Fighting against the fighting is still fighting." If I am going to wade in, ideally, I should do so without being combative about it.
I have been debating whether or not to send the comment about how this is not accessible for the blind to a group I co-own called Blind Dev Works. Not sure if it is relevant to the interests of others there. I'm visually impaired and generally interested in accessibility, but I'm not blind, nor really a developer (though I actually want to learn to code and I'm trying to do something about that).
I don't know if it would just be seen as salt in an open wound or an interesting discussion.
I've just never dived into how those particular APIs work mainly because, well, there are so many problems needing solutions, and I happen to be focusing on others. Surely I'm not the only one to have thought of this, though, and on the off-chance that I am, the best thing I can do is keep mentioning it until someone else decides it's worth trying. :)
(Anyone on HN interested in joining Blind Dev Works is welcome to shoot me an email. I"m happy to send an invitation. It's a small, low traffic group.)
It feels a bit inspiration-porny at times, and my girlfriend and I both cringed quite a bit while watching it, but I think it makes the point I'm trying to much better than I am. Please don't dismiss a challenge out of hand because you can't imagine in 15 seconds of thought how it might be overcome.
"you" being a generic term applicable to anyone reading this, BTW.
-_-
If you don't perceive it that way, you have to accept that there is a near infinite number of accessibility measures to contend with. Maybe I add support for red green color blindness, and then discover there are other types. The package bundle is too large for users in countries with poor internet access, so you need to have a fallback that removes features, and dedicate some resources to minimizing the initial load time. Oh, the input configuration doesn't make sense for users who are unable to use keyboard and mouse, but use an alternative input mechanism, you have to change it to support that. Oh no, adding support to assist those users has made able users switch to the assisted input configuration, and given them a competitive advantage in your game.
Every company cannot service every need. Those that service a need open potential to acquire the market. That may or may not be worth it or possible at any given point, and that's okay.
I know more than most people that there is a cost to making things accessible. Do you not think that I get the dumbed-down, PR/support-filtered version of that response every single time I reach out to a company and tell them that a thing my company is using is unusable by me? :)
But I think we, by which I mean everyone in this thread, can acknowledge that without implying that our needs aren't worth considering because there aren't many of us, or that they aren't worth considering because no one immediately knows how. If that isn't what folks have done here then I'll own my misunderstanding, but folks could have just acknowledged the comment rather than criticizing him for having the audacity to suggest that I too might want to appreciate the technical achievement for myself..
And FWIW, I kind of resent having my disability, which no amount of learning or software upgrades will fix, lumped into the same category of English proficiency or IE 6. That does feel a bit condescending. Saying "well, some people can't upgrade their browsers" is in an entirely different league than a visual disability that no amount of upgrades or night classes can fix. I'm not saying that switching browsers or learning a new language are possible for everyone, but short of gene editing, there is no way for me to eliminate my blindness. I'm not upset about the examples you chose, but would like to politely suggest that you reframe how you think about these issues. :) Thanks, and not in a snarky way. :)
They didn't say that. They said "I didn't have time to focus on accessibility because I was struggling with the challenges of [...]" You're focusing on the [...] which could be anything, it doesn't matter. The point is they're acknowledging it's a legitimate issue that they just didn't have the time or ability to fix. As opposed to saying it's a non-issue or something they refuse to fix.
For example, "My personal website isn't accessible because I wrote the code from scratch to learn myself and it's not perfect" is fine. "My personal website isn't accessible because I don't have any blind friends so it doesn't need to be" is less so.
This is why we have accessibility standards and guidelines that are not an infinite number of pages long.
The "Web platform" is not a single thing. It is a bunch of things that are constantly evolving, that are also implemented differently by different browser vendors that have their own issues.
Just because the web purports to have a (sometimes) working UI that is accessible to some percentage of users on some percentage of devices doesn't mean that we should stop there and not experiment anymore in other directions (even if those new directions could, initially, not support all a11y functionality that 'the Web' already provides, for screen readers or what else have you).
There is no "the Web won, accept it"- many things are terribly broken, before even taking a11y into account. Just note how many dysfunctional UI paradigms exist that don't support what we call 'responsive web design', often from the biggest companies in the world!
A11y isn't anywhere close to a solved problem on the Web any more than responsive layout is -> it should not be the target specification to work towards just because.
As a final thought experiment: what if we are going about a11y all wrong? What if screen readers and tree hierarchies of components aren't the right way to approach building these things and instead the better solution is to completely do away with that approach and instead make new screen "readers" that use AI to better visually determine elements on screens after the fact. AI is definitely at a point where it can classify buttons from text and images, as well as read out text in several kinds of fonts. If this becomes the future, it'll render all of our current web 'standards' to look like an unnecessary hassle of working with the more disingenuous and restricted (in the sense of, you can only use such and such component in such and such way) methods of today.
What I'm saying is, encourage people to experiment with new UIs that don't yet conform to standards. By all means, mention that you wonder about a11y and ask what the plan might be going forward. But don't dismiss these experiments too early cause they're not built in the "right way".
> The "Web platform" is not a single thing. It is a bunch of things that are constantly evolving, that are also implemented differently by different browser vendors that have their own issues.
Maybe The Web, as a platform won?
EDIT: Formatting
doesn't work that well because the event model between web and desktop is radically different. if you don't have complex interactions or expectation about your widgets it kinda works.
That sounds like a use case for @media queries
A11Y is not the bottom line to judge everything by. That dilutes it's importance as a niche. Judging by a11y is a power that should be used responsibly, not as a last resort to just find something critical to say.
It's inaccessible to non English speakers and that's not a problem because it just doesn't matter enough. Same thing with disability. There's just not enough disabled people to justify critiquing everything that's not usable with screen readers.
The world is not accessible to every group within it, and that's okay, that doesn't mean everything that isn't able to be used by some group is somehow bad or deficient. To discriminate against apps that don't have certain abilities is just the same bias as discriminating against people with different abilities. Be more tolerant of apps that are serving their special niches and nothing more.
So now we have a framework running on a VM running on a VM running inside a sandbox running in microcode (did I miss a level?). Can't wait for the next abstraction!
Doing that is just harming a11y efforts, by insisting software must be the fix, when there are plenty of other solutions that don't involve rewriting / redesigning a piece of software, likely to deliver solutions faster or better than changes to software.
At this point, I really don't know why you keep advocating this path as your goal can be achieved through other means. Get off the idea that a11y critiques are the ultimate trump card. They are not.
And money.
https://www.mayo.edu/research/departments-divisions/departme...
That's a problem with the employer, not the application. Applications do not need to cater to every edge case of humanity.
Accessibility is not something that exists until a developer nerfs it. Accessibility takes time and effort to implement.
Take two examples:
* I release an app without much accessibility support on April 5th. Immediately, 90-95% of my prospective customer base can use the app. 5-10% cannot. Over the next few months, I improve my app's accessibility and release the new version on July 5th. Now, 99% of potential customers can use it. In the interim period of three whole months though, the vast majority of potentials were able to use my product.
* I think an app is not worth releasing until it has comprehensive accessibility support. It takes me a couple extra months than it would've without it, but eventually I release my product on July 5th. Yay. 99% of my potential customers can use it at the time of first release.
You really think the second example is better?
The point of the exercise being that you seem to be dismissing the fact that there are actual bad consequences to the 'must be 100% accessible upon first release' principle, simply because a person for whom accommodation is required now has a job.
What I don't see in your argument is some sort of equitable discussion of who bears what costs, and how that equity is fairly determined.
> lose their job because it now requires an app that they can't use.
So is it a convenience or essential for the job? If it is a convenience, then it isn't essential. If it is essential, you're denying it to the larger group in the interim.
Maybe we should just go ahead and gouge everyone's eyes out to really level the playing field...
Keep in mind that things take time to develop a userbase, and that large companies really like things to have an established userbase and support before they get on board. For instance, one of the major reasons that the Raspberry Pi Foundation has seen so much success, even though they aren't the fastest or the cheapest, is because they have a large community support network and support their stuff well.
As such, as long as I (and / or management) are committed to implementing solely-accessibility related features in the near future, I would take the first option, and release as soon as I could.
The only reason not to is greed.
> The only reason not to is greed.
This seems contradictory? If there's a profit to be had, then greed would demand that it be taken.
while accessibility is important this extremisation is a little rich under a post of a literally free tool.
We may see more of this with WASM. And JavaScript can get a little unwieldy beyond 100k lines of code.
[ Found the issue. https://github.com/electron/electron/issues/673 ]
I used to give demos of the Swing version of this app 15 years ago, and people would try to convince me that my app was written in C, because a Java app can't run that fast. Those were weird conversations. I'm not even that clever - I just try to write simple code.
Not for me. They're starting up long, UI is laggy. In comprasion to native IDE like Qt Creator they're really slow.
Fortunately, CPUs have caught up with Java, eventually :)
"Well, it's written in Java, so desktop app probably lags as much. So title does not lie (2001)"
FF's is not.
Some optimizations are better in SpiderMonkey than in v8, some are worse. Unfortunately, whenever a web developer optimizes solely for v8/Chrome, this hurts Firefox.
I'll freely admit that i'm guilty of the "develop for chrome, test in firefox" kind of workflow, and I really want to improve on that. I feel like I have built up a kind of "intuition" about what works well and what doesn't over the years in chrome, and i'd like to start building that up for other browsers.
All I know is that I build an app as I think makes sense logically, and 100% of the time it runs faster / less hot in Chrome.
JS-heavy apps burn thru CPU cycles far more on FF than in Chrome.
I want to use FF as my daily driver, I really do. But it's real-world performance just doesn't cut it for me, and I don't think you can blame that on people "solely optimizing for Chrome", as V8 was a better engine at the moment of release, when nobody had had a chance to optimize for it.
Real-world JS was already in production when V8 was released, and it had orders of magnitude better performance at the time.
There's really no good solution to this because the kind of performance tuning we're talking about explicitly pierces veil the VM is supposed to provide. You're pretty much always going to target the internals of one particular engine. So what this means is that anyone working on a competing engine not only has to provide the same behavior but also the same performance profile because it's something that JS devs expect to be there now.
I don't know how you use Firefox and Chrome (I use both in work) but they behave pretty much identically as far as I can tell, once ads and other crap have been blocked.
The only difference is Chrome is snappier on Google sites and seems to use double the memory to open the same tabs.
My understanding is in this high performance CPU landscape Java apps should work well on all popular desktop platforms and to have it compiling to a web UI like this makes it even more powerful.
How does including existing Java libraries like GeoTools http://docs.geotools.org/. What are good resources to read to understand the limitations of TeaVM?
That's why I still haven't made the switch despite all the claims of "it's just as fast as Chrome in benchmarks!"
Installed an "app shortcut" with Chromium and couldn't be happier.
I find it really impressive that desktop applications can now run quite smoothly in a web browser. In like 15 years we've made it from phpbb forums through 56k modem, to this.
Congratulations
[0] http://example.qt.io/qt-webassembly/widgets/richtext/textedi...
[0]: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
* To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines).
* To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance.
* In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM.
* In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again.
So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons).
And yes, the lack of access to stack even affects C code. For example:
int i = 23; foo(&i);
Similar effort in Clojure or ClojureScript - https://github.com/oakes/play-cljc
It's more intended towards Game development though.
The pattern that Electron and such are continuing is that they do a base set of things well, but then integrating with OS services is non-existent, even though for any given OS it's relatively trivial.
Don't be too impressed that it can run anywhere at acceptable speeds; Java solved that 20 years ago.
Rather, it's more fundamental: as you add in all the functionality provided by various OS's you have to model all that functionality and it has to be comprehensible to your users and maintainable by you.
Some of that functionality is flatly contradictory and much of it is peculiar to a small audience. You can theoretically engineer around it, but in practice, you won't be able to maintain it and no one will want to use it. That's an intractable problem.
That's why I think cross-platform framework authors have consistently been leaving various bits of functionality out for decades. They'd rather deliver "second class" applications than nothing at all, and that's a smart trade-off.
But that does leave a lot of space for native apps.
When you think about it, iOS and Android apps are desktop apps (in full screen mode), not browser apps. And they may be more popular than web apps, for now (though I hate the toll imposed on them).
Maybe someday soon, you'll be able to click on a web app and turn it into a desktop app, with better native platform integration. That might be a reason to stop desktop development.
I know for myself (15-ish year Java dev), even if software I'm writing will only ever be used on my local laptop, if I need UI I'm likely to do a Spring Boot app with a web frontend and Bootstrap.
Anyway for me it looks good and very fast!
That said, it's better than a lot of legacy apps that either don't upscale (and are too small), or half-upscale and end up unusable.
On Firefox it's even worse, looks like it was rendered by 4 MHz Apple II. :|
But if it allows easy porting of a Java app to a browser, then this is still great stuff. Not the most responsive UI, but in case of emergency, why not?
Maybe we can get Spring Boot running in TeaVM instead of Docker. ;)
It's unfortunate Oracle hasn't adopted the approach of treating the browser as a target platform. TeaVM and CheerpJ have just a couple engineers working on this and they've done great things. A fully supported effort could really make this take off.
There's a product called CheerpJ that compiles Swing apps to the browser. I'm not sure when/if we'll see JavaFX.
I also could not use any keyboard shortcuts, and the edit menu options did nothing at all.
Despite that, it really exceeded my expectations.
OpenJdk in wasm might become a thing actually. The download size is not going to be very nice of course but might be acceptable for an intranet type thing that people want to keep alive for whatever reason.
Wasm might soon enable a lot of things that are currently hard and make them both feasible and common again. Flash, silverlight, and shockwave could be kind of nice back in the day and it used to do a lot of things (some of which hopelessly misguided) that are still quite hard to pull off with modern web applications. Most games have better looking and more responsive UIs than many websites. Stuttering laggy divs with broken animations, hover effects, etc. are not a substitute.
I recently got involved in some front end work as I inherited some of that when one of our people left. I must say I find this stuff super tedious to deal with and disappointingly primitive after basically not having done any serious UI work for most of this millennium (usually stick to backend). I suck at this obviously but it seems things could be improved in many ways by rethinking a few things.
IMHO, some native UI kits adapted to WASM combined with modern yet powerful languages like Kotlin, Swift, C#, or Rust should be running circles around most frontend teams in terms of performance, productivity, and quality once this stuff matures a bit.
Scriptable DOM trees as a side effect of browsers exposing their internals to a hacked together bit of scripting language seems to have snowballed into this everything is a document but not really paradigm where you have this unholy mess of nodes and events tied together by a language that is continuously patched up to make this less painful but hopelessly stuck in its own history.
Apologies for the Friday afternoon rant but I've been staring at some example of modern web development the whole day and have a stiff neck from shaking my head in disgust.
Are we talking about the same app?
The UI here is better than most web SPAs (and where it's not, it's not because of the libraries used), and indicative how more uniform, streamlined, and familiar web apps could be if we had gone with a rich widget set and layout engine (like Java has and this uses) from the get go.
And I agree: if your app only needs to run in the browser - use browser tools. But if you really use an app all day long, you're going to want a dedicated desktop version. The browser app-in-an-app model is convenient for casual use, but not optimal for long stretches and doesn't integrate as well with the desktop for real workflow.
Also, if your app exceeds 100k lines of code, there are some languages that might be better than JavaScript.
I'd love to hear more about your idea for web based ireport. Send me a note at jeff at reportmill if you want to chat (or call the main line).
I use it daily at work. It's an impressive feat of engineering with a lackluster ecosystem and inconsistent documentation. Although it's not dead yet (at least technically) as it still has (slow) active development happening.
That said we're not using GWT for CSS, so that reduces iteration time where it's most noticable.
However, there are other, better (than vanilla Java) languages that generate class files for the JVM which this tool can apparently convert to WASM. Might have some redeeming features. Clojure to WASM maybe???
It’s not like CSS is all that fun — this approach gets rid of DOM manipulation for use-cases where a more pure graphical layout is appropriate.
In no way is that true.
E.g. - https://ramdajs.com/docs/#partial
Of course, I’m assuming that the JS programmer is exploiting FP and dynamic types, and not just transliterating Java style static OOP code.