I already knew this was going to be some minimal and ugly website that consciously rejects all modern UI conventions
Congratulations, it passed pagerank and was readable.
I'm betting on HTML
121–130 of 458 posts
Re: I'm betting on HTML
#122I 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…
> I had heard of almost none of these HTML elements I'm not disagreeing with the gist of your post, but come on, these elements have been around for ages. It's definitely on you to become acquainted with the basics before your HTML critic can be taken seriously ;) The post links to MDN (arguably the most useful short reference) but there is of course also WHATWG's HTML spec or, if that's too voluminous, SGML DTD form…
Most of them don't work properly and/or look terrible by default in all browsers.
So no-one uses them, so lots of people don't know about them.
Re: I'm betting on HTML
#123Great read and interactive demo. After a few years of dabbling with Flutter I just came back to the same conclusion: bet on HTML. Astro / Tailwind / Daisy UI / Alpine.js makes it lovely to build an HTML site with a lot of simple SSR and a little bit of client side reactivity peppered about. The result is simple sane HTML files that look and work great on desktop web browser and and mobile wrapped web view. My app is…
After trying a bunch of fancy frameworks and platforms I ended up doing exactly this - a static site with alpinejs and tailwind. It has been by far the best decision I've ever made. And the best thing is I'm confident any new dev will be able to pick up my 100 line build file and grok it in about 3min. No matter whether they're react, angular, PHP or python folks - it's dead simple and I love it.
Now move to the next level and have no build system.
Re: I'm betting on HTML
#124Earlier quoted context omitted.
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…
That's a common argument, but how often are you navigating around in a web app and you don't need data from the server? IME you do like 80+% of the time so "responsiveness" is false anyway, and when you don't you could get pretty far with basic http caching. And assuming high bandwidth is just as bad if not worse than assuming high latency, where typical web app dev platforms perform abysmially not to mention multipl…
This…
{{range .Query `SELECT id,name FROM contacts`}}
{{.name}}
{{end}}
Re: I'm betting on HTML
#125Earlier quoted context omitted.
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 fu…
JS does not 'just work'. This is why a lot of these custom components have bad touch interaction and no accessibility. Take the datepicker; the native mobile version works great, why annoy users with a custom component?
why annoy users with a custom component
Because a system you’re developing may have specialized modes. There’s no “today”, “yesterday” or “last week” or “q3” and other suitable shortcuts in standard date/period peekers. Another method is to use a text field which parses itself into a date or a period. E.g. “2-5” means (and/or expands into) 2023-08-02..2023-08-05. “May” means 2023-05-{01..31}. And so on.
My users always appreciated these buttons and modes because they were working in accounting and picking dates from that stupid standard picker was an ordeal. “ / / “ pattern is also annoying because you have to be precise with your cursor.
That said, ios picker is great, and it’s unnecessary to replace it. But (1) it’s not the only useful mode of operation, (2) it wasn’t always great on all platforms, and (3) html attributes usually suck at describing what patterns and use cases you want and compatibility among browsers is a minefield. I mean not only dates here, also numbers and ~numeric fields.
Re: I'm betting on HTML
#126Hey OP, I notice you're using Berkeley Mono, which is beautiful. But your website's CSS appears to be applying boldface on an already boldface font in the headers (despite the typeface name claiming to be 'Regular', it is actually bold; see the datasheet[1]), which is causing bad hinting. Consider changing your typeface file! [1]: https://cdn.berkeleygraphics.com/static/typefaces/berkeley-m...
Thank you! I was wondering why the font looked so wonky. It looks much better now.
Re: I'm betting on HTML
#127Earlier quoted context omitted.
> “LLMs will look at any .exe and be able to integrate with it immediately”. The LLM will look at any .exe and determine if it halts.
> The LLM will look at any .exe and determine if it halts. At that point you'd need an AGI that can figure out something we can't. Edit: but yeah, sarcasm. Nowadays I can't even tell sometimes.
I believe it was a positive sarcasm in gp.
Re: I'm betting on HTML
#128I'm personally betting on HTMX https://htmx.org/
I also like htmx. But one day someone pointed me to unpoly, which I find better. So I’ll spread the word here: https://unpoly.com/
Re: I'm betting on HTML
#129Earlier quoted context omitted.
I thought was semantic ("emphasis") and is stylistic ("italics")? And last I heard (when came out) you weren't supposed to use anymore because it's bad form to use HTML for styling! Much like .
Yes, that was the mantra some 15–20 years ago. Then HTML 5 came out, in which was indeed obsoleted, but / / weren't and instead got a semantic meaning. (A semantic meaning which, admittedly, is subtle, borderline esoteric, so it's very rarely used as intended.)
Made me read https://www.w3.org/International/questions/qa-b-and-i-tags
I think that at this point I can keep my usual habit of avoiding them completely.
Re: I'm betting on HTML
#130Earlier quoted context omitted.
> “LLMs will look at any .exe and be able to integrate with it immediately”. The LLM will look at any .exe and determine if it halts.
> The LLM will look at any .exe and determine if it halts. At that point you'd need an AGI that can figure out something we can't. Edit: but yeah, sarcasm. Nowadays I can't even tell sometimes.
I am 100% sure that parent poster was being sarcastic at the hype around LLMs and how many think they can solve everything, even if said thing is impossible to do, e.g. the halting problem.
Do note that the halting problem is fundamentally true, no AGI will realize some new way around, unless are mathematics are flawed to the core.