This uses TeaVM to compile Java to JavaScript. Launches faster in browser than the desktop (once cached). Download is 1.2mb (compressed) - much smaller than desktop version. Runtime speed seems the same as desktop.
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
The technology has been around for over ten years - I believe Google Web Toolkit (GWT) was available in the mid 2000's, which also compiles Java source to Javascript.
The first statement is false. GWT defines it's own widgets, not AWT or Swing. The second statement is true - GWT is a transpiler. It would be very interesting if GWT could operate on bytecode but that's probably a very different project.
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.
I think the big win is that TeaVM has a lighter runtime and conditionally compiles only what is needed into the final JavaScript. There are tools that let Java do this now, but I think the standard runtime has more cross dependencies.
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.
I've done both CheerpJ and TeaVM. CheerpJ is awesome - it's a complete port of the JVM to JS and apps often work with no modification. However, the app + runtime is about 75mb (uncompressed) and can take minutes to load from a cold start.
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).
I use something called SnapKit (available on GitHub). It's like Swing and JavaFX had a baby, except that it has an abstraction layer that lets it compile to either JVM or JavaScript.
There are a few people working on similar projects, which I can use if absolutely needed (CheerpJ, JSweet). But you're right. It makes me sad that Oracle doesn't do something like this - ideally by bringing some of these people in.
This is an impressive feat of engineering. But unfortunately, the resulting UI is completely inaccessible to blind users with screen readers, and probably users with some other disabilities as well.
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.
Um, you can't make paintings accessible to blind people nor can you make downhill skiing accessible for four-limb paraplegigs.
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.
This is not art or sport, it is a technical demonstration of an interesting way to build web applications by compiling java to javascript. Calling out that this method has accessibility issues seems very on-point for a show hn post. The TeaVM people may not have thought of this, but should consider it as it will eventually become a barrier to adoption of their tech. For example, anyone who sells software to enterprise companies that has customer facing UIs (and potentially employee facing UIs) knows that the interfaces must meet certain web accessibility standards because the risk to the enterprise of facing ADA lawsuits is high.
Thanks for your comment! I had been wondering where this 'sudden' push toward web accessibility came from: good 'ol US litigiousness!
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)...
> I presume the web standards you mention are part of some US legislation, yes?
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).
A person with a disability shouldn't be denied any given job because an application is inaccessible even though the job function itself ought to be accessible (e.g., for a blind person, isn't inherently visual). It follows that every line of business application that can be accessible must be accessible. This is why I call this out whenever I learn about an inaccessible UI toolkit. I'm afraid that an inaccessible app will lead to someone being unable to get a job they want, or losing the one they have.
How can a blind person ever be a report designer? The nature of the task is inherently visual. No matter how much accessibility you add to PowerPoint a blind user isn't going to be able to chose the perfect font or position a chart in a meaningful way.
I don't have a problem with companies explicitly choosing not to make the apps accessible, unless I'm forced to use them, or they were accessible and it's hard to switch now. I have a problem with UI toolkit developers dismissing accessibility entirely and then companies using those "cool things" to build apps. If you build an inaccessible web app and you want to add a11y later on, you reasonably can. It might be hard, but it's usually doable. If you use a toolkit like this though, you're completely, hopelessly screwed. You can't do anything without rewriting half of the toolkit to support an alternative DOM representation, which will probably affect your performance. I've never seen that done. Either the companies just give up or moan about the shitload of money they've wasted and rebuild the app using normal web components, or build an alternative. Sometimes the law just forces them to, and the toolkit forces them not to. Imagine the sums of money you can waste on this.
PowerPoint is a pretty poor example. A blind person may not be able to build a PowerPoint template, but I think they should be able to build a PowerPoint presentation using a supplied template.
But this is replacing something with good a11y guidelines, with poorer support. That’s worth warning about, and nothing at all like trying to make downhill skiing for paraplegics.
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.
Working on an application now with deep a11y requirements. The main function of the application can't be done without sight (validating scanned documents). It's just a little frustrating.
I completely understand that... it's simply that some of the hard requirements only make sense for those without sight, but you cannot effectively use the app without at least some sight. (there's decent zoom and contrast support)
"can't" is a pretty strong term. Up until recently, people would have said that you can't make Olympic sprinting accessible to someone with no feet, but it turns out in fact you can, with sufficient application of technology.
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.
They didn't change the race though, they changed the person running it by giving them pseudo-feet. To continue your analogy, in order for a bling person to use this we just need to give them pseudo-eyes.
That's a worthwhile goal in itself, sure. But I think you're reading too much into what I said. I never claimed the two situations were identical or analogous, just that "can't" is something that needs to be periodically re-evaluated.
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.
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.
Nitpicking here, but many quadriplegics still have some use of their arms. Depending on the level of SCI and completeness they might not be able to use their pinkies or wrists but still use their arms for transfers or picking things up.
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.
Your not wrong factually but the beauty of web is the fact that it can work for a blind person on the other side of the world or a modern person right next to you.
The title of this submission is "Show HN: 300k lines of Java UI code running native in browser at desktop speed," not "Show HN: page layout and report designer." The criticism is that this particular method of making Java UI code run in the browser, which is being shown to HN because it's presumably interesting to other people with large amounts of Java code as part of different applications, is inaccessible - not that the page layout and report designer is inaccessible.
That's true if the application is entirely about visual layout, e.g. positioning and font sizes. But a blind user should still have an accessible way of controlling the content and structure of a report. And you might be surprised at how much information about layout and formatting is accessible in word processors.
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.
As a blind software developer, I'm kind of sad to see how much Matt is getting pissed on in this thread.
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.
Not to minimise accessibility concerns, but I think Matt's getting pissed on because rather than focus on the (impressive) achievement here he's diverted attention away from that and has (I think perhaps inadvertently) created a discussion that's beginning to resemble a social media pile-on. Accessibilty matters but this isn't an edifying spectacle and focussing on it in the way this discussion does is taking something away from what is otherwise quite a cool tech demo. I.e., it is raining on the parade.
And again I ask, when someone else produces some technically great achievement and people pile on about the design looking bad, why is that treated any differently? Why isn't that raining on the parade?
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. :)
"And again I ask, when someone else produces some technically great achievement and people pile on about the design looking bad, why is that treated any differently? Why isn't that raining on the parade?"
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.
Fair point. On one hand it makes me a little sad to see parades rained on. On the other, I assume folks want some degree of criticism if their ideas have some sort of flaw. On the gripping hand (such a useful metaphor, that) if we're going to tolerate some amount of politely-phrased negative feedback, then we probably shouldn't sweep some of it under the rug because it isn't the "acceptable" kind of feedback. Not that you are doing that, mind you. But it seems like some of that may have happened here.
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
This is not limited to HN. In any group setting, arguing against a thing is frequently counterproductive.
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 don't think it'd be salt in a wound--or at least I wouldn't see it as such. I do wish someone smarter than I am could come up with an accessibility backend to map GUIs to accessible HTML interfaces. So just as QT apps push accessibility objects to Linux/Windows-native accessibility APIs, something could push either ARIA-enhanced <div>s to the browser, or could just output fully-accessible HTML. So instead of QT rendering to a canvas, it could render to another target that just happens to be HTML elements. Substitute any other GUI toolkit with an accessible object representation for QT in my previous paragraph to get a sense for the scope of the problem.
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. :)
Thanks. I've sent some links and excerpts from the discussion (to Blind Dev Works).
(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.)
Sure, but in the context of building a visual layout tool, for someone to say that it shouldn't or doesn't need to be accessible to a blind person because OMG, visual! completely misses the point that it can be, and that other tools before it are. To say "I didn't have time to focus on accessibility because I was struggling with the challenges of making a Java codebase run under wasm" is one thing, and a thing I myself can relate to, having banged my head on wasm's challenges myself. To say "there's just no way to make a visual layout tool accessible to folks who can't see, so I'll just throw up my hands and give up" is another entirely. And I don't think that's what OP is doing, but I do think it's what some in this comment thread are advocating, and that's what bugs me.
Also, on a note directly applicable to this example, if you think hammers are unusable by folks without arms, might I suggest the documentary Right Footed? I can't say whether or not she uses a hammer without arms, but she flies a plane and drives with her feet, so I can't imagine her not using a hammer if she didn't want to.
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.
Making something accessible for a group of people is an opportunity cost at every step in the process. For some reason you've determined that "making the Java codebase run under wasm" is an acceptable diversion from making it accessible, but what makes other decisions less so? For example, I haven't bothered supporting IE for many years, regardless of the fact that there are potential users that will be unable to use services because of it. Same thing with internationalization, there's an opportunity cost that has to be made. That doesn't mean don't make the decision to expand support, I'm just saying that it IS a decision and it DOES have a cost.
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.
Can we just agree that Matt was pointing out a gap and leave it at that?
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. :)
I was worried that me bringing up other accessibility consideration might come off as making the case that a browser upgrade was an equivalent inconvenience as blindness, and that wasn't my point at all.
> or some reason you've determined that "making the Java codebase run under wasm" is an acceptable diversion from making it accessible,
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.
Thanks, a thousand times this. :) Even though this particular codebase doesn't bother me at all, my perception of the responses in this thread does bug me, and I appreciate that someone less emotionally attached than I am has both gotten it and taken the time to try explaining it.
That last paragraph wasn't entirely constructive. I'm sorry about that. I realize there are lots of existing applications that can't be rewritten to directly target the Web platform. But I still believe that new ones should.
Targeting the "web platform" does not by itself magically make an application accessible. It is vastly easier to make a native iOS or Android app accessible given the well defined rich widgets and the absence of 20 years of HTML and CSS evolution.
> I believe it's better to accept that the Web platform won
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".
> > I believe it's better to accept that the Web platform won
> 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.
You're right - it would require a bit of work, however, it wouldn't be that bad for a shared UI framework. I also think this kind of thing will be more common as WebAssembly allows other languages to move to the browser.
I have gone down this road before - but I think this is why many people saw Java as "Write Once, Debug Everywhere". It's just hard to write an abstraction that fronts for so much different native code on different platforms. Something is always going to break. Whereas if you run the same code everywhere, it might actually run everywhere.
So, I guess you have to either take on the extra work of debugging multiple UI implementations, or take on the extra work of making your own toolkit accessible. Personally, I would have chosen the former.
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 opens a whole other can of worms. Some blind people don't want a website or web application to be able to detect that they're running a screen reader, and by extension, that they're blind. [1] I'm not sure where I stand on that issue.
Media queries are instructions that the client can use, unlike other methods like user-agent there is no info being sent over to the site. Of course a malicious page could implement js code to try and understand what bersion of the page the client is actually rendering, but it would be quite easy for the client to circumvent that.
Google suggests that users can enable a "Java Access Bridge" (ships with JRE but disabled by default) that enables the Windows Accessibility API to work with Swing applications.
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.
You can't even type in Japanese. Typical cross-platform "well we got it to run everywhere!" solution.
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!
I'm not calling this out just to be critical. I call this out because I don't want people to be blocked from doing their jobs productively, or at all, due to an accessibility problem that could have been prevented.
This is not a software problem. Software doesn't need to absorb every requirement. You can prevent this problem in ways that don't involve pretending that somehow it's the responsibility of every software developer to use a11y in every product. So judging as if that's in scope is incorrect, is a wasteful use of judgement and, if people are convinced, a wasteful use of software resources.
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.
Still, by your logic, every app must be translated into every language. It's okay to exclude people, especially when you're small and don't have the resources to cater for the needs of every single person.
Apps should be translatable, even if they're not translated. If you're small, you're not obligated to translate an app to every possible language, but it is bad engineering to make your UI dependent on your primary language in a way which would make it hard to ever add support for a new one.
Not everything has to be accessible. 100% blindness isn't that common. And even if it was, there's nothing wrong with making apps for people with good vision.
A blind person can lose their job because an application that's required for the job is inaccessible, even though the job function ought to be perfectly accessible (i.e. isn't inherently visual). That happened to an acquaintance of mine. May it never happen again.
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.
I actually do think the second scenario is better. Some people will lack a convenience in the intervening three months (and remember that's a very optimistic case; it could be4 much longer). But at least a person with a disability won't lose their job because it now requires an app that they can't use.
Ok, now give your reply when the 'app' is critical to saving lives. Each hour it isn't available costs, let's say, 1 infant their life who could otherwise have been saved, per 1000 app users.
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.
> Some people will lack a convenience in the intervening three months
> 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.
I think the idea is: the new app is a convenience to a job that existed before the app. The company that uses it then decides to make it essential to that job.
So you think it's better for everyone to have less convenience so that it is literally impossible to discriminate, instead of just telling employers "don't discriminate"?
Maybe we should just go ahead and gouge everyone's eyes out to really level the playing field...
If you've taken calculus, you'll understand the idea of area under the curve- the number of people using your app will likely go up over time, and it takes time to accrue customers (the area under the curve of the rate of customers). One thing that you should think about is that it takes time for products to gain momentum, and as a product gains momentum, it generates revenue. As such, it might make sense to ship your code without much accessibility support and add it in the ensuing months. If you can be available to even 50% of potential customers three months before the first scenario, by only releasing for people using the OS you develop on, and then you go cross-platform in three, (making your population ~90%) and then add accessibility in the sixth month, it would still make sense from a business point of view to do so.
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.
I share your sentiments. Anybody building a tool that could conceivably be used for work purposes has a moral impetus to treat accessibility as a first-class citizen. The standards are there, the profit motive should be there and thus the resources should be there.
that's a non sequitur. a free tool doesn't have a profit motive and a company using the tool for profit doesn't attach a profit motive to the tool itself.
But they have an interest in their "free" tools being around the next day, don't they? Otherwise they have to either do it the "old way" or find a replacement, both of which cost time. At $100,000 a year per 40-hour-work-week developer, a team of 5 developers costs $240 an hour. That's a lot to lose because your tools disappeared. Analogous to physical work, consider what getting a new tool that's slightly different does to your muscle memory- there's an inherent value in having long-lasting tools, even if they're free.
Compile-to-JavaScript technologies have come a long way and seem well-suited to porting certain legacy applications to the web as proof-of-concept projects, but I think an API-first approach supporting a lightweight, HTML/JavaScript web framework would have required a justifiable, moderate additional effort, and would not only run faster, look and feel more contemporary, and be easier to maintain, test and deploy, but would put you in a better position to add new functionality going forward.
I would agree if the goal is just to build a web app, however, if you want to run natively on multiple platforms, Java still has its good points. If you really run a particular app on a daily basis, it can be nice to have an option for a dedicated desktop app.
We may see more of this with WASM. And JavaScript can get a little unwieldy beyond 100k lines of code.
It's those multi-client scenarios for which the API-first approach is a perfect fit, actually. Once the API is hammered out, it forms the common foundation for building gui's, cli's and even machine-to-machine interfaces. As a stepping stone, web applications can be deployed as hybrid mobile apps using something like Apache Cordova, even as fully native apps for Android and iOS are under development. Once you've implemented something like this, it's hard to go back to monolithic codebases. Caveat: this is predicated on having an API server and requiring an Internet connection. Writing a connectionless app this way would require some additional effort, though still quite do-able.
Everyone is using compile-to-JS technologies now, even JS programmers are doing it because they want to target legacy JS runtimes without new language features. And the minimization etc side benefits have becoim so relied on, that this toolchain is here to stay. It's a good thing because then a level playing field is enjoyed by a broad range of languages, like Elm, TypeScript and ClojureScript.
TeaVM also outputs WebAssembly, which can be faster than vanilla JS. I strongly disagree with you about that part. The HTML vs WebGL(/canvas) bit is more tricky. I do think there are valid uses of WebGL, but this project takes it too far. Their UI elements don't work great everywhere.
This reminded me of the talk "The Birth and Death of JavaScript" (2014) by Gary Bernhardt, where he goes into some of the more absurd possible implications of what happens when applications cross-compiled to JS approach or surpass traditional desktop performance: https://www.destroyallsoftware.com/talks/the-birth-and-death...
No, this is definitely not running at desktop speeds. I have a Ryzen 7 2700, and this thing lags often even with basic UI operations (clicking buttons and menus, dragging objects). Now imagine someone with a dual-core laptop CPU... this will be even worse. It certainly feels like this is a web app rather than a native one.
Now that hurts :-). Java has been pretty amazing for many years. Many Java desktop apps ran poorly because they were written poorly.
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.
This is my experience with java > 7. The JVM with default settings is pretty excellent these days (see JetBrains IDEs: they're MASSIVE but they run just as well as any other native desktop app.) The issue as far as i see it is that the "enterprise" way of thinking that has and still does dominate the majority of development that results in java code is so bad that it starts to seem like its the language/runtime.
I used to write apps with Swing nearly 20 years ago (before javax), and making even simple apps perform without tearing and atrocious performance was really, really hard.
Fortunately, CPUs have caught up with Java, eventually :)
I get desktop speed for Chrome, Safari, but FireFox does lag for me. The first run does load various UI files on demand, but once cached, most delays go away.
Yeah, what's up with that? I use Firefox a lot, and I've noticed it always has poor performance on heavy JS apps. The off time I need one of such apps is the only reason I keep Chrome installed on my system.
I've noticed that too. I think it might be that these days "idiomatic high-performance JS" might just be another way of saying "makes use of Chrome's quirks, strengths and optimizations". I imagine there's some things Firefox just can't do quite as fast as Chrome because of design decisions. The reverse probably also holds true, but that doesn't help as much if you aren't the market leader.
As a member of the Mozilla JS team, let me tell you that we're working on optimizing our engine for real-world usage all the time.
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.
This might be a lot to ask of a random internet comment, but is there anything common you tend to see in apps that make them look/feel overtuned to v8?
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.
I'd guess a lot of that sort of optimization happens at the framework/library level (React, Emscripten, etc) and less so in your typical application code.
I have never once "optimized solely for V8" (I honestly have no idea what runs better in Chrome vs. Firefox).
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.
Do you develop and test using Chrome, or Firefox, or both? If you aren't testing in Firefox beyond "it displays correctly" but you are using Chrome for your normal development, and testing, you are de-facto optimizing for Chrome, because you'll notice slowness in Chrome and work around if, but that same thing may have been fast in Firefox, but you never noticed. That's what being the market leading browser grants them.
I don't disagree at all, V8 was and still is revolutionary. However, the second order effect of V8 having captured such a large portion of the market is that developers will code/tweak/optimize until their app/library is suitably performant on V8 and then stop. No value judgement, it's totally rational but the effect is that now a lot of JS code has an implicit dependency on the quirks of V8 in order to be fast.
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.
As an enlightened individual as I'm sure you are, we strive to remove personal bias when possible. This includes measuring statistics. Which can take the form of synthetic benchmarks, but also real life tests, like page load times of notoriously bad news sites, or heavy cpu bound tasks like image resizing in the browser.
If you're not measuring it then it's pretty much subjective, no? You can't quantify what you don't measure.
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.
This is fantastic. I tried it out and works very well. I am self taught python and a bit of javascript to put front end to python servers. I have not really ventured outside that landscape as it has worked well for last 4 years or so for me so please excuse ignorance.
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?
Is there some public URL that would show that issue? I'm happy to take a look at what's going on with Firefox here, but could really use something to work with...
this makes me think of Qt in a web browser using WebAssembly [0]
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.
Again, slow is relative, and JS is slow relative to WASM. That should be obvious, but here's a source.[0] A demo working smoothly does not mean that a language is not slow compared to another. Besides this point, there are some very processing heavy tasks that we're throwing in browsers these days; this demo is not representative of everything we expect browsers to run. And if you read the other comments here, some people were having lag issues with the demo anyway.
No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM was not designed to run languages like Java, at least in version 1.0. Here are the reasons:
* 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:
Serious question, Are the days of native applications UI (be it Windows/Mac/Linux) are numbered? Does it make sense to develop a native application now days? (games and heavy CAD software aside)
Cross-platform UIs have been around for ages; QT goes back 30 years.
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.
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.
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 think there are a lot of other software categories to add to your parenthetical, but I think you're right that it'll be only those things that require a really rich interface (I'd add music production software, for example).
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.
This doesn't support native high DPI rendering. I think it's rendered at low DPI, and upscaled/blurry on my laptop. Other commenters have stated that it uses canvas.
This is pretty awesome. The UI load time and responsiveness are vert impressive. I hate web dev with a passion and I've been looking for something like this.
Hmm. I have 4-core i7-4770, but the UI on this thing lags a lot, all widgets generally feels sluggish. Such graphics operations don't require a lot of CPU, though, remember that we used to have 200 MHz Pentiums?
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?
I haven't done much testing on older systems. I'm looking forward to WASM, though. TeaVM has an option to compile there, but I haven't tried it. There's a bit of code that should benefit from WASM - and when threading is standard, that will be a big advance as well. Also WASM's ability to compile while downloading should be nice.
I suppose the plug-in/Applet approach is why it didn't fly - same reason Flash has gone away.
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.
No - this app uses a UI kit called SnapKit (available on GitHub). It's kind of a composite of Swing and JavaFX. Like those, it abstracts drawing and user input, so that on the JVM it uses Java2D/Swing and in the browser it uses DOM.
There's a product called CheerpJ that compiles Swing apps to the browser. I'm not sure when/if we'll see JavaFX.
Cool as a demo but not really something I recommend other than as a way of salvaging low value legacy java applications (of which there are a lot) where the UX is secondary to the ability to keep the application in a functioning state and where it is not feasible to build a replacement.
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.
>Cool as a demo but not really something I recommend other than as a way of salvaging low value legacy java applications (of which there are a lot) where the UX is secondary
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.
Absolutely. Doing "UI's" with the DOM (HTML / CSS / JS) was a big step backwards. We've spent two decades trying to graft an application platform onto a document delivery system.
Like you say, WASM should enable many more solutions to target the browser, breaking JavaScript's monopoly. There are still good desktop developer tools out there.
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.
is it possible to port other java project to web version?
at my work we are heavy users of jaspersoft Ireport. but anyone working with it can verify that working with ireport is quite a hell... - problems with different versions of java, different jars, problems running report on production etc....
So I got an idea of creating a web based ireport where everyone editing it would be working on the same version of software.
It's a bit of work for a typical Swing app using this technology (TeaVM) which has a small runtime. However, there is another Java-to-JS compiler called CheerpJ which handles many Swing apps without much work. The only downside is a larger runtime, so apps can take a bit to launch.
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 think this kind of thing will be much more common now that WebAssembly is allowing other languages to compile to the browser. The nice thing about Java, is that there is already support for a dozen platforms, with full native support. The browser is just natural - Oracle should have done this years ago (provide a standard solution to compile to JS and now WASM).
GWT has its strengths (it's been doing the equivalent of tree-shaking and dead code elimination since 2006).
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.
In my day to day there's about 30 seconds for a cold compile (which is rare, only when I clear byte caches) and maybe 5 seconds usually, less if I've just changed one line or something small like that.
That said we're not using GWT for CSS, so that reduces iteration time where it's most noticable.
With TeaVM, I can do all my iterative development on the JVM (instant compile time). Compiling to the browser is usually just a one time thing for deployment. Although, TeaVM also have a "dev-server" mode that does iterative compiles, which is apparently much faster for iterative development.
This is really a Java desktop app compiled to the browser. Oracle/Sun probably made a mistake by not thinking of the browser as just another target platform (in full-screen mode). The separate Applet concept probably added an unnecessary layer of complication.
Yeah, I hear you. Replacing 10s of thousands of JS lines with 100s of thousands of Java lines doesn’t feel like progress. Most Java (only) programmers look at JS as an “inferior, weird” language, but it’s actually much more powerful and concise if you dig into it.
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.
http://teavm.org