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

301–310 of 551 posts

Re: HTML First

#301

Post by MrJohz »

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.

Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems).

Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.

And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.

Re: HTML First

#302

Post by zilti »

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.

Hopefully WASM will fill that area, and browsers can go back to being browsers.

Re: HTML First

#303

Post by [deleted] »

RoddaWallPro wrote: post #275
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.

[deleted]

Re: HTML First

#304

Post by zlg_codes »

codeptualize wrote: post #244
zlg_codes wrote: post #232

Earlier quoted context omitted.

Are you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.

So pelican and hugo are not frameworks? How is a static site generator any different from statically exporting next.js/nuxt.js or similar? I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary. And to be clear, these static exports are incredibly fast and performant. > you could roll your own SSG in a w…

I can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace.

Sure, you can make plugins for Pelican to make it generate things the way you want, but it's still just a generator/builder using Jinja templates and Markdown or some other text transformation tool.

Also, there's no real indicator that I used Pelican to build my site. There's no cruft I'm including in my element or anything else. It outputs regular-ass HTML.

I'm sure it's nice to be able to swap into dynamic web app mode if you decide a project's going differently than expected, but I don't run into that much with the things I design. I usually know from the beginning which tech I'll need to achieve the goal.

Frameworks force the dev into specific ways of doing things, so if a program fits into that architecture, go nuts. I'm curious what you guys need on your sites that require so much JS.

Re: HTML First

#305

Post by [deleted] »

pech0rin wrote: post #196

I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css? The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is…

[deleted]

Re: HTML First

#306

Post by MrJohz »

zilti wrote: post #298
codeptualize wrote: post #167

Earlier quoted context omitted.

This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.

You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.

While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.

Re: HTML First

#307

Post by zztop44 »

zlg_codes wrote: post #237
threatofrain wrote: post #117

Earlier quoted context omitted.

> Just use a single CSS file with sensibly named classes IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.

Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming. Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name. Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar…

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.

Re: HTML First

#308

Post by tarikjn »

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 by JS. Which means build step. Everything opposite to this article’s advice.

Re: HTML First

#309

Post by guhcampos »

Isn't this just Unobtrusive Javascript all over again?

We lost that war once, I don't see why we would win now. I'm saying "we" because I am particularly for this approach, too.

Don't get me wrong: I absolutely hate React, and am very cinical about the whole "server side rendering" fad (well, we've been doing server side rendering for 30 years, right?). Still, I think the overall web community simply does not care enough, so I've kind of given up.

Re: HTML First

#310

Post by m-a-r-c-e-l »

mostlylurks wrote: post #269
m-a-r-c-e-l wrote: post #30

I love the idea! In my current company we started with HTML and embedded JavaScript at the bottom and Styles at the top. Everything in one file, very easy to find and understand. It was "a little bit" slower. Pagespeed Insights didn't like it. Now we are "modern" with CSS and JS in a build process. And nobody knows which file to look at... My new Projects will start with HTML first, again. My credibility: 45 years, c…

Assuming your site doesn't literally have only a single page, how do you handle reuse of styles and potentially behavior across pages if you put everything into one HTML? I've tried out the "everything in one file" approach in various contexts where it has worked out fine, but a website seems like the one place where it would quickly become an issue. I would at the very least assume two reusable kept separately from…

You're absolutely right. We had additionally one common JS/CSS file each.

Every approach has its pros and cons.

Post reply on HN