Vugu – Modern UI Library for Go and WebAssembly
vugu.org
vugu.org
A wider breadth of examples, with links to the demos or even hosting one on the homepage should definitely be considered.
I checked some examples in the playground and they seemed to be devoid of any kind of accessibility tags, and the generated HTML sources didn't look super friendly to screen readers.
A good UI library should definitely be accessible once it's in a mature release, but that's a fair bit of extra work to do up front when things are likely still in a state of flux; and since there's no guarantee there's even sufficient interest in Yet Another UI Library to get an upswing in usage, it's very possible no blind user will ever be exposed to a site powered by this in production at all, ever.
I'm not trying to say we should ignore blind people overall, but this comment is always in the top spot on every single new UI library and it's rather tiresome. How about some actually constructive criticism on the structure of how this library actually works?
Again, me and you and everyone else definitely want production apps to be accessible! And yeah, it might rule out the selection of an immature library like this one for a larger scale project that has more concerns about missing out on the potential user base that have accessibility concerns. Fair enough.
It's like adding unit tests AFTER you've written everything. Just don't do it.
Funny you say this, because that's exactly what I do :)
I don't start unit tests on a new project/library until I flesh out most of the major components as I'm sure I'd be rewriting things multiple times as I'm iterating in the beginning. My guess is this method isn't uncommon....
Well, accessibility is deeply about how it works, not so much something that can be tacked on afterwards.
Plus I think this is something constructive to consider.
"More than 3.4 million (3%) Americans aged 40 years and older are either legally blind (having visual acuity [VA] of 20/200 or worse or a visual field of less than 20 degrees) or are visually impaired (having VA of 20/40 or less) (Eye Diseases Prevalence Research Group, 2004)."
The percentage goes up sharply with age.
My daughter is a power user with a retinal disease. Being constantly marginalized as an unimportant case kinda sucks.
I doubt that you can add a good accessibility layer after everything else is done and the absence of a plan is telling. Which is fine, if the author doesn't know or doesn't care, it's ok, it's his time and his project after all. But if you plan to build something with it you should question yourself: "is it accessible?".
In my opinion the parent question was perhaps a bit harsh but legit.
That is: It's lower-level than something you would ask to support ARIA standards. It will support them if the markup you write for your Vugu components supports them. Vugu doesn't ship any built-in components or anything.
All your CPU are belong to us
Looks like they have rather diverse goals, except that both use go lang.
Very different goals, even if they're both essentially "glue Go stuff to web stuff"
Using latest Chromium on Kubuntu.
This is clearly Experimental / Alpha and missing some basics, such as:
On Chrome: Click "get started" Click the back button in the browser URL changes, but you stay on the "Getting started" page
Sorry if this is a dumb question but I'm pretty new to wasm.
That being said. I would love to see something like this done in Swift!
What I really want is something like an "old school" UI library and the ability to style it via well-documented straightforward CSS. For web apps I don't necessarily want to code my UI in HTML. I want to develop an app in a more Qt-like way but with a more modern API.
The older versions of GWT actually kind of did this but it's Java and newer versions have decided to try to cater to people who want to do web sites rather than business apps with it.
I just wait for someone bored enough to bring Flash back.
Microsoft is busy pushing Blazor for .NET, and Unity is working on a 2D WebAssembly game engine already demoed multiple conferences.
C and C++ can make use of Emscripten and even use SDL, POSIX subset and OpenGL mapped into browser APIs.
D's LLVM based compiler, ldc, can target WebAssembly. Thus you can also write the logic in D, and do some mapping into browser APIs like canvas and WebGL.
Unreal can also target WebAssembly.
There is TeaVM for Java.
Go compiler supports cross compiling for WebAssembly now.
So plenty of information around.
I would assume you actually meant "accessible and mobile-friendly", in which case the answer to that is generally "nothing does that". You need frameworks or libraries (not languages or compilers) if you want something that just does it for you.
The data and business logic of your code can be written in a WASM-targeting language, but I don't think you could make a React/Vue/Angular-esque UI library (or even a jQuery clone) purely in Rust.
However WebAssembly is not stuck in MVP v1.0, there is ongoing work to expose more of the underlying features to WebAssembly, like the DOM references proposal.
I personally am very happy with the progress that has been made over the past 10 years with JS and associated technologies.
Still excited about WebAssembly et al., but not nearly as excited as I would've been 10 years ago.
Last time I looked, there were minimisation plugins for Gulp/Grunt, etc that would package JS up.
Sure, it starts getting complicated if you want to add language features that haven't made it into browsers yet (i.e. Babel) or use something that transpiles to JavaScript (e.g. TypeScript), but the really popular ones have plenty of good documentation on how to set them up and what each piece is doing.
I've only had to set up Webpack a couple times and I've already internalized most of the important stuff.
Source Maps are still black magic to me though...
OK, so...
1. It doesn't do one job and do it well. It tries to do it all.
2. It has magic. Why does this setting do this? Don't know, just do it.
3. It's vastly overcomplicated (related to 1, and produces 2)
4. It's a black box. It's not at all transparent about how it does what it does, and the output it produces seems to be arbitrary. I mean, you could probably work back from the minimised mess that you get to relate it to the source, probably. But it's not at all clear why tweaking this declaration makes that function move to that module.
5. It's not instrumented, or predictable. Changing a declaration can make it double its processing time, and there's no way of knowing which of the 5 changes you just made caused that.
That said, I’m using the Maven plugin which runs the Google Closure compiler to bundle my js files (and strip white space, but not name-mangling). Seems to get the job done.
Note: most of the files are just a few large “IIFE”s to be concatenated together, rather than “modules” or such, as we had a requirement to support IE11, and were initially sticking with ES5 style.
Every language has flaws (yes, even LISP). Every language has a different purpose. Javascript has done an amazing job so far, and there are millions of people writing some great things in it. Yes, there are also millions of people writing some terrible things in it, but that's on the people not the language.
I think having a way of running Go as my front end is going to be great, and I look forward to testing it out. I will heave a huge sigh of relief if I can just code in one language for the whole stack.
But that does come with complications. There are currently exactly zero Front End Developers who write usable web front ends in Go. Given the complexity of writing web front ends (and that's not going to be any easier in compiled Go or Rust than it is in interpreted JS), and the paucity of experience in writing them, I'm not sure moving to a Go front end is wise for another few years. Even then, I'd be surprised if Go won that particular competition, and I wouldn't be surprised to find that we have to run Python in Web Assembly because that's what all the Front End devs use. I like Python, don't get me wrong, but I don't see Python in WA as a huge step up from native JS...
Why? Is there some first-principles thing here? What if Flash was open sourced, massively cleaned up, changed to be search friendly, and ended up with well curated app marketplaces and code signing? The language Flash used had a shared heritage with JS, and actually did a better job of providing "just works" write once, run everywhere.
Many Smalltalk variants had a practically bulletproof write once, run everywhere record of performance. What if properly code signed and sandboxed Smalltalk plugins had won? That could well have resulted in a more open web than what we ended up with.
Wanting to code your web app in anything else is... I don't know... petulant?
Why?
There are currently exactly zero Front End Developers who write usable web front ends in Go.
If the developer experience becomes a lot more like developing against a desktop UI framework, there are a ton of experienced older developers who could quickly jump in. It's not rocket science. Actually, in many ways, desktop development is easier than the web front end.
For that matter, why not build something which is 1-to-1 isomorphic with React? (EDIT: I see now, that's already sort of the direction they're going for!)
I'm not sure moving to a Go front end is wise for another few years.
Which I would interpret as a sign that it's the right time to jump in to be a pioneer!
It did, for its time. But there's a tremendous amount of work done in scaling UIs between mobile and desktop viewports on the web that Flash could never easily achieve, and most native frameworks are still struggling with today.
> If the developer experience becomes a lot more like developing against a desktop UI framework
... then the mobile experience is crap, yeah.
Keep in mind that Flash was effectively abandoned/deprecated. Again, there's nothing first principles here. The greater effectiveness of MacOS in dealing with scaling UIs is a demonstration of this.
> If the developer experience becomes a lot more like developing against a desktop UI framework
... then the mobile experience is crap, yeah.
Credit where credit is due. Look at what Apple has achieved in terms of this. In a way, the argument tactic is straw-manning here. Instead of picking a few glaring errors from past frameworks, shouldn't we be looking at the best of what existing frameworks can do, and try to build that?
Flash was proprietary tech. Eventually Adobe would have worked this out and owned the internet. You can't have proprietary tech underpinning everything. The story of video codecs bears this out.
I developed a ton of desktop UI in Visual Basic. It was easy. But I didn't have to allow for random screen sizes, random browsers, random OS's, random accessibility problems, rarely had to allow for random languages (and that was difficult), and I had a synchronous back end that I could wait for between clicks. Sorry, but the difference between desktop and web UI is huge, and underestimating that gap is a major cause of bad web UI.
The desktop world has long moved from fixed layouts from VB 6 and lower.
Since 2001 actually, given that even Forms has a layout manager.
You don't get better, if you don't try different. In terms of clarity and expressive power, I would say that Smalltalk is a step above Javascript.
I've written a lot of python, javascript, C and go in my career, and my opinion is that javascript has done a barely adequate job despite being the only game in town.
Thank god for the petulant, else we would still be foraging for berries.
Every language has a different purpose.
What is the purpose of C#1, when one could use C#3.5?
I especially don't understand why people would want to write a front-end in Go. React already provides a great front-end experience. If you're doing something that requires high-performance, then use c++ compiled to wasm or something similar. But why Go? It's not as performant as C++ and I don't think it provides a UI development experience as good as React.