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

401–410 of 551 posts

Re: HTML First

#401

Post by sensanaty »

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…

The default datepickers in browsers are not feature-rich at all though. They're fine for extremely basic "pick a date" type of usecases, but as soon as you want to do anything slightly complex like picking a range, a date & specific time in one or having it be interactive in some other way like Google Flights showing you a range of prices alongside the date etc., you have to create your own datepicker component (or use an already built one).

Re: HTML First

#402

Post by docmars »

zztop44 wrote: post #284
squidbeak wrote: post #180

Earlier quoted context omitted.

Perhaps web publishing shouldn't be presupposed to be 'software development'?

But very often it is software development. And there isn’t always some bright line between them. Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications. Let’s use software development tools, rather than web publishing tools, to develop that software.

It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is.

As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based on the features you need vs. the market share of older versions.

People (and teams) choose web development for the lower barrier to entry, and as a platform, browsers get products most of the way to their goals, and fast.

Re: HTML First

#403

Post by iopq »

philihp wrote: post #97
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…

For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR. I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my…

and this is why that example doesn't work - you find out onclick doesn't work where you thought it would work

whereas you can addEventListener anywhere you want

Re: HTML First

#404

Post by fiddlerwoaroof »

DangitBobby wrote: post #370
fiddlerwoaroof wrote: post #324

Earlier quoted context omitted.

Yeah, shift/control-click is a longstanding workflow for multiselect and macOS, Linux and windows all support it with various platform-specific subtleties. The worst part of the web is losing all these sorts of features because some web designer thinks they’re a “bad UX”

Present a form with a 25 item native multiselect to 10 of your non-prgrammer family members. Ask them to perform two tasks: - Select 5 non-adjacent items - Select 5 adjacent items. Report back with success rates.

The nice thing about native behaviors is you only have to teach them once. Custom behaviors per application make it harder for people to develop a model of how their computer works because you have to learn a new interaction model per application. I’m pretty anti the notion that UX is intuitive in any sense: all human-computer interaction is learned at some point and we should focus more on educating people how to do tasks like this than pursuing some lowest-common denominator concept of “intuitiveness” or “discoverability”.

Anyways, my favorite multiselect paradigm is the old windows one with two list boxes side by side and buttons in between.

Re: HTML First

#405

Post by JRJurman »

A lot of these points are great, but the examples here don't help for building more complex components or pieces, that could contribute to a larger application...

If people are looking for a way to build native web-components using HTML-First principles, I've been working on a library to do just that!

https://tram-one.io/tram-lite/

Re: HTML First

#406

Post by docmars »

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.

Better than maintaining vanilla JS applications that reinvented React for no d*mn reason. At least there's a massive pool of engineers who could jump into an old project and work on it right away, rather than wading through some clever engineer's buggy attempt at a view state management system.

Popular backend templating systems face the same problem with possible sunsetting and decay of collective knowledge over time.

React is a great investment, and is here to stay for a long time because its team (and community) are massive, and are keeping pace with newer libraries/frameworks that are in a lot of ways doing things better. React's market share has hardly been touched by Vue, Svelte, Solid, etc. and less so by HTMX and other new attempts at un-frameworking the web.

Re: HTML First

#407

Post by docmars »

Xeamek wrote: post #331
pault wrote: post #201

Earlier quoted context omitted.

The chances of this happening before your project is obsolete are pretty slim. Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily usi…

>React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens. React might be 10 years old, but it changed like 5 times during that time. Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?). It's almost disingenuous to ignore tha…

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 quite mature. Their approach with server components is an optimization path that uses concepts/patterns from already popular server-side languages and frameworks + templating, and blends them seamlessly with client-side development, giving engineers the best of many worlds.

This was a natural evolution from NextJS which popularized this way of using React, and it's giving engineers more choices in how they build + optimize their apps.

Re: HTML First

#408

Post by hoosieree »

arcanemachiner wrote: post #350
ckolkey wrote: post #279

Earlier quoted context omitted.

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

ISO-style timestamps are the only only one that makes any sense. YYYY-MM-DD or GTFO.

no need to fight over it, compromise is both elegant and simple:

    YMYY-YD-DM

Re: HTML First

#409

Post by listenallyall »

xgb84j wrote: post #266
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.

The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months. For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody el…

> a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals

The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.

Post reply on HN