I think "desktop" in this case just means "not optimized for mobile". It's a [[desktop] [[UI toolkit] for Web]], not a [[[desktop UI] toolkit] for Web].

I guess "A UI Toolkit for Desktop Web" (as opposed to "Mobile Web") would be clearer but sound more awkward.

As a foreigner I have always struggled with association order in English (which undoubtedly happens in other languages, but not quite like this in my native Spanish). I liked your use of brackets here and, if you or others here don't mind let me present a question I've had for the longest time. Does CGI, as in "common gateway interface", parse as "[common gateway] interface" or "common [gateway interface]"? Thanks, and apologies for the digression!

Skimming Wikipedia and RFC 3875, it seems like there was never a notion of a “common gateway” that needed an interface. The name suggests to me that there were many ways forms of “gateway interfaces” between web servers and executables, and the standard was to pick a common one.

In general, it seems English doesn’t try to make a distinction. Is a small, red bird a small bird that’s red or a red bird that’s small? Same difference, and in fact the standard ordering of adjectives (1) would preclude such a distinction from being possible.

(1) https://en.m.wikipedia.org/wiki/Adjective#order

It would parse as [common gateway interface], i.e. it is a singular thing, not really at all grammatically similar to the aforementioned "Desktop UI" issue.

This is a Vue-based component library, designed for webapps in desktop-size rather than mobile-sized browsers. It's still only JS/CSS view components, nothing to do with actual desktop apps.

There are dozens of libraries like this, especially many that follow the Ant Design guidelines created by the major Chinese company Ant Financial for their own apps. Vue has a large Chinese community and is more often used in projects there, which also means the documentation might be a little wonky when translated to English.

Some other design systems and component frameworks, with varying support for mobile and corporate backing:

https://ant.design/

https://quasar-framework.org/

https://at-ui.github.io/at-ui/

https://developer.microsoft.com/en-us/fabric

https://vmware.github.io/clarity/

http://appnexus.github.io/lucid/

https://ng-lightning.github.io/ng-lightning/

https://blueprintjs.com/

http://www.jetbrains.org/ring-ui/

https://www.lightningdesignsystem.com/

https://elastic.github.io/eui/

https://atlaskit.atlassian.com/

You forgot Bootstrap-Vue, Bootstrap without JQuery.

A Nuxt core member is a core contributor to the project.

https://bootstrap-vue.js.org/

I can't speak as a user of said framework, but as a developer learning Vue I like it!

I like it because it's not over-engineered with like 10 classes to do a simple dialog. You can go to any .vue file and look how they do it. It's not very difficult to copy some bits of the code and css, to do your own components. They use a bit of mixins and whatnot but for the most part you can reuse some of that code without having to bother with the node packages and whatnot. Plus they have a bunch of useful little bits of js in there for dom manipulation etc.

I also learned how to manually instantiate components and passing props to them, from this codebase. It wasn't made obvious in the Vue docs.. and it's actually SUPER useful when refactoring old codebases (like YUI2).. where I do'nt have the luxury of wrapping everything in a view, I can make a Vue dialog, or a Vue bar chart.. and "mount" it to the page. Then I can use the webpack build, single file components & all the good stuff from a modern Vue build in a legacy web app.

Vue+Vuex feels like a built-in browser API - completely unopionated. This made it perfect for a problem I was facing. Angular and React+Redux want things done in a certain way, which is a problem if you are not on a greenfields codebase.

That is how I'm using Vue as well, new parts of the system are done Vue SFC style but old legacy parts are refactored to in page components mounted against the dom, eventually the amount of legacy jquery soup will approach a point where I can just transfer those components over a full 'Vue' style approach.

VueJS makes that all very clean and simple compared to everything else I looked at which wants you do to do it "our way or the highway".

Exactly, it's awesome because if you eventually refactor the container page or section to a Vue comp, you can include the other child components straight without any further work. They already work as full blown components.

Plus:

- since we're mounting components and using SFC, we can use the "runtime only" build (though I keep the full one when I want to make something quick, because the savings in the minified Vye library were very small)

- it can be a small performance improvement in cases where we want to mount something in response to user input, whereas the template in the html page will be compiled on page load (afaik).

I know it says “Desktop” but it seems pointless to me to design something with web technology that doesn’t work on mobile.

I suppose if they’re committed to being desktop only they could at least remove the meta zoom tag so I could see a scaled down version on my phone and zoom and pan around, ala the original safari mobile experience.

That depends on your requirements and constraints.

"Designed with web technology" doesn't necessarily mean "designed for the public web".

In many enterprise settings desktop-only is perfectly fine because applications developed for these environments often won't ever be accessed from a mobile device anyway. Even if they are it's usually only a small part of the application that needs to be available for mobile devices.

In these cases, devoting an inordinate amount of time to making all of your design work flawlessly on mobile devices can mean a huge waste of resources.

By the way, from a cursory check - while not particularly mobile-friendly - this UI toolkit is responsive (probably also because that makes perfect sense on the desktop as well) and seems to work alright on mobile devices, too.

The web is a deployment technology as much as it is a display technology. Even when you design something that's only supposed to be displayed on desktop screens, it may still make sense to use web technologies if it makes your deployment easier (e.g. because the target environment is heterogenous, with lots of different OSes).

There are lots of enterprise and other complex webapps that will never be used on a mobile browser, or have accompanying mobile apps for that scenario.

There's no need to be good at something that doesn't apply to your situation, especially considering how much more work mobile UI takes.

E.g. we have an in-house web based ERP/CRM. Nobody is allowed to use phones at work and no one works from home. Supporting mobile is useless for our project.

I used this recently for a serious project recently, currently deployed in production, and it was delightful. One of the best designed software UI libraries (API and UI) I've had the chance to use.

It integrated perfectly with Vue.js.

We plan to use it throughout the rest of our application as we replace Rails views/jQuery with Vue.js components.

We tried using this for one of the client facing application(not an internal tool) and found it bloated and had to make lot of customization to fulfill our needs so we wrote a custom framework which is more than 10x smaller. Not that we didn't import all the components but just the components we needed but still felt it was bloated.

This feels like reinventing the wheel. There are a bunch of really great "desktop" web frameworks out there, e.g. https://ant.design - which is great.

Apparently the Select component doesn't support any keyboard commands - something quite many users do use on a regular basis. So apparently it's a downgrade over the default browser behaviour.

> There are a bunch of really great "desktop" web frameworks out there

I don't think that ever makes sense when it comes to design. No one ever says there are so many shirts out there let's not design another one...

> No one ever says there are so many shirts out there let's not design another one...

Perhaps not, but many should.

Do you mean this? Focusing, and selecting seems to work well on the keyboard. https://element.eleme.io/#/en-US/component/select

I notice you can't type "O" and have it select the option starting with "O"

Ah, good point.

Element is based on Ant-Design, but created in Vue.

So we've come full circle now yeah? Rebuilding desktop component sets in the web, to port our web apps to the desktop...

Wait for wasm-compiled desktop apps in web.

It looks very similar to Ant, which is a battle-tested enterprise-class UI kit – https://ant.design/

I'm curious why these libraries aren't embracing web components more. Requiring Vue 2.0 drastically fragments the potential audience.

Who remembers Cappuccino and Objective-J?

I'm sad it didn't get much traction. At the time, it seemed Apple was trying similar things with SproutCore

http://www.cappuccino-project.org

http://www.cappuccino-project.org/learn/objective-j.html

https://en.wikipedia.org/wiki/SproutCore

I memba'

You mean AT-UI*: https://at-ui.github.io/at-ui/#/en

It looks VERY similar

Interesting... Does the AT UI have an actual repo? I couldn't find one like Element has: https://github.com/ElemeFE/element

Makes me wonder who ripped off^h^h^h forked whom.

edit: found https://github.com/AT-UI/at-ui

Element repo history starts in September-ish 2016, AT-UI in Apr 2017. The content is very close, but I'd guess Element is the original. Not sure.

I like at-ui than most of the vue frameworks including elements because most of them are bloated.

I wonder how it compares with Ext JS, a semi-forgotten framework which was, among other aspects, very desktop-centric (in a very powerful way IMO)..

What is advantage over Bootstrap, other than working cleanly with Vue?

What do they mean by "desktop ui toolkit for the web"?

I thought it was an alternative to QT, GTK, Cocoa, Electron, etc, but no…

It's just another CSS framework ala Twitter Bootstrap, very misleading.

Yeah the whole landing page is focused on "this is why our product is the best" but I still don't get what their product is. Probably just means that I'm not the target, but still...

I'll also chime in. I started using this about a month ago and it's been rock solid and really easy to work with. Especially with Vue CLI 3.

Really like the clean interface. Ended up using this instead of Vuetify. Vuetify is really well put together and maintained, I just found that I really dislike Material design.

I like Vuetify because it has a very active Discord community and it's pretty easy to get help. The lead developer himself responds to questions fairly regularly, and comments on feature requests too.

Does Element have something similar?

There's a gitter channel for Element. But the community is not as good as Vuetify. If you are ok with the Material design look, Vuetify is far superior in terms of # of components, community participation, and developer feedback.

Can't even see the inputs... https://element.eleme.io/#/en-US/component/form

As much of a fan I am for Vue, I never liked this library due to its lack of mobile friendliness. Sure, it says it's for Desktop, but the only use I can think of for eschewing mobile styles is Electron apps.

> span > number of column the grid spans > number > — > 24

It's not 2010 - we have grid for grids. Unless someone is paying you vast quantities of money for IE support why use something else?