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

231–240 of 551 posts

Re: HTML First

#231

Post by ativzzz »

jasonwatkinspdx wrote: post #216
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…

37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?

To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails

And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work

They believe this now, in 4-5 years it'll be XYZ next thing

Re: HTML First

#232

Post by zlg_codes »

codeptualize wrote: post #221
tonyennis wrote: post #213

Earlier quoted context omitted.

"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.

> "Not that complex" Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages. Things don't need to get very complex to benefit from frameworks and tooling.

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.

Re: HTML First

#233

Post by rndmize »

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 yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)

Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed.

There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.

Re: HTML First

#234

Post by andybak »

xgb84j wrote: post #160
tabacitu wrote: post #145

Earlier quoted context omitted.

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.

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.

Re: HTML First

#235

Post by sethkim »

I built something recently with the same ideas in mind: https://github.com/sethkimmel3/tailgate. It allows people to build generative-AI applications without any of the complication of setting up a backend, and in the simplest cases only requires adding HTML attributes.

I originally learned to code with HTML, CSS, and JS, and I think it's still the easiest way to experience the magic of shipping a working application to others. We should keep encouraging more patterns and tooling that lower the barriers of entry to those just starting out.

Re: HTML First

#237

Post by zlg_codes »

threatofrain wrote: post #117
mattlondon wrote: post #90

Earlier quoted context omitted.

Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO. There is no harm in a plain CSS file, and applying classes at the element level in the HTML. If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings,…

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

I am interested in reading your philosophy on CSS classes.

Re: HTML First

#238

Post by moron4hire »

I think of myself as a very "semantic, HTML-forward" guy when it comes to front-end work and I found myself disagreeing with the vast majority of this.

Re: HTML First

#239

Post by yyzzx »

gemstones wrote: post #85
smallerfish wrote: post #76

Earlier quoted context omitted.

Here to bust your assumptions. I skew backend but love CSS, and am one of the better UX engineers I know of. I also dislike javascript a lot, and find that the htmx approach cuts a significant amount of complexity out of your app (e.g. your views can talk directly to your daos.)

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.

Similarly for every React/$oftheday dev who creates a snappy, race condition free, spinner free, app that feels almost as snappy as the web prior to React/$oftheday, there are 40 who create sluggish, unmaintainable tyre fires.

Re: HTML First

#240

Post by firecall »

Amen to that!

The popular pattern of constructing React components with Organism, Atoms, Molecules and so on, makes following an unfamiliar codebase a nightmare!

JSX is hard to use in my eyes.

At first I thought it must be me, but I’m glad there is a movement to reject all this front end React based madness.

Building API layers with GraphQL and React on the front end just for a few business forms is madness!

Post reply on HN