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

151–160 of 551 posts

Re: HTML First

#151

Post by tabacitu »

isodev wrote: post #81
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..

The OP was making a point that the build step should not be required to run/display a web app. For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step. I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for produ…

I read it the same way, yes. Good point with the cleanup: - it’s one thing to need to run build for it to work; - it’s another thing to run build to make it smaller;

Re: HTML First

#152

Post by aniforprez »

mock-possum wrote: post #143
1shooner wrote: post #45

Earlier quoted context omitted.

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.

Only people who haven't used tailwind say this. A lot of tailwind classes aren't singular styles but a composite of style attributes and mostly define behaviours rather than just expose a single CSS attribute. And a lot of that behaviour is applying styles on hover, on media queries, on grouped elements and other extremely common user actions, none of which are possible with inline styles

Re: HTML First

#153

Post by codeptualize »

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.

I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.

I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.

I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.

Re: HTML First

#154

Post by iudqnolq »

mattlondon wrote: post #120
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.

Well the point I was trying to make was to not do what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about the semantic nature of the style, rather than what the style actually is. The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymo…

The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..."

Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css.

Without components tailwind is probably a bad choice.

Re: HTML First

#155

Post by wildrhythms »

mock-possum wrote: post #143
1shooner wrote: post #45

Earlier quoted context omitted.

Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS. With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.

It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.

The styles are already coupled to the component anyway, so what's your problem with putting them in the markup? The alternative is making up arbitrary class names and putting the styles in a separate file: now you've added an extra layer of mapping that the developer after you has to grok.

Re: HTML First

#156

Post by jaapbadlands »

wheelerof4te wrote: post #121
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…

"I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives." Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites. In…

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 industry forward, not by building less, more basic, and shittier applications in a some faux-noble quest to use inline event handlers.

Re: HTML First

#157

Post by sawmurai »

TheCycoONE wrote: post #108

A return to unsafe-inline? That feels like a bit step backwards when it comes to cross site scripting attack surface. Content-Security-Policy forces you to opt into unsafe for good reason.

I was about to comment that but luckily stopped to search if someone else already did. In our company this is taken pretty seriously and would trigger some raised eyebrows from the security department :)

Re: HTML First

#158

Post by evantbyrne »

corethree wrote: post #146
evantbyrne wrote: post #140

Earlier quoted context omitted.

> The dom was a failure, react was a failure. What do you think going back to the DOM will do? It'll give me that extra 50% effort back. Although I've used React for years, I have never been on the bandwagon. Having built many React SPAs with different teams at this point I'm confident it has always been a step backwards.

Yeah but react was designed to address a problem. I don't know if you recall but people were complaining a lot back then. There were tons of frameworks attempting to solve the issue. Only react came out in top. By stepping back we are just going back to the same problem. The next abstraction will attempt to solve the same problem again. Very likely in a similar way react failed, the next abstraction will introduce ne…

I don't have fond memories of early React; It was extremely verbose not having hooks until relatively recently, build tools were necessary but a horrible mess, and it was falsely advertised as being faster than vanilla JS. Hype around Facebook carried React. It has improved massively since then, but so has vanilla JS. I don't see a transition away from React as a step back at all. React made rendering new elements client-side and attaching events cleaner, but that was never a hard problem per se and we have web components now.

Re: HTML First

#159

Post by infamia »

corethree wrote: post #134
evantbyrne wrote: post #129

Earlier quoted context omitted.

Agree to disagree. Building a React frontend is extremely complicated compared to server rendering HTML with progressive enhancement. It introduces state management to the frontend for even the most basic tasks, which is not something most web applications benefit from. When I built my CI/CD platform (Beaker Studio), the React portion probably added a solid 50% extra time to the project and really did nothing for it…

No you agree. You're just not understanding. The purpose of react was to simplify the complexities of front end web development. Just like the purpose of the DOM was to do the same thing. Now this article is pointing to going back to the DOM for a similar purpose. The cycle on the great circle of life occurs because we are repeatedly attempting and failing to fulfill the singular purpose of building a clean API for u…

> The dom was a failure, react was a failure. What do you think going back to the DOM will do?

Facebook (rightly) said the VDOM was needed at because of rough edges around the performance of DOM implementations in assorted browsers. The DOM has improved over the past 15 years or so to the point where things like HTMX and AlpineJs are viable for more use cases. React and the DOM have not failed, they are tools that have their uses and limitations. Looking for one solution to rule them all is ultimately an exercise in futility and disappointment. Instead we should be looking at ways to integrate React and hypermedia so they interoperate more smoothly (e.g., web components or similar solutions).

Re: HTML First

#160

Post by xgb84j »

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.

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 always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.

Post reply on HN