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

531–540 of 551 posts

Re: HTML First

#531

Post by andai »

andai wrote: post #86

The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites . For web apps , at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.) I used to be really big on th…

Edit: There is a proposal to extend JavaScript with type annotations, which would allow ("a reasonably large subset") of TypeScript to run directly in the browser. Yay!

https://github.com/tc39/proposal-type-annotations

Re: HTML First

#532

Post by jaapbadlands »

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'll enjoy that a hell of a lot more than I'll enjoy doing the same thing on bullshit vanilla code I scratched together myself under the pressure of a deadline, lol.

Re: HTML First

#533

Post by Karrot_Kream »

marcus_holmes wrote: post #478
Karrot_Kream wrote: post #466

Earlier quoted context omitted.

> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry. But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with…

Yeah, I think so. If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience). Our online lives would be a lot better if the p…

> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).

What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?

> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.

I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.

Re: HTML First

#534

Post by listenallyall »

_gabe_ wrote: post #530
listenallyall wrote: post #467

Earlier quoted context omitted.

> Compare that to 100-200ms of latency between a faraway server A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to m…

> almost real-time connectivity with a database If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page. All th…

> problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails

Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.

> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page

You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.

Re: HTML First

#535

Post by marcus_holmes »

Karrot_Kream wrote: post #533
marcus_holmes wrote: post #478

Earlier quoted context omitted.

Yeah, I think so. If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience). Our online lives would be a lot better if the p…

> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience). What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute? > Our online lives would be a lot better if the product folks listened to the tech folks a bit more. I mean, ac…

From my experience I don't think product and management folks care much about the user experience either; it seems to be mostly ego and dick-measuring.

My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user is not going to see them; they're going to switch away from the app after 10s of staring at a blank page waiting for the JS to download.

Seen too many "perfect" designs on a laptop monitor right next to the router in the dev studio fail completely in the wild. Every Kb matters.

Re: HTML First

#536

Post by Karrot_Kream »

marcus_holmes wrote: post #535
Karrot_Kream wrote: post #533

Earlier quoted context omitted.

> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience). What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute? > Our online lives would be a lot better if the product folks listened to the tech folks a bit more. I mean, ac…

From my experience I don't think product and management folks care much about the user experience either; it seems to be mostly ego and dick-measuring. My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user i…

Unless you have anything more than anecdotes and feelings to contribute to this discussion, I don't think there's anything more to discuss. Data makes a more convincing argument for such bold claims, especially when a minority of practitioners claims that their way of doing things is more correct than a much larger majority. I will say, from your maligning of "product and management folks" to your anecdotally-driven interest in page weight, its like every dev stereotype ever.

Re: HTML First

#537

Post by docmars »

nightowl_games wrote: post #445
docmars wrote: post #373

Earlier quoted context omitted.

One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board. This is why I reach for a view library like React, Vue, or…

Cant you just use vanilla JavaScript at that point?

Not in a way that scales, if you need it. It all depends on the problems you're trying to solve, and if it gets to a point where I feel like I'm reinventing any of the popular frameworks, I'm just going to use them instead.

Re: HTML First

#538

Post by docmars »

skydhash wrote: post #442
docmars wrote: post #407

Earlier quoted context omitted.

React's first flavor (class-based components) are fully backwards compatible with today's React versions. It doesn't seem odd to me that a popular library identifies its pain points and improves its APIs & patterns over time. That's the beauty of open source software with large communities guiding their growth. Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already qu…

> This was a natural evolution from NextJS It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.

No you're right, but the benefit is: a more consistent dev experience across client and server-side. Being able to write the same components in either environment for specific optimization purposes (static rendering vs. interactions) is a huge plus. It reduces the cognitive overhead of context switching between languages and technologies.

Re: HTML First

#539

Post by wheresmycraisin »

RunSet wrote: post #515
wheresmycraisin wrote: post #323

Earlier quoted context omitted.

> 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. Not everything has be a Large Enterprise Application.

Perhaps, but can you name even one successful, big, bloated institutional project that operates primarily on the principles of HTML First?

How is that a response to "Not everything has be a Large Enterprise Application."? If I said "not everything has to be blue" would you reply "what's one thing that's blue?"?

Re: HTML First

#540

Post by zlg_codes »

alib wrote: post #523
zlg_codes wrote: post #459

Earlier quoted context omitted.

What makes it more accessible? I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.

That’s exactly it. With native buttons and links you get all the accessibility for free. If you attach events to non-interactive elements, you have to do all the accessibility work yourself. In a custom interface, a button outside a form is perfectly valid and the best choice for the above reason.

Yeah, no. If the only reason to do it is to accommodate poorly made accessibility software then count me out. That's bad reasoning and the 'correct' elements will change with the accessibility software.

Logically it should be the reverse. Screenreaders can learn how to detect all clickable elements instead of shoehorning a form control element into places.

Post reply on HN