Element – A Vue 2.0-based component library for developers, designers and PMs | Hacker News Reader

Element – A Vue 2.0-based component library for developers, designers and PMs

element.eleme.io

337 pointsDowwie140 comments

I have actually tried to use this to build an enterprise application. Here is what we found.

* Most of the components they provide are very basic and does not actually require them to provide it. Couple of lines of wrapper on any CSS framework like bootstrap can make half of those components.

* Most of the advanced components like DataGrid, DropDown Menus, etc are aither not available or buggy. You will get better support from thirdparty Vue components.

* There are lot of silly components like footer and header etc. There is no need for defining them except to show that it is complete UI framework. Trying to be 'Complete UI Framework' is bad choice for any UI on Web. HTML is too flexible and requirements are too diverse that no one UI library can provide everything.

We finally replaced all Element Components with standard bootstrap code. Every thing works perfectly. And we get the benefit of 1000s people testing bootstrap.

Did you use any library for example form validation, or did you do that on you own?

We implemented our own. We don't need more than 10 different type of fields. So basically it will take couple of hours to create those base components to our requirements.

The main lession I learned in JS world is, when the requirement is small, better write it from scratch using code we find on net. Trying to integrate different incompatible libraries will just waste our time.

not vue, but I use ReactStrap + Bootstrap4 for that, and it works good.

Bootstrap 4 has some small rendering artifacts (like datetime inputs in inputGroups) but they are pretty fast about fixing them. (Though my input group example, the fix will be in the next release, beta1)

You should check out Vuelidate. It tries to avoid any extra fluff.

Disclaimer: I'm one of the authors

Thanks for writing this, as I was just browsing through and wondering how it would look/work in practice. I got impression that a lot of components really don't need Vue that much.

I am not against having things packaged like this, but like you said, Bootstrap, Foundation etc specialize in this, it seems like overkill not to use them.

I've used it in multiple projects, it's not perfect but overall I'm happy. There are other component frameworks, but in my experience they are crap, even the ones based on bootstrap. If you want total control, you are better of writing your own and picking thirdparty vue components trying to solve one problem.

So how was Vue for an enterprise application?

I would also be interested in this.

I was looking at Vue for our enterprise app primarily because our frontend UI code is very complex and difficult to reason about (built on an older tech stack). Thus far I've only ported one of our more complicated UIs to Vue and as I expected the code is far simpler to understand. I pretty much knew this going in though. We would get similar benefits from React, but I do prefer Vue.

There's still some unknowns for me. I have this integrated into our existing app so that on route start it creates the Vue instance and on route change it destroys the vue instance and while that works fine for now I'm not sure if it will cause issues as we migrate the rest of our app.

I also rolled my own validation (which is pretty easy), but I need to evaluate the existing solutions to see what benefits they give.

Was surprised on mobile that the InputNumber field doesn't spawn a dialer pad (tapping it brings up the alpha keyboard). There are some elements here, for sure, that just seem to be minimally skinned and not fully thought out. Bummer, because I have a lot of work based around enterprise design systems and I love seeing fresh takes on these types of components... not much depth in this library, unfortunately.

The date/time input was particularly disappointing... the time being absolutely hideous even on the desktop. These days I consider material-ui.com (react components) to be one of the best component libraries I've seen. Short of that, I'd just assume use something like Bootstrap for the (s)css and control most of it myself, which is easy enough.

In fact, I'm half surprised they didn't just do a nice set of components meant to be used with Bootstrap, considering the style choices are very close.

I've never used Element, but I share your sentiment. For a library like Vue which doesn't yet (!) have the adoption of React, I tend to avoid 3rd party component libraries especially if they are full of fluff like footer/header components.

I looked at using Vue 2 with bootstrap 4 this past weekend and it seems most Vue+bootstrap integrations are for Vue 1.x while the Vue 2.x bootstrap libraries are incomplete. Instead I just included bootstrap's CSS and for the most part things just work. For things that require JS like modals I found the official bootstrap JS code was very easy to read and had a Vue modal component up and running pretty quickly. I wish the bootstrap docs were a bit clearer as to where JS is used to enhance components. The foundation docs in comparison have the tiny "JS" badge next to all the JS enhanced components, but I'd like to see something more along the lines of "JavaScript is required to disable the body element's scrollbar and to dynamically add the modal backdrop to the DOM".

One thing I find tiring in the JS ecosystem is the constant rewriting of vanilla JS libraries so they play nicely with virtual-dom based libraries and all of the framework specific component libraries which too often play a major role in determining our tech stack. It all just seems like a massive wasted effort.

    It all just seems like a massive wasted effort.

I think many of us pursue new tech to ensure the chore of doing our work remains fun and engaging, the most important priority! Probably billions of dollars got spent last year just so startups could migrate between one pointless stack and another to entertain their developers instead of their users, and the punchline is the developers still aren't comfortable enough.

Hah. I realize that problem exists in the industry, but for us there's certainly tangible benefits to switching from our current 6 year old UI framework to Vue or React (see my other comment down below).

I was mainly referring to the wasted developer effort of making wrappers for bootstrap, foundation, semantic UI, etc. of varying quality for every framework (react, vue, ember, etc).

In addition, while I realize this isn't a realistic goal :) I wish that our choice in component library was independent of our framework of choice. For instance, it would be nice to use ionic with Vue without spending 2 years writing a vue-ionic wrapper.

What is a DataGrid? A Table? I seriously don't know that

Typically a table with (optional) sorting, filtering, re-ordering, and/or drag-n-drop.

One of the more complete "new" widget sets is Clarity by VMWare (https://vmware.github.io/clarity/documentation). It is based on Angular 2, though ..

This is one of the reasons I'm working on Bootparts[1]. I needed components to build websites that were JS agnostic. Its based on Bootstrap 3 and under active development. Check it out and let me know of any feedback you may have. Its fairly new (v0.4) but have a 5 year commitment to it.

https://yelluw.github.io/Bootparts

I really like Element but it's a shame they don't it responsive, when I tried contributing to make things responsive they actively denied the PR saying it's for desktop apps.

Actively refusing pull requests that make the framework responsive is a bit of a downer for me, but overall I like what the author(s) did

"it's for desktop apps"

haha can you imagine if desktop users had different resolutions and aspect ratios on their screens? oh wait...

It's an excellent point. This one response from the team is enough for me to lose confidence in the project.

They have their own mobile ui https://github.com/ElemeFE/mint-ui

Is it just me or the mint-ui homepage[0] doesn't display anything at all ?

[0]( http://mint-ui.github.io/ )

Works fine here

blank for me too

For mobile FrameWork7-Vue has the most mobile components ready-made... Not affiliated, just a big fan

https://framework7.io/vue/

For anyone looking for a lightweight responsive library, Bulma http://bulma.io/ is a great option. It pairs with Vue quite well since it's a CSS only library.

Note: I'm not affiliated with them, just using them on my latest project.

I agree. I've been using it for my personal project and it has been easy to grok and looks great.

It's looking good, one thing that bothered me as it's css only is that form elements like checkboxes and radio buttons need to be styled separately (https://github.com/jgthms/bulma/issues/44)

If more component libraries went with the following structure...

    <label>
      <input type="radio" />
      <span>Label Text</span>
    </label>

It's easy enough to target the input/span as children of label for custom styling, without having to use JS or some weird wrangling of classes and structure.

I just created a project using VueJS and Bulma and everything went really smooth.

*I switched from Bootstrap 4.

I've been using Bulma on my side project. Really nice looking and super easy to use. I like how it doesn't try to do too much.

I tried using Element on my current project and, like other commenters, found it to lack enough responsive utilities to make it useful. Then I stumbled upon Quasar (http://quasar-framework.org/). It's responsive, supports Cordova and Electron, and it looks good. I rarely switch frameworks mid-project, but this was well worth the effort.

Looks really good. I usually judge a library by it's data table. This one seems surprisingly featured.

Will try it too.

Question for HN: I'm a systems developer and want to play a bit with frontend development (writing frontends for custom tools I built).

What framework + feature-complete component library is recommended in 2017?

React? Vue? Polymer? Plain JS with intercooler.js? I feel a bit overwhelmed.

I've been using Vue for a similar purpose this last week or two and I've found it very simple and easy to follow. I'd recommend that.

What component library to use?

Depends on which components you need. Normal HTML with Bootstrap CSS will mostly cover the basics.

And there are other individual Vue component libraries like VueTable etc.

Currently I'm not using one, building my own context menu, graph and grid components as a way of testing out vue, and to see if I can do it. Reasonably straight forward so far

I had begun to write a guide, but currently busy with something else :-(

I find vue to be an amazing library, got started within a week

https://github.com/thewhitetulip/intro-to-vuejs/

It depends on what you want todo and how complex it is. Should it run only in a Browser or Mobile (native) too?

You will find 10 People that tell you use X, 10 use Y, 10 use Z, any suggestion is right and any would be wrong.

Look at the frameworks and features and decide which one come close to your prefered development style. It is not easy and it took time.

In the last 24 month i tried many: backbone, ember, aurelia, react, react redux and currently vue and many of which i forget the name ;-). All have there pros and cons.

If you always look for a newer thing, then you will never find one. To myself: Lesson learned ;-)

I'm using react (with clojurescript) & angular2, and would suggest React. It is becoming mature and stable, great ecosystem, and a clear direction while angular (and other alternatives) are still finding where to go, mostly copying React. I'd go straight to the source.

Mithril is a very non-overwhelming framework. You can find a number of pre-built components for it at https://github.com/lhorie/mithril.js/wiki/Components but I bet you'll end up building your own.

How familiar are you with JavaScript? HTML?

I've found Mithril to be a giant pile of crap. Buggy on most browsers and incredibly painful to use. Run, don't walk from this platform.

What browsers and what bugs? My experience has been the opposite of yours.

This comment bears no resemblence to the experience of those of us running mithril in production

If you want it to feel more like backend development, give clojurescript a whirl.

Best way to do that is start with this template: https://github.com/Day8/re-frame-template

Which is based on this library: https://github.com/Day8/re-frame

ClojureScript is fantastic. Being immutable as a baseline makes it work so much better in the React world of things. That said, if you haven't used any Lisps it can be a bit intimidating (for me it still is, a bit), but you get to the point fairly quickly where things can be both daunting and productive at the same time.

If you prefer to stick with more raw JS, I recommend React without a data-framework until you find you need one. Raw react components are plenty to get you started.

I would disagree. ClojureScript is very cool, but unless you're adept at functional languages it's another big jump for someone new to front end development. Plenty of time to do CS a little later.

I mean, by that same metric if you aren't familiar with JS paradigms it's a leap on it's own, no? So I don't think that's the right metric on it's own. I also think that getting started with ClojureScript is pretty simple, even if you aren't super familiar with FP (though it will definitely stretch your brain a bit).

ClojureScript gives you the opportunity to write code that's somewhat imperative, just with plenty of extra parentheses.

> I mean, by that same metric if you aren't familiar with JS paradigms it's a leap on it's own, no?

A smaller leap from a OO language to JS than to ClojureScript, surely you agree there.

Of course! That said, I think the typical use with ClojureScript/re-frame doesn't lead you into an academic or pedantic world of heavy FP. The benefits of being functional are largely abstracted away. You're mostly going to be writing some HTML in DSL-style reagent(1), and mapping over lists/maps.

That's largely why you can get productive reasonably quickly, even with the intimidation factor still present.

(1): https://github.com/reagent-project/reagent#examples

I think that's just a benefit of lisps in general, they don't focus on the academic "look at how smart I am" aspects of FP that the ML languages do.

React is actually not that easy to pick up. Tons of ways to do things, messy data management, complex lifecycle hooks.

vue or riot would be a good choice to play and develop something quickly I think.

I finally spent the time to learn it recently, and it's really only hard if you make it hard on yourself. Plain old react without redux is pretty dang simple, actually.

I agree that it depends on your project, but I've used all the frameworks you listed and Vue.js stands out to me. The documentation is top notch, the ecosystem is flourishing, and using the framework feels intuitive. Drop one script into your project and you have a fully reactive front-end at your disposal (or you can use a more complex build system like Webpack). I'd suggest reading the official 2.0 guide here: https://vuejs.org/v2/guide/

Let us dispel the notion that webpack is 'complex'. webpack works extremely hard to make its documentation [1] and overall tool easy to read and use.

The community is ever-growing and it has one of the most helpful and enthusiastic maintainers I've ever seen a JavaScript OSS project have. Ever. (Look at you Larkin!)

From egghead.io to online documentation, you will see that while webpack has a lot to it, it is easy to understand in chunks and each part of webpack serves a purpose to better optimize and structure your workflow.

[1] https://webpack.github.io/docs/tutorials/getting-started/

Webpack is complex in the same way that all build systems are complex – they take time to understand and configure. In the context of this thread, where a systems developer is feeling overwhelmed by front-end development options, Webpack is certainly an added complexity regardless of how well it's documented (which, I agree, have significantly improved).

I understand where you're coming from (Webpack initially got a bad reputation as being complex and folks are working hard to improve it) but my note about complexity was relative to simply dropping a script in the page to get Vue.js up and running.

To all the Webpack maintainers, and to all contributors of open-source projects, I can't thank you enough for your efforts. You open doors and expand the minds of developers like me and I'm forever indebted to you.

Quick FYI: that link is the old-old Webpack 1.x docs.

The current Webpack docs, which have been completely re-written and are _vastly_ better, are at https://webpack.js.org/ .

I'd stick with Angular combined with Bootstrap to get stuff done quick - that said it might be useful to learn plain html/css/js first so you are aware of which features are introduced by frameworks.

I would suggest Polymer. Web Standards based - has comprehensive library of elements and polymer itself is a tiny library.

I've had very good experience with it - if you know html/JS you will feel at home.

As for being "feature complete" - it has probably best implementation of material design elements and you can find a ton of other element on https://www.webcomponents.org/.

It is also interoperable with other solutions like jquery/angular/aurelia and others.

Polymer works very well for it's use case, but it is very difficult to make it work with tools like webpack. It ends up requiring what feels like a lot of hacks. SystemJS seems to be a bit easier to work with since there is a plugin for requiring the necessary HTML files.

Polymer 2.0 looks to be much better.

I probably wouldn't let your build tool choice influence the UI framework choice. Other way around, actually. Polymer has an excellent build tool of its own.

Can I use Polymer components with Vue.js?

Polymer elements are "normal" elements so yeah you should be able to do so unless vue does something weird.

https://github.com/vuejs/vue-element - this might give some hints.

No you can not. Telling from experience. Here is the reason..

Vue is optimized to create/update your DOM elements based on data. Polymer does create a DOM node and internally implement lot os JS to create their own shadow DOM. Each Polyer component can have different life cycle (for Example and Table Component can actually creat TR,TD elements after some time of creating your Custom Table Polymer component). And Vue does not know this. Once the Dom for parent tag is created, Vue assumes its work is done. And if data change mean while it will remove it or update it. But Life Cycle of prevously create Polyermer component may still in progress...and you will get lot of exceptions in console.

How to burn your fingers and see this problem..?

Try to use OnsenUI Polymer components with Vue.JS. Mainly any List and Table tags with dynamic children bound to data.

I don't understand your point. Can Vue update `<input>`? If so it should be able to update any custom element.

Yes, that is what I thought. Until I started using some more wired Polymer components. Not all components get problems though.

Weird, vaadin made a compat layer for polymer/angular and it works well. I would expect vuejs would also work reasonably well with proper compat. shim, there is one for vue 1.x.

Thanks. It sounds like it would get easier with Polymer 2.0?

https://www.polymer-project.org/2.0/docs/about_20

Polymer is built for the world without Vue.js or React. They are slow and heavy weight compared to very very optimized DOM operations done by Vue.js or React.

I think the time for Polymer is gone, and it is better to forget that it exists.

I mean, custom elements just shipped in Chrome a few months ago and are shipping in Safari soon. Firefox is in active development. So a bit too soon to say a technology's time has passed when it hasn't really had a chance up until this point.

Chrome has had Custom Elements since v33, almost 3 years ago. Maybe you're thinking of the latest (v1) iteration of the spec? http://caniuse.com/#feat=custom-elements

Yep, v0 doesn't count, it's a legacy Chrome-only feature for now.

The performance benefits of virtual DOM / DOM diffing are way, way overrated IMO. You can use that stuff with Polymer where you really need it, but I just use plain Polymer for everything and it's awesome. I think the time for React is gone :-P

Jesus, already? :-P

Interesting - the benchmarks prove otherwise - it is as fast as other new solutions. So i think you never actually used it in production at any scale.

If angular 1.5 was OK for thousands of devs over recent years then Polymer that is comparable to ng2 or react is more then enough.

Not to mention that for a world without polymer - some of biggest enterprises in the world are betting on it (and I don't mean just google here).

We did use in production. And it sucks to support it. Problems.. * Dynamic components wont work with Vue. Lists etc. * Loading individual html files for each component. Could not figure out how to bundle the components with Webpack.

If you still want to use it, use it without Vue or React.

Well, people use them with angular 1/2 and aurelia so im quite sure it should work with vue/react.

I did bundle my components into single file - even throwing in sass compilation so I think the problem is elsewhere ;-)

React. If you're new to the front end, it makes sense to choose the most popular tool that has way more documentation, blog posts, stack overflow answers, etc than anything else.

Well, in terms of your most popular, Angular 1.x is still slightly ahead... I happen to prefer React + Redux + material-ui.com's components. But that's not the only option. I can see why polymer/web-components may be appealing to some... I don't really get peoples desire to use any version of Angular for new projects though, I just don't care for it.

I don't know vue well enough to comment, but a lot of people seem to like it.

But most of the posts or stack overflow entries are obsolete and confuses more than it helps, you always have to look for the version or the date (if they are mentioned)

Frontends for tools -> dashboards, right?

https://github.com/akveo/ng2-admin

And to conjure it alive with data: http://stackoverflow.com/questions/39905586/how-to-consume-r...

I started a simple project a week ago. I use Vue and Semantic-UI. This combination looks very good for me so far.

Of the 3 choices that you gave, I'd use Vue.

If you broaden the scope to 'let's use anything', then I'd suggest Ember since I like their model layer better.

The React ecosystem is a bit fractured at the moment, so jumping into it is a full-time job.

In a year or two, I expect it to settle down when some framework rises out of the morass and gains credibility amongst the majority of dev's.

As a back-end developer who recently made a trip up to frontend worlds I would recommend vue.

Big advantage of vue, that you can just include vue, some component library (like the above, or vue-mdl in my case) and start building stuff. You don't need learn 5 new transpilers and build tools to get the simplest thing done like described in https://hackernoon.com/how-it-feels-to-learn-javascript-in-2... .

All the options you mention are perfectly viable, and none of them is 'strictly better' than the other. This thread will be filled with people telling you to use one of them because reason X, or not use one because reason Y. It's like arguing which brand of beer is the best, there's no definitive answer to a question like that. This thread will be filled with choice-supportive biased comments, and their arguments might not apply to you at all. It comes down to personal requirements and taste.

Really like Javascript over HTML? React is probably for you.

Don't care about details and just want things to work? Vue could be nice.

Prefer sticking as close as possible to the W3C specifications? You will like Polymer.

Telling you want you should use is like telling you what things you should value. Again, all the options are great. All of them have mature tooling, and will 'just work' if you buy in to their way of doing things. Just try them and figure out which one you like.

If you can stomach a little build tool complexity (a one-time cost), React + MobX is basically a better, simpler Vue.

From my experience, would strongly suggest Vue. I am a systems developer too and started playing with UI for a side project. I started building the app and started with Angular, Angular 2, React and then heard about Vue and tried it. Vue makes things super easy and is well documented. I was super productive and got things done fastest on Vue.

Used it since some weeks. Good documentation and examples, don't be afraid of many chinese chars in the doc or on github issue, they try to write everything in english too.

Always got quick response when i had issues.

Great advantage, which is not so exposed, is, that the form system has a good (i think well known) validation system integrated. Developers did not need to build own hacky solutions or search other libraries that work mostly not good with an external UI.

Desktop only framework seems like a bad idea.

- How can you be sure you won't be asked for a mobile or responsive version down the road? People change requirements all the time.

- If you want to ever work on other type of projects you now have to learn two when one may have sufficed

- Community size is a huge factor for contributions and momentum, and desktop only limits your community size

For this framework it would be more useful if they offered a single component for a data grid. That's more work than the rest of the framework combined.

Developers are creating lots of UI libraries but after sometime they lose traction and support for this library abandoned, bug fixes/improvements will be halted. If so, why create so many libraries instead of writing yet another theme for bootstrap. Best example is material ui kits, they are a lot, but only 2 or 3 of them are still continuing development

While I agree with the sentiment in general, I don't think Bootstrap is a great solution either. It's very easy for a project to outgrow Bootstrap at which point it becomes a burden instead of an asset.

Could you expound on what you mean? How is it easy to outgrow Bootstrap?

I'm not OP and I made the experience with Zurb's Foundation but the problem isn't specific to the framework.

In my opinion you'll run into issues with these kitchen sink frameworks once you try to do something custom - customizing elements and components feels like fighting the framework at a certain point and once you realize that it's hard to get out.

I don't recommend using Bootstrap or any other framework unless you're very certain about future requirements.

Here's a nice talk on the topic: https://www.youtube.com/watch?v=Mea2jIXQEFk

I find that using the SCSS/Less source for bootstrap is less fighting... the layout/structure is pretty easy to use internally, for the most part, everything I need for creating additional controls starts from variables and utilities.

But you would break all that once it comes to updating the framework, wouldn't you? With Foundation it was either that or constantly overriding framework defaults. Once you took a look at the rules in the browser inspector / dev tools you saw many of them leading to conflicts and it felt very messy despite end results working out.

I usually copy the variables/utils to my project (often just the variables)... when updating minor/point version updates, it's usually a quick diff against the framework version to see what's been added/changed. Major versions are usually close to a rewrite of the rendering templates/components, so that's the case regardless.

I have my own bootstrap.scss, with my own variables/utils... the rest point to the framework versions... It's pretty easy to do and works out really well imho. Of course, I often only change a few colors, and tweak some of the font defaults.

The same argument can be made for non-ui abstractions.

I've been using this library for the last few weeks in two different Vue.js projects and it's awesome. The English documentation is still being written, but the components are really well thought out and complete. These folks made a beautiful, solid UI library.

Vue is really nice to develop in. I have led the push to adopt Vue in our company now. It is very well put together and along with WebPack is really improving our entire setup. It definitely provides the kind of standards we need to grow our team around.

Also this is a very well put together component library. I will definitely be investigating it more.

Element seems heavily inspired by Ant Design for React [1], which came out of Ant Financial/Alibaba.

It's a project by Ele.me, a Chinese food delivery company. Alibaba and Ant Financial invested $1.25B in it last year [2].

[1]https://ant.design/docs/react/introduce

[2]http://www.wsj.com/articles/alibaba-ant-financial-to-jointly...

I get a 404 when opening any of the linked pages in a new tab, since the URLS are missing a '#'.

Don't want this to sound like bashing, but the website doesn't work very well on mobile (hover and active states act weirdly, menu very clumbersome, etc.), and I assume the same can be said about the toolkit. Hopefully this is an area the author(s) plan to work on.

UPDATE: Just realised this is developed by a Chinese food delivery service ele.me (饿了么). I visited their website and found its developers made it completely without RWD in mind. This explains things…

Primary it is an UI for Desktops not for Smartphones.

Most UIs are Desktop or Mobil based, a UI which fits all is hard to find and sometimes not really good.

unfortunately it's not, they even actively refuse PR that attempt to make components responsive

Unfortunate indeed. I get that making things work well on both desktop on mobile is difficult (if not impossible), but at least the UI should be somehow usable. The nav works so poorly on my phone I can’t even browse all the pages on the site. Guess I’ll continue my search for a good UI toolkit for my Vue projects somewhere else. :(

Link: https://github.com/ElemeFE/element/pull/1562#issuecomment-26...

> Thanks for contributing, but Element is not for mobile web apps, so the changes here may seem a little weird. Maybe you can just override its CSS in your own project.

It says its a "Desktop UI Library" so I guess they don't care much about mobile support.

In a project I work on right now I use no XML/HTML. I love HTML and it's great for static web pages/documents and for "old school" server side rendering. But for a SPA with real time and dynamic updates, it's the wrong tool. It's much faster appending the elements to the DOM. Lexical scope and closures plus being able to call functions that returns elements in JavaScript makes it fun.

I like that this one has a tree component, it seems like most widget sets (SemanticJS and Bootstrap and everything Material included) forget about the tree.

Actually, I have seen multiple libraries aimed for desktop UI that implement trees. Seems that trees somehow were lost in the transition to web applications.

Sadly this library seems pretty poor for accessibility :(

Since I started using rem for font sizes I just can't go back to px, I find rem so much better for responsive websites and would recommend it to anyone who did not try it yet.

What's the benefit? I don't like having to calculate how big things will be (by converting base font + rem to px) while with px I know immediately.

You don't have to calculate anything, 1 rem is 16px by default, but you can set html font size to 62.5% and it will be 10px, so if you need something to be 20px (if you are used to px sizes) - you can just set it to 2rem and it will render as 20px. It's not a matter of calculation but just a matter of getting used to how big is 1 rem.

The biggest benefit is that you can target specific screen sizes with different html font-size values using @media queries, so for example for bigger displays you can set html font-size to 120% and it will result in automatic increase of size of all the elements where font-size or paddings etc are set with rem. Same goes for mobile devices, for examples all the headers will go from being 40px font-size to say 25px, just by changing an html tag font-size value, you don't have to target any elements individually, it will be automatic.

For me it was one of the best discoveries to increase productivity, when building responsive designs.

Cool, thanks! I will try it out for my next project.

I love how comprehensive the set of components is - trees, tables with lots of options, sliders, date and time pickers with range support, carousels...

I was going to give Vue.js a try for my next project anyway, so I'll be giving serious consideration to using this instead of my default choice (Bootstrap).

Ah, I hadn't noticed that it's touted for desktop apps... and isn't responsive. Might give it a miss then..

What does "eleme.io" even mean? How sad of state are we that everyone feels compelled to use these nonsense "io", "me", "to", etc. domains just because they are "hip".

It means the domain squatters own just about every single word of every TLD at this point.

I can attest to this fact. Many domain squatters sit on four, five and even six letter premium .com/.org./.net domains waiting for their payday that never comes because no one will ever pay that much money when the alternative is to use another domain name.

And of the people that CAN pay that money, what happens is they send a notice of their newly-established IP being used in a domain and they get it with the help of the registrar.

It's ridiculous to expect a person pay $1000+ for a domain when they go 'oh, we'll just use another domain name!'

People are dumb.

edit: spelling

Terrible domain name, no doubt. However, I like that these alternative TLD's are becoming somewhat acceptable now. Finding an unused .com domain for a new business can be really hard(/expensive). For example, I would much rather buy dropbox.io than getdropbox.com. Or maybe even drop.box?

the company that develops it is called "Ele.me"[0]

[0]https://www.crunchbase.com/organization/ele-me

Interesting. Then the domain is not that terrible as I thought. Too many "eleme" in the names. :-)

"Just for Product Designer" ? Some weird copy going on.

Author is Chinese apparently.

Vue.js has a large traction in China since the creator speaks Chinese and all the docs are available in it as well.

Besides the already mentioned UIs I am also watching https://vuetifyjs.com , looks promising.

If I click the link to a new UI lib from my phone and the demo is janky as fuck I'm not going to pull it into my project. Maybe I'm just being an asshole.

Any other PMs on here that can vouch for this as a solid prototyping tool? My current prototyping options are either too time-consuming or too restricting...

Hello!

Sorry for bringing this issue here and I'm sure many may not understand my point... but, after reading some posts about objectification of women (like this one: http://www.heroicgirls.com/de-objectify-women-comics-guide), could the woman in the homepage picture be drawn differently?

I'm sure it was not intentional and it may be seem as a small issue for some people, but I know women who do not like to be represented that way.

Thanks for understanding =)

Btw, I really like the page design! It is great =)

I thought this would be like a tool to build a styleguide for your application. Not an actual framework like Twitter Bootstrap. :(

The links at the top (Guide, Component, Resource) fail when trying to right-click -> open in a new window :(

When I found this, I thought it was for WebComponent based and for all frameworks.

How is it comparing with taking, say, Semantic-UI, and use it with Vue?

If you have to use a command line to install it, it's not for designers and PMs.

Reply on news.ycombinator.com