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

291–300 of 551 posts

Re: HTML First

#291

Post by robertoandred »

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

Earlier quoted context omitted.

What's the reason to use a framework like HTMX instead of React?

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.

Re: HTML First

#292

Post by zlg_codes »

josephg wrote: post #215
assimpleaspossi wrote: post #194

Earlier quoted context omitted.

note that the tag does not use and does not need a closing slash and never has in any HTML specification. https://html.spec.whatwg.org/dev/embedded-content.html#the-i...

Yep. It’s one of a handful of void elements along with and . Also using a slash to self close a tag is not part of the html spec and it never has been part of the spec. The browser doesn’t know what that means on any tag. If you write the browser ignores the slash and thinks you still haven’t closed your Div.

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 tag or closing slash is one of the weird edge cases in HTML. While it's not in the HTML spec, it may still be seen in the wild in XML and XHTML documents and is not universally bad or unsupported.

Re: HTML First

#293

Post by robertoandred »

max_ wrote: post #241
robertoandred wrote: post #197

Earlier quoted context omitted.

What's the reason to use a framework like HTMX instead of React?

It reduces development complexity. - No complex build set-up (just link the script & use it) - Less congitive load when reading the code. Especially if it's not yours. - Very decent learning curve.

But all it is is fancier fetch()s. It can't remotely approach the functionality of React, so it just shifts any complexity to different places.

Re: HTML First

#295

Post by andirk »

rndmize wrote: post #233

I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react. My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use do we get a datepicker across browsers? (Looks like…

from the rest of the discussion, `input` element is infamously shitty for having vastly different ways of interacting with it, whereas most other HTML elements have one signature.

Re: HTML First

#296

Post by 3c6bYDXLMj »

ssss11 wrote: post #265
c-fe wrote: post #246

Earlier quoted context omitted.

Quick thought regarding date pickers, specifically: > Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1…

Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.

[dead]

Re: HTML First

#297

Post by mekoka »

ativzzz wrote: post #231
jasonwatkinspdx wrote: post #216

Earlier quoted context omitted.

37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?

To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work They believe this now,…

People buy into ideas and once they've paid the price, they dislike when that investment is challenged with new information. The resistance that I see in these thread to the idea that going back to HTML might be enough, to me looks very much like that.

Basecamp (formerly 37signals) has a track record of challenging the status quo, whether in business or engineering practices and to actually be fair, they're not changing their front-end philosophy on a whim or to simply follow a fad. They're trying to solve real problems. In the past, their flagship product served as proof that exposed many established counter-advices as merely baseless beliefs. Over the years, they've demonstrated how many "bad ideas" could actually work better for you, once you allow yourself to become a bit more pragmatic.

They might not be BIG, but they're also not small. Imo, what they say and do engineering-wise tends to matter much more to average developers than what Facebook or Google might recommend.

I think the question stands, is Basecamp a good enough example?

Re: HTML First

#298

Post by zilti »

codeptualize wrote: post #167
xgb84j wrote: post #160

Earlier quoted context omitted.

Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects. Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all. I personally…

This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.

You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.

Re: HTML First

#299

Post by meowtimemania »

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…

Most anything built with php or traditional SSR pages follows these concepts to some extent.

Re: HTML First

#300

Post by hollowturtle »

I strongly believe that no one would hate or love to hate the build step if we didn’t have to mess around with so many unmaintanable configs, dependencies and pipelines of translations like typescript -> js with commonjs or es modules and so on. Still, for me, which ever code I write I want it to be compiled/translated by a machine, that given a “browserlist” knows better than me how to output code that works for the most system around. And that’s especially true if you have a successful product with a lot of customers. I agree on rolling back most of the abstraction madness we built so far, but surely I can’t remember how to write es5 compatible code anymore, should be a no brainer for me. Lastly, I can’t disagree more on improving inclusion with “html first”, whatever approach you choose it’s still super hard to have a web app that has: perfect audit score, adpative ui for all screens, accessibility, print(! what id customers demand that each app page should be printable?) and more I can’t think of now. This job is hard, it’s not for everyone and going back to first principle won’t save us from hardwork anyways
Post reply on HN