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

311–320 of 551 posts

Re: HTML First

#311

Post by codeptualize »

zilti wrote: post #298
codeptualize wrote: post #167

Earlier quoted context omitted.

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.

If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced..

Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.

The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.

Just like the original article, you might want to test your assumptions a bit more.

Re: HTML First

#312

Post by TheCycoONE »

Jiocus wrote: post #250
sawmurai wrote: post #157

Earlier quoted context omitted.

I was about to comment that but luckily stopped to search if someone else already did. In our company this is taken pretty seriously and would trigger some raised eyebrows from the security department :)

While I agree that the article overlooks the security aspects of inline scripting[1], we do have content security policy[2] at our disposal using CSP nonce [3] and hash [4] keywords to allow inline script and CSS. On the other hand, the articles ease-of-use argument of inlining doesn't really hold up after factoring in CSP. In my opinion, it's consideration as unsafe isn't intended literally. It has more to do with:…

Neither of those work for the inline event handlers proposed by this article. You need unsafe-inline or unsafe-hashes.

Re: HTML First

#313

Post by LudwigNagasena »

zlg_codes wrote: post #270
LudwigNagasena wrote: post #52

It is so much easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveraging the extreme simplicity” effort wholly misguided. It’s neither “enjoyable” nor “seamless” to manually synchronise the backend, the frontend logic and the DOM of your app without frameworks. And maybe the trite talking point of helping young developers by sendin…

> nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development. That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing. ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. Anyway, View Source is a…

> That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing.

But they are a thing now.

> ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those.

An average self-taught hacker can afford YouTube. That’s why I explicitly mentioned talks and not conferences per se.

> Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site.

Opening up source code is a choice. And if a creator wants to open-source their app, I would rather look at it in GitLab rather than in production.

Re: HTML First

#314

Post by contradictioned »

RoddaWallPro wrote: post #275
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…

"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.

Drag and drop? At least that’s only using a pointer device without modifier key…

Re: HTML First

#316

Post by josephg »

zlg_codes wrote: post #292
josephg wrote: post #215

Earlier quoted context omitted.

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…

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 understand self closing tags. I used to be one of them! And that will almost always, but not always work out fine:

- React / JSX supports self closing tags. So do a lot of other web frameworks.

- Void elements ignore the /. (And you don't need to close void tags anyway). So you can write input, img, br, etc tags however you want.

- HTML5 will auto-insert missing closing tags when it needs them. Eg, will render as you expect because the browser will automatically close the span when you close the div. (!)

But it'll confuse you in weird ways. Like - which the browser dangerously interprets as an open script tag. Subsequent text is interpreted as javascript!

I think its good practice to be clear in all source files whether you're writing XHTML (eg in .jsx) or writing real, god fearing HTML. And then never use self closing tags in HTML. Sooner or later, someone will think they matter and you'll get bugs.

Re: HTML First

#317

Post by iFreilicht »

zlg_codes wrote: post #245
gemstones wrote: post #29

Can the people that want this HTML-first world style it to look the ways they want themselves? My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS. Why listen to UX thoughts from a population who are scared of UX?

To be fair, most UX "experts" are too busy chasing interfaces that are "inclusive", i.e. built for toddlers. Show me a powerful program with a "good" UI by modern standards and I'll show you a mess. VS Code is a prime example.

Interesting example. Why would you say VSCode is a mess? I feel like it's not in line with the current UX Zeitgeist I assume you're referring to (touch-first, wasteful whitespace, manipulative patterns, reduced functionality) at all. It provides multiple layers of access to functionality that allow the user to choose their trade-off between discoverability and speed. The UI is compact with very little padding and shows a lot of information at once. No affordances to touch input are made either.

Another powerful tool that is built on modern UX principles would be Fusion 360. In my experience, it makes me as a user much more powerful and actually provides more functionality in a more productive manner than its competitors and predecessor. Would be interested in you explaining how that UI is a mess as well.

Re: HTML First

#319

Post by jasonwatkinspdx »

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,…

I think this is a rational strategy. They aren't changing concepts just randomly for that alone. As we learn problems with the last approach we try something new to address it. If you're starting a new app green field this is an ideal time to try to shed some baggage.

Re: HTML First

#320

Post by moritzwarhier »

alethiophile wrote: post #276
moritzwarhier wrote: post #49

Earlier quoted context omitted.

I once built a project-tailored combobox using Alpine.js - this is about where it breaks down. It worked, it was a lot of fun to write because it went really fast, even with some bells and whistles. Whole thing was my escape hatch when datalist attribute didn't work. It also worked well. Alpine JS feels like a simpler version of Vue 2 without a build step and without any of the complex or confusing stuff (and of cour…

Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data. It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; chang…

Should have mentioned that I made a generic Blade component from it (it was a Laravel project)

Copying still happened, take that as you will - in this case that was the problem :) Might be my implementation was not generic enough, but tbh the colleague was not especially proficient at JS. We had a productive conversation about this, but this particular project ultimately was lost by my former employer. The reason was not this autocomplete component though :)

Post reply on HN