131–140 of 296 posts
Gimme a dark/light mode switch. CSS is allowed.
Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
Plain HTML is very cozy to me - I came of age in that era. Marquee tags 4eva . But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR sy…
> Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code. You're overthinking htmx then. I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page. Server always has authoritative state and code is dead…
Yes, almost certainly!
> I do some fairly complex stuff with no extra partials. Trick is just always rerender and use hx-select and hx-target to slice out the bits you want to update on the current page.
Good trick! My only experience of HTMX in production entailed porting Stimulus code, hence the partials, but your approach is obviously much neater. I'll give it a shot, next time it might be suitable.
Something I keep thinking about when I consider the trade-offs between building a site with HTML/CSS wherever possible vs JS is what the actual _experience_ of writing and maintaining HTML/CSS is vs JS. JS gets knocked around a bunch compared to "real" languages (although less so in recent years), but at the end of the day, it's a programming language. You can write a loop in it. Writing a web server in C++ is a way…
In the past decade, we went full JS as an industry and now we’re starting to swing back. Server side interactivity like Phoenix Liveview, C# Blazor, HTMX, PHP/Laravel Livewire, Rails Hotwire, all of these are different abstractions around JS to make interoperability between the frontend and backend more manageable and they’ve come a long way to closing the gap. Advancements in HTML/CSS standards also deserve credit for closing the gap but we’re still not quite there yet.
But at the end of the day, the web is dynamic. As new tools and techniques are discovered, the industry will continue to evolve and certain “hacks” will become new standards and ignorant newcomers will reinvent the wheel again to achieve some crazy interactive design because they didn’t know any better! And it wil work, mostly.
Until the way we interact with browsers changes, I feel that we’ll continue to bolt on new features over time and the web will continue to evolve. Just like the iPhone, a surge of use of smart glasses could change the computing paradigm or perhaps its some other device entirely.
So you can (and should!) try to optimize for today, but trying to optimize for tomorrow will always carry the risk irrelevance if the market pivots quickly. Bleeding edge is risky but so is falling behind.
A missed opportunity to not have all of these examples inline. The page/blog-post would be so much more convincing if it utilized all of these HTML replacements instead (or in addition) to linking to codepen.
The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation). I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features. [0] https://theosoti.com/you-dont-need-js/
It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
I didn't know about , but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.
It can't do complex autocomplete. It's ok for simple cases only. I use it with a 25k long list to ease the input. Works well enough for this.
Earlier quoted context omitted.
That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1] Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2] Modern CSS is awesome. [1] https://developer.chrome.com/blog/entry-exit-animations [2] https://nerdy.dev/open…
I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.
Plain HTML is very cozy to me - I came of age in that era. Marquee tags 4eva . But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR sy…
I have been trying to find other more commonly known UI patterns that could be done natively. The time has long come for tabular data to be put into HTML tables just by referencing the source. Xslt almost did that. Another one is integrating xml http requests with native html. I think HTMz came close to this.
The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation). I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features. [0] https://theosoti.com/you-dont-need-js/
Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard. It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.