Live data from Hacker News

Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

oat.ink

71–80 of 151 posts

Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

#72

The motivating blog post[1] linked from the front page is probably going to generate a more interesting discussion than the framework itself. As someone who has to deal with both angular and nextjs for different (but overlapping) stacks at work, I find myself increasingly sympathetic to this viewpoint. [1]: https://nadh.in/blog/javascript-ecosystem-software-developme...

Previously (2021): https://news.ycombinator.com/item?id=28892933

Ah ha, figured it must have been discussed here before!

Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

#73
post #28

No Datepicker?

As pointed out in another comment, it's under the form elements, not listed as a top-level component as many UI libraries do

https://oat.ink/components/#form

Which actually makes sense: Oat's driving philosophy seems to be to use and enhance native controls as much as possible, and the date picker is already a native type on the input element.

Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

#78

The code example doesn't render for me.

Ditto, if you mean the codeblock in the Typography section. edit: clarification, focus

The Preview of the Sidebar doesn't display the Logout button in the footer of the sidebar.

edit: That is, the footer is not within a visible area of the sidebar.

Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

#79

What's with variable names starting with "#" as first character?

If you are referring to class members in the JavaScript then those are private fields[1]

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library

#80

The motivating blog post[1] linked from the front page is probably going to generate a more interesting discussion than the framework itself. As someone who has to deal with both angular and nextjs for different (but overlapping) stacks at work, I find myself increasingly sympathetic to this viewpoint. [1]: https://nadh.in/blog/javascript-ecosystem-software-developme...

Nice link - still relevant IMNHO - even though it's from 2021.

Discussed at the time:

https://news.ycombinator.com/item?id=28892933

Post reply on HN