Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Vue Dark Mode – A Minimalist Dark Design System for Vue.js (vuedarkmode.com)
146 points by LeCoupa on Nov 1, 2018 | hide | past | favorite | 52 comments



I might be a bit out of touch with frontend, but what's the reasoning for this theme being tied to a framework?

I always learnt to keep markup and styles separate as much as possible, because that was beneficial for re-use, maintainability, etc. I would see the JS framework as providing the markup part, so surely the styles should be an orthogonal concern? Would this library not be better as a CSS library that apps can use regardless of the JS (or lack of JS) that they choose to have?


The current wave of component-based development is blurring these lines. A Link component can contain the markup, behavior, and styles--presenting a very simple API to the developer.

I find myself taking a hybrid approach these days: common styles and variables (primarily variables) in global SCSS/Stylus stylesheets, and component-specific styles defined in the respective Vue components.

As it turns out, I have very few truly common CSS classes.

EDIT: To address the re-usability aspect as well: this approach absolutely makes it more difficult to re-use styles across other frameworks; but if I'm moving from Vue to some-new-framework, stylesheets are the least of my concerns.


To play devil's advocate, you can release both in a hierarchical structure. There's no reason that the component framework can't import a Sass project for it's styling. Then folks who don't want to use Vue can still make use of the styles.


Absolutely. And a number of projects do exactly that.

Bulma -> Buefy Bootstrap -> VueBootstrap, et al.

That said, if you're already using Vue, then a Vue-based framework is more convenient.


Yes, it should be just a css file.

But how cool is that? A css file. Not as cool and professional as a 'Design System for <frameworkname>'.

Also, in my experience is that once a developer has mastered a framework, they are so proud of it the tie everything to the framework. To pledge their allegiance. And to signal to the pack "Hey, I'm part of the family!".


I'm so tired of seeing this attitude. This isn't about being "cool" this is a visual system for Vue that includes Vue components. Meaning this isn't a collection of styles, these are components that have been styled.

Why do you feel the need to make sweeping generalizations about the author and the author's work? Just shitting on someone/something for the sake of it?


Please, please don't make your UI components unaccessible by removing the focus ring("outline: 0"). You're basically excluding all keyboard users from using your widgets, because I simply cannot tell which element is currently focussed.

If you really find the default browser focus ring ugly, feel free to style it or provide another alternative (like a box shadow).


I don't understand what you mean. It's just using border instead of outline. It would still show as active if focus is from a keyboard. The changes are not tied to click events.


Most of the elements do not change visually at all when tabbed to?


That's a browser implementation and an html issue. They're just displaying the items here, not putting them in a true form.

If you put these components into a <form> tab would work fine. The :focus state would still happen, and that's what's styled.

edit: I see what you're saying. I was only looking at form inputs, but i see no focus state on buttons as you said.


I agree also. Another method, albeit more advanced, is an option to not show on mouse clicks, and do show when using the keyboard or cycling through tab indexes etc.


You're right. I just fixed this. :-)


This looks pretty nice and there's loads of good stuff here - well done!

Two comments: 1) I am really not sure about the resizing hover animation on the buttons (it feels too slow and looks like it goes a bit blurry as it resizes, at least on my non-retina external display); 2) I don't think the checkbox having the tick in it in the unchecked hover state is the right behaviour and will probably confuse some users.


I agree with both of these issues. In addition to looking blurry, it is difficult to differentiate the hovered button by size alone. Consider adding a border or other effect to better indicate the hover state. A few of the other controls on the page do this. For example, the buttons you use below your section headings change their outline when hovered.


I see that blurry zoom transition effect all over the place. I suspect retina Macs don't do it, so designers keep doing it. Kinda reminds me that up until recently, Shopify used to only list Helvetica in their font-family, so Windows users saw Times New Roman. I see that stuff all the time coming from Mac-centric design firms.

^ I hesitated writing that, since it was all speculation, but then I clicked the link at the bottom saying "Hire me!" to see the designer's website and...

    html {
        font-family: "Avenir";
    }
No fallbacks whatsoever, so I'm seeing Times New Roman.


Thank you for your feedback bshimmin. I removed the resize property and reworked the hover effect. :)


I have the same issue with button resizing on my 4k monitor, I think it would work better if just the button resized, not the text, since the spacing between the letters bounces around when the text resizes.


Some things I noticed missing from something like http://element.eleme.io/:

- clicking an input with placeholder text brings the cursor to the front of the input text and doesn't erase the existing text. This is very bad UX.

- no example of a full form with validation errors

- no file upload input

- no HTML5 number input

- no multi-select clearable/filterable selectboxes... select2 style selects are pretty standard these days

- no date/time picker, another essential form component

Not trying to be critical, I'm sure these will come with time. But this is far from a production usable framework in its current state.


As an aside, I don't why top-aligned infield form labels[0] aren't more popular. I implement the style whenever possible.

[0]: http://uxmovement.com/forms/why-infield-top-aligned-form-lab...


The orange is yellow. Great color pallet though, it's really easy on the eyes for the most part.

I'm not that into frontend dev, I mostly stick with backend and devops so for me, when I need to make a front end without a ton of bells and whistles, this kind of stuff saves my no-css-skills-on-my-resume butt!


Thank you for your feedback. I made it more orange. :)


The name makes this seem a little bit more official than it really is. And I agree with another comment that a light mode would be nice. Then, the name makes less sense.

I’d suggest to consider a different name, that would identify the design system (like Blueprint or Material), not a feature of an existing framework.


Looks nice!

One observation: your select options are unreadable in Chrome on Linux. You probably need a colour other than white for the option text.


Yes, I guess it looks like this? https://github.com/LeCoupa/vuedarkmode/issues/22


Yup!


The toggles have a visible dark border around them. Not too noticible on an LCD but fairly visible on OLED.


I think the bigger value is in decoupling the visual style choices from the framework used. This one seems to be going the other direction. Not only is the overall visual style "burned in", but it is permanently set to "dark mode". This seems like a safe choice only for small, short-lived applications.

(By the way, the new stuff from Google in which they have made Material Design much more configurable, is a great shift in the right direction. Of course it would be even better if the whole material-ness of an application were a runtime switch, but there are significant obstacles to that.)


Is there a reason why it is "Made by Nada Rifki" and it's her profile that shows up on the footer while she did 0 commits on the project?


It's odd they're marketing themselves as a Vue freelancer when their GitHub just has 1 intro project from 3 months ago. https://github.com/nrifki?tab=repositories


It looks great. Great work!!

Also, is there a reason why we can't toggle on and off dark mode to compare it to a non dark mode?


Designer vs developer maybe?


It would be more interesting if there was styling for light and dark mode, so you would be able to switch between depending on user preference.


Yes, I'll build this next week. That's why I added a toggle "Dark Mode Activated" on the bottom bar. You will be able to switch between both. :)


Love it! I had to make my own dark mode for my app, I wish I had this before.


Super cool! :)

Two notes:

- The Nuxt.js code sample is the exact same as the Vue.js one — unless that's intentional

- The button icons have `cursor: default;` on them which is kind of weird because the buttons are `cursor: pointer`. Perhaps keep it consistent?


Yes I updated the cursor css property to "inherit". Thanks :)


Good stuff. The native UI for selects is bleeding through in Firefox to note.


I would love to use this if it was in React. It looks really nice. It would also be cool if there was a light model that one could toggle between. Calling it dark mode implies their is a light mode no?


Yes, I'm currently building the light mode. ;)


The orange colour is too bright, and the white text on the orange buttons is unreadable. Other than tweaking this colour it looks fantastic!


Thank you! I'll fix this :)


Dark patterns!


How does a theme for a framework make it to the front page?


Exploit the HN ranking algorithm[1]:

    (= gravity* 1.8 timebase* 120 front-threshold* 1
       nourl-factor* .4 lightweight-factor* .17 gag-factor* .1)

    (def frontpage-rank (s (o scorefn realscore) (o gravity gravity*))
      (* (/ (let base (- (scorefn s) 1)
              (if (> base 0) (expt base .8) base))
            (expt (/ (+ (item-age s) timebase*) 60) gravity))
         (if (no (in s!type 'story 'poll))  .8
             (blank s!url)                  nourl-factor*
             (mem 'bury s!keys)             .001
                                            (* (contro-factor s)
                                               (if (mem 'gag s!keys)
                                                    gag-factor*
                                                   (lightweight s)
                                                    lightweight-factor*
                                                   1)))))
[1] - https://news.ycombinator.com/item?id=1781417


I'm not sure why this would be questioned.

On the front page of Hacker News right now we have articles about conservation, witchcraft, the death of an author, the Japanese language, horror and WWI, and ketchup.

And this is a relatively tame day.

A theme for an extremely popular framework used by many "hackers", created by a fellow HNer and presented as a "Show HN"... this seems exactly in line with the spirit of Hacker News. This is the kind of thing I would expect to see on the front page.


A new theme is created for a framework at about the same rate that mosquitoes reproduce.


Even though it's not really something intellectually appealing, I was not aware of this and glad that I saw it.


People upvote it and the algorithm does the rest


There is something else going on. People submit things that go into oblivion that are much more compelling.


Because the flag algorithm works quite well too. You should flag this one if you think it's not newsworthy.


I assume "Show HN" items aren't necessarily news, but just someone showing the community something new that may be of interest. There already appears to be too much flagging around here just because someone doesn't particularly like something. Let's not encourage more.


It was probably posted before the rush hour and reached the front page with only a couple of upvotes.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: