Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
71–80 of 151 posts
Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#72The 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
Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#73No Datepicker?
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
#74Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#75The code example doesn't render for me.
edit: clarification, focus
Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#76What's with variable names starting with "#" as first character?
Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#77Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#78The code example doesn't render for me.
Ditto, if you mean the codeblock in the Typography section. edit: clarification, focus
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
#79What's with variable names starting with "#" as first character?
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: Oat – Ultra-lightweight, zero dependency, semantic HTML, CSS, JS UI library
#80The 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...
Discussed at the time: