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

221–230 of 551 posts

Re: HTML First

#221

Post by codeptualize »

tonyennis wrote: post #213
pech0rin wrote: post #196

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css? The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is…

"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.

> "Not that complex"

Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages.

Things don't need to get very complex to benefit from frameworks and tooling.

Re: HTML First

#222

Post by MrJohz »

avidphantasm wrote: post #208
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…

Even if this isn’t always practical for larger projects today, I would argue that this should “ultimately” be the goal—-at some point the “standard” browser runtime should be expressive enough to not require lots of tooling to make most apps.

I'm not sure that's always the case — we don't expect assembly to be a high-level language after all! The more specific and batteries-included the browser becomes, the harder it is to go off the beaten track. My standard example here is date pickers — theoretically it's just a simple component, and yet there is no one-size-fits-all option. What works for booking an appointment won't work as well for putting in a date of birth. What works for a date of birth won't work if you're trying to book a set of nights in a hotel. You might want to include prices for individual days directly in the date picker. You might want to show which days are valid and which aren't. You might want to show several months, you might want to show just a week.

I don't necessarily disagree that more components in browsers is a bad thing (I've been very happy to use the new modal element, for example), but I think the browser is working better right now as a lower-level (albeit still fairly high-level) platform that allows people to build a variety of documents and applications on top.

Re: HTML First

#223

Post by fsckboy »

wheelerof4te wrote: post #184
jaapbadlands wrote: post #156

Earlier quoted context omitted.

No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the i…

"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions." Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

I love maintaining and cleaning up code (I will insist on cleaning up according to my taste even if it already works fine in production, just like when I carve the turkey I eat some crispy and fatty pieces hot from the oven) It takes a great weight off my short term memory and ADD that I know that the code already worked, so if it stops working, I did it, recently.

But here's the thing, hot-shot devs, and hot-shot dev wannabes look down on maintenance; and humans are social creatures, me included. So I'm not going to do a job for you that you look down on, unless you carry me in (and out) on a sedan chair.

Same for writing doc, I'm good at it and enoy it, but there's no pleasure in doing something that other people don't really value.

Re: HTML First

#224

Post by Jtsummers »

recursivedoubts wrote: post #190
Jtsummers wrote: post #23

This one confuses me: > Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious? [0] https://hyperscript.org

yeah, kinda. source: I'm the creator of hyperscript.

I'm not saying hyperscript isn't serious (I have no opinion on it at all actually). I'm saying the claim "avoid DSLs" followed by an example using a DSL is a sign of unseriousness on the part of the author of HTML First.

Six principles and one of them is presented with an example that blatantly violates that same principle. I could see a mistake like this slipping through if there were many more principles and examples, but this is a relatively short piece for such an error to slip in.

Re: HTML First

#225

Post by zlg_codes »

The Web was never meant to have an interactive scripting layer. It got there by accident. Microsoft's XmlHttpRequest paved the way for page loads without page loads, and it became an accidental standard due to how it worked.

We can go back and replace Javascript with whatever we want, or expand the element to be able to handle more than one language type.

Not really sympathetic of big web apps having to adjust to such an environment. I already don't consider them truly part of the web. They're something you can make with the Web but don't actually represent the values or accessibility that the basic Web already provides.

I only use JS when absolutely required.

Re: HTML First

#226

Post by lol768 »

mro_name wrote: post #136

doesn't the inline JS (onlick="this.classList.add('green')") harm/complicate CSP headers?

Yes, it all flies in the face of accepted strict Content-Security-Policy best practice.

Re: HTML First

#228

Post by nathanfig »

varun_ch wrote: post #34

While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..

Deno Fresh uses Twind, which avoids the build step: https://twind.dev/

But IIRC it doesn't offer quite everything full Tailwind does. In general I was frustrated with Fresh for not being up-front about the fact that it is largely built on Preact and Twind, and you must buy into those libraries first.

Re: HTML First

#229

Post by David-Guillot »

robertoandred wrote: post #197
max_ wrote: post #144

Earlier quoted context omitted.

Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.

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.

Re: HTML First

#230

Post by zlg_codes »

pech0rin wrote: post #196

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css? The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is…

I'm sorry, but the majority of the change has been inflicted by for-profit outfits who EEE'd the W3C to get what they wanted. None of us asked for a Javascript-dominated Web where you download megabytes of code before you see the first page.

You make it better by separating concerns or finding better ways to do the same thing.

By this point, QUIC and HTTP should fork instead of QUIC insisting on taking over HTTP.

We can make this space better by pushing out complex "web" applications to their own protocol they can fuck up on their own instead of pushing the system requirements of a browser up every year.

Post reply on HN