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

271–280 of 551 posts

Re: HTML First

#271

Post by gemstones »

usrbinbash wrote: post #60
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?

I am very happily listening to UX thoughts from people who specialize in UX. What I am decidedly NOT happy with, is the frontend using as much, or even more, internal logic, magic, and build steps as the actual business logic. To put this another way: I will happily listen to an interior designer on his thoughts about the color of the drapes. But if he tells me that this color means he has to bring his own crew of st…

That applies to backends equally, but you don’t get thinkpieces on how that makes it a great idea for frontend devs to avoid all those silly DTOs and design patterns that complicate the server code.

Re: HTML First

#272

Post by ceuk »

andybak wrote: post #234
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…

The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem. The small projects are where the people I care about are struggling.

Big project =/= Big company

e.g. WhatsApp back before the acquisition

Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.

Re: HTML First

#273

Post by divbzero »

c-fe wrote: post #246
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…

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…

This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.

Re: HTML First

#274

Post by xgb84j »

josephg wrote: post #210
squidbeak wrote: post #173

Earlier quoted context omitted.

Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.

I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on. The big projects are of course important. But even chrome needs a simple little website with a download link.

That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.

Re: HTML First

#275

Post by RoddaWallPro »

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.

Re: HTML First

#276

Post by alethiophile »

moritzwarhier wrote: post #49
listenallyall wrote: post #16

Earlier quoted context omitted.

The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.

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; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.

Re: HTML First

#277

Post by zlg_codes »

dartos wrote: post #73
treyd wrote: post #56

Earlier quoted context omitted.

My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as a web app.

Why? The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far. It’s not good for everything all the time, but it is good for most UI focused software most of the time.

Is there no appreciation for using the right tool for the job?

When you build an app on Electron, you're forcing the client to run another browser, alongside whatever other browsers they're running. Due to the complexity of the Web, running a browser now takes hundreds of megabytes of RAM, sometimes a gig or two. Now imagine you have 8 different Electron apps you use. You have the system resource use of 8 separate browsers now. Congrats.

Secondly, there's no integration between Web apps and the OS. Only recently did things like light and dark mode get OS-level support, so there's that much, but long story short, Web apps don't integrate well with the system. They tend to be shipped in containers, too, so while it may be "good security" it results in a worse runtime environment and uses more resources.

The Web is a document platform, first and foremost. The building of V8 and Node.js, the myriad frameworks, etc, are the result of companies trying to turn an existing protocol into a moneymaker. Tim Berners Lee never intended the Web to be an application platform or a vector for DRM. For-profit interests created all of that extra complexity, and took over standards committees to push their ideas through.

Web apps work best when they take advantage of some of the Web's strengths. If your program needs to talk on the network a lot and it's already working with HTML, then yes maybe it should be a webapp.

The problem is everyone's ignoring the complexity, resource use, and tangled knot of abstraction on the client's end. It's "not a big deal", until it is, then we'll go back to rediscovering how easy native development is with a smart enough Makefile. All the major UI toolkits are cross-platform, there's little excuse.

Re: HTML First

#278

Post by wayfinder »

Writing your code in a way that makes sense to someone else is a skill.

If someone writes the bonkers code in the article’s bad examples, I guarantee their “HTML-first” code will be just as bad.

Re: HTML First

#279

Post by ckolkey »

mmcnl wrote: post #264
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…

The default date picker is laughable. For example there is no way to control the format in which the date is displayed.

Unless I'm mistaken, it's shown in a format localised to the user, so... i'd much rather you keep your hands off that, and I'll enjoy my DD.MM.YYYY

Re: HTML First

#280

Post by kevlened »

zlg_codes wrote: post #247
gemstones wrote: post #85

Earlier quoted context omitted.

I’ve met enough people that aren’t like you that your lived experience, real as it may be, doesn’t really change my opinion much. For every one of you who isn’t scared of CSS there are like 40 people into HTMX that make bad UXs even by the standards of internal company tooling.

What literature exists on UI and UX that isn't condescending or clueless in tone? Interfaces are as unique as humans are. There's a reason we have emacs, vim, and Notepad.

Refactoring UI fits those constraints. While it's by the creators of tailwind, it doesn't make assumptions about the css you use to achieve your desired UI.

https://www.refactoringui.com/

Post reply on HN