HTML First • Hacker News Board

Re: HTML First

#491

Post by xigoi » Mon, Nov 13, 2023, 8:18 AM UTC

docmars wrote: post #373

al_borland wrote: post #368

Earlier quoted context omitted.

Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.

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…

Libraries like Vue allow you to easily add some interactivity to a site without converting it entirely. Why not do that?

Re: HTML First

#492

Post by zztop44 » Mon, Nov 13, 2023, 8:20 AM UTC

zlg_codes wrote: post #475

zztop44 wrote: post #307

Earlier quoted context omitted.

The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.

Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works. Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via and . Are you saying there are frameworks that tie HTML and CSS together into the same…

It’s quite a common pattern in modern frontend frameworks. Each component includes just the CSS required for that component (plus any global styles). At built time, the bundler will generate unique class names for each of the HTML elements in the component and output an optimized CSS bundle matching those unique class names.

It definitely adds extra complexity in the build step, and the resultant randomly generated class names aren’t very nice aesthetically.

However, this approach allows you to read and modify the CSS, HTML and JS that affect a component all in the same place, instead bouncing around between different files. It also avoids the problem of naming (and remembering) globally scoped CSS selectors, and generally results in less CSS over the wire.

Re: HTML First

#493

Post by hhsectech » Mon, Nov 13, 2023, 8:22 AM UTC

tabacitu wrote: post #145

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…

Why? Why does it need to be good for big projects in order to be good practice? I’m genuinely asking. I never understood this argument that people bring. In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.

This.

Big companies are in the minority and what they do would not classify as "normal" or "standard practice".

It really bugs when people say "it's standard industry practice" when actually what they mean is "thats how the big businesses do it".

Re: HTML First

#494

Post by listenallyall » Mon, Nov 13, 2023, 8:23 AM UTC

codeptualize wrote: post #489

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…

How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push. You make a great point why we use client side solutions.

> How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.

That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.

Re: HTML First

#495

Post by xigoi » Mon, Nov 13, 2023, 8:32 AM UTC

ssss11 wrote: post #265

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…

Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.

And that's precisely the problem.

Re: HTML First

#496

Post by skydhash » Mon, Nov 13, 2023, 8:47 AM UTC

zztop44 wrote: post #473

skydhash wrote: post #438

Earlier quoted context omitted.

My preference is local first desktop applications. Sometimes it’s because I prefer files, sometimes it’s because native apps are more fluid and more egonomic.

What about for getting quotes on insurance? Or booking a restaurant? Or a flight or hotel? Submitting your taxes? Getting printable directions to a trailhead? Proving feedback on someone’s Figma document? Previewing a 3D model before getting it printed… Is it your preference to install a new local first desktop application any time you wish to do any of these things?

That depends where the data and the logic all. If they only store the data, but I’m doing all the computation, it may as well be a local app (figma, the 3d viewer..) or at least have an API so I can build my own interface.

I’m not against Web Apps, but many take my browser as free real estate.

Re: HTML First

#497

Post by xboxnolifes » Mon, Nov 13, 2023, 9:04 AM UTC

meowtimemania wrote: post #336

tarikjn wrote: post #308

This whole post is an anti-pattern and bad advice. It read as from someone who didn’t go through the growing pains of building complex websites. This is how we started building websites until things started to break with side effects, conflicting class names, bad introspection etc. and React came to the rescue. The pattern you want is progressive enhancement and your output to be clean, compact html that’s augmented…

Building websites with React also has its pitfalls and using React means introducing a lot of complexity. If you aren't already using NodeJS on the backend, it's probably best to avoid ReactJS unless it's actually necessary.

What does nodejs have to do with reactjs here?

Re: HTML First

#498

Post by geenat » Mon, Nov 13, 2023, 9:39 AM UTC

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

Good options for zero build:

* Self host tailwind v3 CDN.

* https://github.com/gnat/css-scope-inline

Both are surprisingly fast- parse 10,000+ or class="..." in under a second.

Re: HTML First

#499

Post by donperignon » Mon, Nov 13, 2023, 9:50 AM UTC

This trend makes total sense given the current web panorama.

I have been disabling javascript for a lot of websites during the last year, the experience is not damage at all, it's the oposite, you get a snappier navigation, no ads tracking and if you have bandwidth issues you now can browse those sites without problem.

The drawbacks, some interactivity is lost, but nothing major.

Re: HTML First

#500

Post by marcus_holmes » Mon, Nov 13, 2023, 9:53 AM UTC

azangru wrote: post #490

marcus_holmes wrote: post #443

Earlier quoted context omitted.

Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you. It's almost impossible. The first reaction is always `npm init`

> Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you. > It's almost impossible. The first reaction is always `npm init` Consider a simple case — a static website containing several pages (it's simpler than anything requiring a dynamic server, right?). If you are a professional front-end developer, you are almost certain to prefer some kind of a static-site gener…

> or you could use a Hugo binary (I'd love to see anyone call its templating language simple)

I dunno, I'm a Go dev, so it makes sense to me ;)

> Is this too complex a step?

If it just stopped there, sure, that would be fine. But it never does. My experience of front-end devs is that they will do anything to avoid writing any actual code. So there's a tendency to pull in dependencies and bloat the thing until it suffocates in its own complexity. I've seen node_modules with thousands of subdirs, and a build process that takes minutes, for really very simple sites.