| We've all probably heard about the HTML dialog element, popover API, and customizable select, but I think a lot of people don't realize how powerful and battle-tested they are and also might not know about some of the inconsistencies these elements have and that they might encounter when using them. And this is what this post is about, I'm not going to go over the syntax and basic API's, if you're unfamiliar with them, I would suggest you read some MDN pages and Chrome For Devs blog posts before you jump into this article. I would like to focus more on in-depth details and edge cases. The article will be a comparison between these native elements and UI libraries like Shadcn, React Aria, etc. You can get a better reading experience from the link above, it's demos and code snippets for better understanding. If you complete reading the article, tell me about your thoughts in the comments below. Let's start by listing out some of the common features you would expect from a robust dialog, select, or popover, whether it's native or custom JS one.
I don't know if I missed something, but let's just focus on these four features for now and see how native elements vs UI libraries approach them, as we'll see, there's a lot to unpack in here. For keyboard navigation and Escape key dismissal, the HTML dialog, select, popover, and all the upcoming elements have this built-in, you almost don't need any JavaScript at all for any of this to work, but for JS libraries, it's an entirely different story, you'd be shipping tons and tons (or even hundreds) of lines of JS for Escape key dismissal, arrow keys navigation, focus trapping, etc. All of this just to re-invent what the browser gives you for free. For back button/swipe gesture, this is also already built-in in the native components, all of them close on back button press on Android, but in UI libraries like Radix UI or React Aria, they don't even have this feature at all, despite that it can be added using JavaScript. In order to add support for back button press and swipe gestures, you can use the The browser compatibility for the The Top LayerOne thing I want to compare is how native elements and UI libraries make sure things appear on top of other page content and also above each other. To better explain this, let's take the following example from Notion webapp, here we have the settings dialog and inside we have a select that we can choose our preferred theme from. The question is how do we ensure the dialog appears above other content and the select appears above the dialog. Please continue reading the post from the link above, Reddit posts don't support demos and multiple images. If you complete reading the article, tell me about your thoughts in the comments below. [link] [留言] |
Frontend
Read original: https://www.reddit.com/r/webdev/comments/1wcg499/html_is_eating_javascript_ui_libraries/
HTML is eating JavaScript UI libraries
/u/Successful-Shock-802 Reddit r/webdev
1 views
← Previous
The Webhook is the Persistence: RBAC Misconfiguration in EKS
Next →
Keeping Translated OSS Documentation Fresh with an SSOT and CI
Related
Healthcare Platform development
Frontend
0
DEV Community
Email Signature Generator CSS icons
Frontend
0
DEV Community
I created some demo code to show how to send messages between a parent page and IFRAME, and specifically how to use that to modify IFRAME height and prevent internal scrolls
Frontend
1
Reddit r/webdev
Tencent EdgeOne Makers: My Experience Deploying a Website as a Beginner Developer
Frontend
0
Dev.to (EN Zone)
Comments0
No comments yet — be the first