Hacker News new | ask | show | jobs
Vuetify - Material Component Framework for VueJS 2 (vuetifyjs.com)
127 points by mhaehnel 3475 days ago
10 comments

Could actually see a "flash of unstyled content" on my desktop PC. No biggie, but that makes me think about just how overkill I want to go with VueJS. (edit: wondering also if they precompiled those templates with vue-loader?)

I'm super excited about VueJS, and start using it on my site. But when I see a component for a button, you know, just a regular styled link... I wonder if there is really a purpose to that? How do you strike the right balance of what should be a component, and what can be handled as plain html with perhaps some backend helpers to output in view templates?

Also just as a general criticism I think it's not welcoming for a Vue component framework to have such a strong opiniated design built in. It would be much nicer to have the theme something relatively easy to change. It may be don't get me wrong... but my first impression is "Can I even use this? Without changing tons of style rules?".

For this I think the relatively simple design of Bootstrap is a strength. Give me the same components with a barebones design, with cheap flat buttons with some rounded corners for "pzaz" and then I feel much more confident about bringing that into an existing project. Even if I started a site today, I don't want to use Material design.

> But when I see a component for a button, you know, just a regular styled link... I wonder if there is really a purpose to that?

Why shouldn't there be a component for a button? Buttons can have endless styles and animations. They have a myriad of behaviors. For instance, there are differences in how they could respond to touches versus mouse clicks. They have a standard interface. With a component, you could keep them consistent across an application and share them across applications.

> Could actually see a "flash of unstyled content" on my desktop PC. No biggie, but that makes me think about just how overkill I want to go with VueJS. (edit: wondering also if they precompiled those templates with vue-loader?)

yeah, I agree that seems a misconfigured vue-loader/webpack issue. but when you do approach overkill, however you choose to define it, vue's server-side rendering starts to make a lot of sense. personally I wouldn't use a JS framework without SSR because progressive enhancement is important to me, but that's a digression.

I disabled the use of custom fonts and have to say that the material style of Google makes websites unreadable. Just like this framework does.

This is because the span inside an icon has a huge font size. And they use ligatures for characters (so I'm seeing the huge ligatures).

Why would someone choose ligatures over CSS classes?

Edit: I was thinking about problems with screen readers and so on. A CSS class is just styling, but what Google uses is content.

> Why would someone choose ligatures over CSS classes?

That's a really good question because I presume they did it for a reason. Why else go through the hassle?

Could you provide a screenshot of the problem you encounter?
Just disable the "Material Icons" font in DevTools and you'll see it.
What would be helpful is a comparison to all the other Vue Material frameworks that already exist. (see github.com/vuejs/awesome-vue for example) ie, why should I switch? Why did this project get created from scratch instead of adding on to the existing ones?
A handful of those other frameworks wrap Material Design Light and/or Materialize in Vue components, so this eliminates that dependency and (theoretically) provides a cleaner API.

But https://vuematerial.github.io/ looks to have pretty similar "features" and is "Vue native" as well.

I'm not UI expert, but the fact that the buttons don't have any animation change (or change in colour) when pushed down is a little grating...
ty for the feedback.
Hmm I thought I could use this and add a few Material elements to my project here and there. But only including the CSS completely changes the styling of everything on my page (buttons, inputs, etc..). I mean not even Bootstrap changes the appearance of <button> until you add 'btn' class.
While this is useful to have, I would argue that layout should be left to css frameworks (material css in this case) and components only used for functional parts of the app.

No one is forcing us to make everything a component. What would be a benefit of having a footer or header a component for example?

If you don't want to make many modifications I prefer having it like this, with each component being completely self-contained with no global CSS dependencies.
Simply for semantics, as they are done with functional components. As far as layouts, you do not have to use them, they are just an added feature to help the prototyping and build phase.
Looks cool, unfortunately like many of these UI frameworks, the more advanced functionality has been left out so far. Compared to http://semantic-ui.com/modules/dropdown.html which has searching and filtering etc.

Hard to move to anything this unless it's the most basic of applications.

Completely agree, it is one of the most important things I'm working on right now, fleshing out each components API with additional functionality.
The advanced functionality is left out because it's very difficult, and quite a waste of valuable developer time, to reimplement essentially the same widget set over and over and over again for each framework.

That's just one reason why it saddens me to see so many proprietary frameworks out there with more all the time, especially ones that are so close to being compatible with Web Components. If Vue just used and produced Web Components, it could use a common Material Design component set. The investment in fewer component sets by more people would result in much higher quality and free up developers to work on higher-level things.

And Semantic UI is far too large for a site that wants to be snappy.
thanks for bringing semantic-ui. heaven't heard of it till now, and love what I see very much!
This page had an ugly flicker as the page loaded, with the unstyled left-side navigation displayed before the CSS rules were loaded.

It's not a huge deal, and honestly I have built some sites like that as well, but when you're pitching front-end frameworks, stuff like that matters. I don't want anyone to think that that kind of flicker is inherent to Vue.

It has to do with lazily loading assets, but not actually having the critical styles inlined. It's something that I had before launch, but ultimately did not like how it was done so I removed it. It's also not a product of the framework, just where I choose to load assets in the docs for pagespeed. They can easily be moved into the head and all of that is resolved.
What's the recommended way to resolve that these days? Render your primary CSS bundle in head?
I believe best practice is to sort out which of your CSS is needed to render above-the-fold content, separate that out into a smaller file, and serve that higher in the page or even inline it. The rest of the CSS can be served at the bottom, with the JavaScript.

If anyone has a better plan, I'm all ears!

That is correct. It can just be a pain to do intuitively as all sites are different. Vuetify Documentation runs off of the vuetify webpack-ssr vue cli template which I recently removed that functionality.
I love Material Design and so does everyone else,so I'm definitely in the target group. Thank you for making this.
what's the big deal with "material"? Looks ugly as sin. I just don't get it.
Personally, I like material design, as do many others.

If done right, it makes the interface feel fluid and alive rather than just click and appear.

Whether or not you like that is personal preference.

I have mixed feelings about it.

I really dislike the trend of material "inspired" designs that seem to obscure functionality in the name of aesthetics. Things like hiding buttons and input fields as (minimally styled) text on plain backgrounds, or screwing with scroll behavior drive me nuts.

On the other hand, I do like the occasional, subtle, animation that makes the interface feel like something with a bit more substance and interactivity than usual. The little ripple animations on touch are a good example of pleasant eyecandy that adds a bit of, for lack of a better phrase, emotional appeal.

Sliding/scaling/etc. dropdowns, sidebars, and menus that move around to indicate where they came from and are going to are fine and useful, but that's hardly unique to material.

completely agree.

https://angular.io/docs/ts/latest/ is the best material implementation i believe.

Try Google Cloud Console. Even better!
"I just don't get it" sums up my thoughts on a lot of Material Design. Here's an example from just this morning, where I wanted to sign up for Netlify News: https://www.netlify.com/news/

There's a form near the bottom of page, but it's very, very easy to miss because it implements Material Design-inspired input fields. And thought this is a DIY implementation, the 'official' version is highly similar: https://material.angularjs.org/latest/demo/input

For me, no animation or clever UX in the world is worth actually hiding the input a user is looking to use.

wowser I just took a look at that. totally confusing, can not understanf why anyone in UX would find that acceptable.

I honestly think this Material thing is just a huge troll of the design community.

I don't think it looks ugly, but I'm also not overly enamoured of it. But it's free, available, coherent and familiar to users.
Same here. It just looks ugly to me.

That said, I do like flat designs. I've recently moved from Android to iOS and I'm really enjoying the UI. Although it is a flat design, it does have accents and details.

Material design just looks like something half-baked to me: I can't drop the feeling that there is way too much white space.

I find myself scrolling A LOT, when using material design. It's very hard to use.
agreed, feels like fist-sized crayons and picture books to me. too much scrolling, too much affectation, too much grey-on-white and too much padding and white space.