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

381–390 of 551 posts

Re: HTML First

#381

Post by thinkingemote »

csbartus wrote: post #168
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…

Agree. I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities. Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps. With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the f…

All of the technologies you used previously were considered "finally fully fledged" until they weren't!

We will be doing something different in a couple of years and saying that the stuff we do now is out of date and the new stuff is home. It's always been this way. We are tech nomads finding ourselves new homes as and when we move on.

Re: HTML First

#382

Post by docmars »

professorsnep wrote: post #377
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…

For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project. [1]: https://docs.astro.build/

Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!

Re: HTML First

#383

Post by joshghent »

The author raises some interesting points.

But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine.

What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap.

I’ve never understood these html purist arguments. As if React/Vue/Angular are desecrating this pure text language.

There are other issues of far greater importance - accessibility, multi-language, browser consistency, sane defaults and easy tooling.

Re: HTML First

#384

Post by docmars »

tonyennis wrote: post #99
philihp wrote: post #97

Earlier quoted context omitted.

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…

Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo

Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?

Re: HTML First

#385

Post by Yodel0914 »

6031769 wrote: post #352
Yodel0914 wrote: post #349

Earlier quoted context omitted.

For smallish or personal sites I'm 100% on board. For a large enterprise-y app, which in a previous era would have been a rich client deployable, the benefits of these hulking UI frameworks outweighs the costs.

To the devs perhaps. To the users? Not so much. So many sites these days are so bloated and slow as to be unusable. Those of us devs who chose the other approach have to work harder no doubt but our users are much happier. Isn't that the goal, after all?

Surely that depends on your users.

My current users value speed of feature release over almost anything else, because the system needs to adapt to their rapidly changing business rules.

In my previous job, correctness was the most highly valued attribute, followed by adherence to consistent design across the org (which was large, and produced many sites that a user would navigate between all-but unknowingly).

In either case, if I'd gone on a HTML purity rampage, I would not have been helping my users in any meaningful way.

Re: HTML First

#386

Post by docmars »

thinkingemote wrote: post #381
csbartus wrote: post #168

Earlier quoted context omitted.

Agree. I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities. Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps. With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the f…

All of the technologies you used previously were considered "finally fully fledged" until they weren't! We will be doing something different in a couple of years and saying that the stuff we do now is out of date and the new stuff is home. It's always been this way. We are tech nomads finding ourselves new homes as and when we move on.

Using PHP and other tools/frameworks that tightly coupled the frontend to the backend codebase made life miserable. While I was excited to get into web development back when these technologies were popular, they were anything but pleasant to use.

With the introduction of Angular 1.x and eventually React, Vue, and Svelte -- creating web apps finally felt productive, easy to debug, and easy to ship. Wiring up interactions finally felt intuitive. No more jQuery code colliding with itself as you struggle to organize your project and cobble together a bunch of poorly maintained "component" libraries and pray they work together without obvious user-facing bugs on your site or app.

Or worse: on a team of engineers.

I won't lie, learning how early build systems worked was a pain, but the curve was completely worth it, and I wouldn't change a thing. Today, using tools like Vite with their default project templates is almost too easy, and you can hit the ground running in no time.

Publishing to Vercel, Netlify, and other modern hosting stacks is a breeze, and they all support direct tie-ins with every popular package & build system.

Re: HTML First

#387

Post by docmars »

squidbeak wrote: post #180
csbartus wrote: post #168

Earlier quoted context omitted.

Agree. I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities. Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps. With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the f…

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

The line is very blurry, and the moment you'd like dynamic, interactive content embedded within that static content is when it's time to reach for a view library like React.

At that point, I'm just going to start the project with React / Vue / Svelte every time because almost 100% of the time, I realize I need to support the features they offer that raw HTML/CSS cannot, or if they do, are very poorly implemented by browsers, hitting limitations with them that become frustrating and prevent you from achieving the scope you're aiming for.

Using any of those three libraries/frameworks is painless, and I can get a project going rapidly and with high confidence that I can support any functionality, interaction, animation, content, routing, and other common web problems, with great ease.

Re: HTML First

#388

Post by geuis »

I'm on board with this conceptually. Most of the independent sites I build I still do this.

But some of the things being spouted on this site are junk:

    
      Click Me
No. Absolutely not. Don't ever do this.

This is an unmaintainable mess.

I started messing with early web dev stuff in the late 90's. It took over a decade to finally get enough momentum to move people away from this kind of crap.

I'm going to lovingly refer back to https://www.csszengarden.com/. Separation of concerns is a good thing and should be used as much as possible.

Re: HTML First

#389

Post by docmars »

I love how many folks here seem to think JavaScript (and its popular libraries / frameworks) are somehow threatening to the web. This is like saying people should write native user interfaces for iOS and Android, "but no, not with Swift or Java" (respectively).

All the templating, but without the language or libraries to support its interactivity, navigation, data calls, calculations, you name it.

It's rather quite silly.

Re: HTML First

#390

Post by rndmize »

n2d4 wrote: post #326
RoddaWallPro wrote: post #275

Earlier quoted context omitted.

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

Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.

This is pretty much correct, though I feel there's some finer points depending on the number of options (5? 10? 50?) and the expected number of values chosen (2? 4? 10?).

Checkboxes are a good choice for a small number of options: https://m3.material.io/components/chips/overview . I'd say past a dozen options though this starts to become unwieldy.

Tag-style multiselects are fairly common (see https://react-select.com/home for an example). These are good where the number of values a user is expected to have selected is small (less than five imo) but the number of options is large enough to make checkboxes impractical. If you're expecting a higher number of things to be selected, you could have the option list stay open after an option is clicked, so they user doesn't have to reopen it each time they want to add an option (and, in fact, the "Animation" example does precisely that).

Two column designs ( https://crlcu.github.io/multiselect/examples/search.html ) have mostly fallen out of favor, though I feel they still have their uses for larger lists with large numbers of selected values.

Post reply on HN