Most websites I enter don't work well on mobile, but this one does!
I'm betting on HTML
51–60 of 458 posts
Re: I'm betting on HTML
#52I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…
You might like this: http://youmightnotneedjs.com/
There's a scroll indicator!
It tells you, by looking at a thin bar, how far down the page you are! What a novel idea!
I wish browsers had this builtin so that we didn't need to implement a bar for showing the user how much of the document is left to scroll.
(Seriously though, wtf did firefox make the scrollbar autohide? In order to see it the user has to interact with the page. It's worse in the debugger, where horizontal scrollbar just won't show until you interact with the keyboard in some way).
Re: I'm betting on HTML
#53Oh man, there's a element?! There are probably occasions where that is the whole reason I pulled a JS framework in, since default alert boxes are horrible and anything better is a heap of work to do in a nice looking yet portable way.
> Oh man, there's a element?!
It only exist because browsers decided to remove alert/confirm/prompt. Before this it existed in a limbo plagued by so many issues that Chrome even suggested to remove the spec.
None of the issues were fixed. But within a year from Chrome's botched attempt to remove alert it suddenly shipped in all browsers.
Re: I'm betting on HTML
#54I've been using `dialog` and `details` of late, and couldn't be happier. At the same time, `section`, `article`, `header` and `footer` confuse me a lot. I've stopped using them.
Section and article really don't add any value, but header and footer elements are used as landmarks by adjustive technologies like screen readers
> Section and article really don't add any value
They are nice hints to assistive technologies and reader mode.
Re: I'm betting on HTML
#55I'm personally betting on HTMX https://htmx.org/
I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume).
That said, this is me speaking about htmx based on what I know about it. They may have some tricks up their sleeves these days to account for those issues. But those tricks would need JS.
Re: I'm betting on HTML
#56I had heard of almost none of these HTML elements, and that's such a shame, because they could seriously help put the "we need JavaScript for every gosh darn thing" ecosystem to an end (or at least return JS to what it was originally meant to be: a way to add some flair, some interactivity, some whatever, but not necessarily a replacement for all of your markup and a full-DOM manager). I'm starting to think my dream…
In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app.
They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you full power, works identical on all systems, etc.
In the end all these extra components just end up as bloat all browsers have to implement but no one uses.
Re: I'm betting on HTML
#57I didn't realize some of these elements existed. Neat! However, I think if we want an open/federated system to win, we need to make it compelling to normal people. That means making it fun and entertaining. I've found that no argument about freedom, privacy, or anything actually important will work.
Might seem elitist but we’ve seen what ‘normal people’ looks like on the internet and perhaps we do want places where there is a barrier to entry.
Re: I'm betting on HTML
#58Earlier quoted context omitted.
You'll be fine. If anything CSS is the one thing that's gotten easier in web dev. It might take some time but you'll be able to grok it for sure if you've dealt with old school CSS.
ehh... more organized / better? Sure. Easier? Well, even if you don't have to deal with legacy styling (which had moments of insanity, like floats, and other things which were fairly reasonable, like tables, br, b, i), there is so much new CSS to replace the old: variables, transforms, complex animations, using borders to make arrows and other visual content, in flow vs out of flow, container queries, view transition…
CSS is huge. I wish there was a way to shed all that dead skin. Only 5% of it is truly powerful. Most of it is never used.
Re: I'm betting on HTML
#59I'm personally betting on HTMX https://htmx.org/
I like htmx too for its simplicity but it’s actually antithetical to another key HN trope: responsiveness. Round-tripping to the server is much slower than client-side JS. It should be terrible for fast keyboard navigation, for instance. You might not notice on a server on localhost or on fast internet (which is very user-hostile to assume). That said, this is me speaking about htmx based on what I know about it. The…
If I had to architect a front end today, I'd start with HTMX. Very curious how far a HTMX+Deno stack could get you.
Re: I'm betting on HTML
#60Earlier quoted context omitted.
I use Flutter for some web apps, it works fine. It's good for web apps, not web sites, and compared to other desktop or mobile apps, there is literally no difference between rendering on a canvas to rendering on Qt or SwiftUI. People, in my experience, just get up in arms about the web that does not happen with other technologies.
> compared to other desktop or mobile apps, there is literally no difference between rendering on a canvas to rendering on Qt or SwiftUI. Except, you know, accessibility. > just get up in arms about the web that does not happen with other technologies. And for a good reason.
Flutter has a wild accessibility system that also exports DOM elements just for the aria labels.
This all breaks the browser’s in page search function though! Long standing bug with no fix yet.