A UI library which doesn't present a visual example of its capabilities on its landing page is missing the point. The underlying technology stack is secondary.
This project sounds like it is just code. There isn’t any UI components or themes or anything. It’s just a library for writing web components but with Go instead of Javascript:
Does "modern" here mean that it supports all the expected ARIA accessibility standards, or are they talking about a shiny developer experience and fancy APIs whilst ignoring usability completely?
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.
Why is this always the first comment on any new UI library that's in a beta level release? I get it, there are blind users, but they're honestly less than 0.1% of the population.
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?
> A good UI library should definitely be accessible once it's in a mature release
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.
>How about some actually constructive criticism on the structure of how this library actually works?
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.
It's undeniably true that accessibility is a basic necessity rather than a feature. But is it fair to expect accessible features on an experimental technology?
Exactly. Accessibility is a huge investment of time and adds a lot of technical debt if done incorrectly, really doesn't make sense until the entire library is somewhat mature and starts being ised in production at large enterprises. Can't believe OP is complaining about screen readers in a beta release.
IMO, it's just a formulaic, virtuous sort of comment. An easy bikeshedding criticism. That's why we always see it on everything.
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.
I'd say it's too late then. You have to make at least some assumption beforehand, otherwise you'll have to rewrite huge portions of your lib. Sorry, I kindly disagree.
It's like adding unit tests AFTER you've written everything. Just don't do it.
>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....
Yeah, I know - that's how it's mostly done. I guess a Mish-Mash might make some sense? Because, often, I see people in my team creating "ConsoleApplication1"-kind of projects, so that they can build their components and already test them. That's when I mostly say "write a Unit test instead."
According to a 2011 study by Google, there are on average more people with just low vision/blindness online than there are Canadians online, and visual impairment is just one kind of disability.
It looks like it's very similar to Vue, except that instead of <script type="application/javascript"> it's <script type="application/x-go"> and the special HTML attributes are prefixed with "vg-" instead of "v-".
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.
There is nothing in the Vugu project which will prevent proper accessibility standards from being used (as others here have mentioned it will output whatever you ask it to). It's a valid point that examples should include such features where relevant.
Considering it outputs what you tell it to output, you can add aria-* all you like. This doesn't have a corresponding UI component library, it's a lower-level library for creating components.
Wails (https://wails.app/) has similar goals, but has traditional Javascript on the browser side. It's not clear to me how Vugu accesses resources from the backend. Wails has an explicit event mechanism.
I can't comment on Wails but Vugu is for building front-end code that runs in-browser, written in Go and running via WebAssembly. You can make calls to the backend however you like, it doesn't impose much at all in this regard except as it relates to updating the UI/DOM.
concurrency yes, parallelism no(t yet). each wasm module is single threaded, but you can create multiple modules in separate threads that communicate with each other via shared memory and atomic ops, but of course you have to figure out how to correctly emit modules that take advantage of this. So far emscripten's pthread is the only thing I'm aware of that properly does this.
The website manages to consistently crash my browser (Brave), my Android launcher, and who knows what else - my device no longer responds to gesture navigaion. Quite impressive.
This is cool, but in all honesty, golang isn't the best language for UI. It's just not expressive enough. Golang sacrifices expressiveness for readability (and readability is an opinionated concept) for a domain where I think expressiveness is more important.
That being said. I would love to see something like this done in Swift!
We are approaching the glorious day when we'll be able to write web frontends for web-based apps in real programming languages. Not there yet though.
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.
It's the web. It runs HTML, CSS and JS. Wanting to code your web app in anything else is... I don't know... petulant? And wanting to lose HTML but keep CSS seems a little perverse ;)
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!
> actually did a better job of providing "just works" write once, run everywhere.
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
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.
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?
petulant (and I'm still not sure that's the right word for it) because instead of learning the technology that everyone else (i.e. the standards bodies that decide these things) decides is what we're doing now, you gotta do something different. Not better, but different.
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.
petulant (and I'm still not sure that's the right word for it) because instead of learning the technology that everyone else (i.e. the standards bodies that decide these things) decides is what we're doing now, you gotta do something different. Not better, but different.
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.
Meh. Wanting to replace javascript for frontend webdev is no different than wanting to run javascript on the server. It's not perverse or petulant. Everyone has opinions...
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.
I'm actually with you on C. C has the excuse of being portable assembly and from the dawn of time. Javascript is just the result of shoehorning something into the browser quickly.
Of course it is. So is JavaScript. I've done stuff in C, C++, Haskell, python and am now writing primarily in js. Nothing weird there. I fight more with libraries than with the language.
The bit I fight with the most is how to package it all up for distribution. I'm not a frontend dev, and I vaguely understand that the answer is "webpack" but it's not clear to me what the happy path is for configuring this for distribution. It's also not clear to me whether these $LANG->WASM toolkits will solve this problem or whether they'll also need something like webpack.
I’m a somewhat (?) unusual situation where we are a Java shop in which I persuaded the group a few years ago to move to an SPA on top of web services (REST, JSON) architecture...
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.
I switched from Webpack to Parcel (https://parceljs.org/), it requires far less configuration (only command line parameters for me) and runs faster. It's "batteries included", and I find it's enough for most of my applications.
Why? Webpack has gotten significantly easier to get up and running with since Webpack 4 (iirc).
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.
It's taken me 8 days to answer, because I've rewritten this a few times. I may write this up as a blog post.
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.
And finally... It's a solution to a problem that only exists because of the dependency culture in the JS community. Because each dependency contains a lot more code than is needed to solve the one problem it was imported to solve, web apps tend to bloat. So we need to break them into modules and only import the modules we need. So we need a tool to do that and package the modules up. So we get Webpack. Instead, why don't we just import less code in the first place? We really (and I mean really) don't need 500Kb of javascript to create a basic web app. If we could cut that down to 100Kb then we could just minimise it and we wouldn't need webpack at all (maybe Gulp to run Babel for those oh-so-necessary new cool JS features).
TypeScript is already similar to WebIDL, what we are missing is having it as part of the browser engines, with more optimizations based on type information, instead of being yet another language with a JavaScript backend.
Is this right? (Disclaimer: I'm about halfway through the Rust book, so I'm just a bit above useless when it comes to Rust) but my understanding was that since WASM can't do DOM manipulation, you still need JS and something like Emscripten to call WASM code.
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.
While this is technically true, we have libraries (js-sys and web-sys) as well as tools (wasm-pack and wasm-bindgen) that handle creating that JS for you; you don't have to write any of it yourself. Additionally, they're implemented as polyfills for the eventual way to do this kind of thing without the JS, so once that lands in wasm proper, your code won't need to change, and things will just get faster.
On current WebAssembly version you still need to expose canvas or WebGL entry points to Rust code.
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.
Qt has an experimental WebAssembly backend, already discussed at least twice on Qt's developer blog.
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.
Do any of those generate web apps that are accessible and browser-friendly? I am quite aware of the fact that you can run desktop apps in a web window. Will have to investigate Blazer and Qt.
Could you elaborate on what you mean by "browser-friendly"?
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.
Actually what many are unaware of is that for a couple of years Adobe still had Flash for mobile devices via an AOT compiler to native code, as means to address iOS as target.
Why is modern JS (TS especially) not a "real programming language". I have never once been bitten by == vs === or the crazy automatic type conversions people use to demonstrate that JS is not a "real" programming language.
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.
