Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTML First

html-first.com

Post reply on HN
Print view View original

501–510 of 551 posts

Re: HTML First

#501

Post by justsomehnguy »

josephg wrote: post #316
zlg_codes wrote: post #292

Earlier quoted context omitted.

I'm adding context to this because you're only telling part of the story: self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax. Void elements lacking the need for a closing…

You can view HTML as a weird, quirky version of XHTML if you want. But XHTML lost the war. Browsers are HTML5 engines, not XHTML engines. And if you're writing HTML, the browser considers to just be a weird way to write . The slash is non-significant. So confusingly is not equivalent to . The problem I have with self-closing tags is that I've met so many web developers throughout my career who think that browsers und…

Offtopic but not: https://daringfireball.net/projects/markdown/syntax#p

Re: HTML First

#502

Post by MrJohz »

chii wrote: post #479
MrJohz wrote: post #463

Earlier quoted context omitted.

I think the point they're making is that you'd have the same problems with developers working HTML-first. Accessibility does not simply come for free in either situation, you need to make sure it's present. Choosing, for example, whether to use a div with a click handler, or a proper button, is a decision you need to make regardless of whether or not you're using a framework. So it seems incorrect to say that you los…

> developers who didn't understand the web platform well enough to design proper accessible controls. And i actually think that it is _better_ for a developer not to have to do their own accessibility controls, but delegate this problem to the component framework. They have to know about the problem, but not have to spend cognitive budget thinking about it while they compose their UI from framework components - this…

But you're using the same component framework regardless of whether you use React or not: it's the same underlying elements that you decide between, and the same process of configuring then correctly to be accessible.

Re: HTML First

#505

Post by _heimdall »

robertoandred wrote: post #291
David-Guillot wrote: post #229

Earlier quoted context omitted.

Cost. React will require you to hire a React dev to handle all the complexity. htmx will be mastered by your "back-end" devs (who actually are web devs) in less than a week.

What kind of web dev can't handle React? Meanwhile, htmx uses clunky, non-standard attributes that rely on logic and templates that are split up in a million different places. Plus it requires a context switch to do anything client side.

Don't underestimate the learning commitment it takes to learn react. Learning the basics of react and its component architecture is one thing, learning all the tricks and gotchas related to hooks, accidental re-renders, accidental no-renders, etc takes time.

Throw in the usual pile of libraries used with any larger react app and it can easily take months to really get moving.

Re: HTML First

#506

Post by darkerside »

whstl wrote: post #414
docmars wrote: post #384

Earlier quoted context omitted.

Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?

I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash. Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatibl…

Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.

Re: HTML First

#507

Post by _heimdall »

oliyoung wrote: post #339

` ` Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics. This is a terrible idea.

This is actually the most interesting one to me, not because I prefer it but because I want to see what others think.

I've been told by quite a few Tailwind users that they much prefer it because it bring styling and markup into the same place. In their view markup and styling are so linked that splitting the code up is painful to follow and maintain. This onclick example follows the exact same argument, that the click handler is so tied to the markup that it should be inline.

Re: HTML First

#508

Post by darkerside »

MrJohz wrote: post #458
xg15 wrote: post #329

Earlier quoted context omitted.

What would be the specific difference between all of those? For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built i…

* For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling. * For adding a…

Thank you for this perspective. I despise when a website makes me pick by birthday in a typical date picker.

Maybe we are lacking vocabulary for these different types of date widgets. I've never heard anyone take about an historical date picker as a separate concept.

Re: HTML First

#509

Post by H12 »

codeptualize wrote: post #89

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I…

Counterpoint: The article is titled "HTML First" not "HTML Only"

Admittedly I had the same reaction you did as I was reading the article. All I could think was how poorly these approaches would scale when the need arose for even modest ly complex state management.

While the body of the article doesn't address this, IMO the title does. I think it's generally good advice to suggest only reaching for the tools intended for complex environments when they become necessary, not before.

Re: HTML First

#510

Post by fao_ »

n2d4 wrote: post #326
RoddaWallPro wrote: post #275

Earlier quoted context omitted.

"shift/control-clicking to get multiple things is a flat no-go from a UX perspective" - Do you mean that this is NOT how you should do multiselects? If that is what you mean, then how _do_ you do them? If I have a list of items and I want to select 10 or 15 of them in a row, I currently don't know of a better UI to do that with than shift+click.

Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.

> Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking.

My boomer parents do. Most users I've seen in the wild do.

Post reply on HN