ajusa
commented
2 years ago One thing that might be nice to have on the home page (or on other pages) are examples targeting when folks first reach for Javascript. I'll try and list some examples here from what I can remember when I first got into webdev (apologies if I list something that's already covered in the examples):
- Fancy slide out menus on mobile (doing the transition, hiding the menu)
- Modal boxes (closing, opening, closing with esc, etc)
- Creating a photo carousel where you have images changing automatically, but a button can also jump to an image
- Realtime form validation (showing error messages or adding classes based on HTML5 validation API?)
- Smooth scroll to a part of page
- Creating a countdown timer
- A typing/typewriter effect (words that appear to be typed over time, filling in a paragraph)
- Having text appear and fade in after scrolling down (I see this effect a fair amount in footers)
- Small animations. This one is a bit weird, because you can use CSS classes for animations in some cases, and use hyperscript itself to transition other CSS properties. Drawing a line here by showing off examples of what to do might be helpful.
- Closeable popups and bars in general (like the kinds that ask for cookies or whatever, similar to modals but might be simpler?)
- Implementing a scroll to top button that only shows up if you aren't at the top of a page
- Client side routing? Showing certain elements when the URL has something in it?
- A simple todo list application? Like create, delete, and check off items using only hyperscript. This could show off the currently undocumented templating capabilities.
Generally, when it comes to JS, I've been able to learn best practices by looking at other examples. With hyperscript, I think we need to make more effort to show folks best practices for conciseness and performance. Right now, you can do some stuff in hyperscript multiple ways, using different parts of the language. It's like when you're first introduced to the command line or UNIX. There are multiple ways to view and read a file (head, tail, cat, redirection, etc) but generally, you figure out which one to use based on context and learning from others.
After reading through my list, I think some of these might not require JS anymore (specifically the smooth scroll one, might be others as well). I currently don't have the time to implement these unfortunately, but I think adding more common cases where someone would reach for a little bit of JS is where hyperscript can be really powerful. Sorry for the wall of text, curious to know if others agree with me on some of these examples.
remcoboerma
bencroker
As hyperscript approaches a stable 1.0 release, one of the areas that @1cg, @dz4k and I would like to improve are the docs. I believe it is beneficial for active community members to perform documentation reviews (similar to code reviews) and to contribute high-level explanations and real-world use-cases, so that hyperscript becomes more approachable for the front-end development community at large.
Since we have a solid starting point at https://hyperscript.org/, I suggest we focus on 3 areas.
1. The home page.
https://hyperscript.org/ is the first thing people see when coming to the site. The goal of this page is convey what hyperscript is, how the syntax looks and how it can increase productivity.
2. The docs page.
https://hyperscript.org/docs/ is where you go to learn how to write hyperscript. The introduction should read like a guide that gets you familiar with the core concepts of hyperscript, namely event handling and common commands, as well as provide useful and graspable examples.
3. The cookbook.
https://hyperscript.org/cookbook/ should feature the most common, real-world use-cases for hyperscript (and avoid abstract examples that show off speculative features), building up from very simple to more complex. The goal for the cookbook is to provide a selection of recipes that people can learn from, copy-paste into their mark-up, as well as use as a starting point for more complex requirements.
Anyone may contribute in the form of a pull request to the
masterbranch, referencing this issue and improving one of the 3 pages above (1 PR per web page, please!). All PR's will be reviewed by one or more of the core contributors, who have final say about what ends up being merged.Suggestions are welcome on how to better encourage and improve this process, to help ensure we get to that coveted 1.0 release sooner rather than later.