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

441–450 of 551 posts

Re: HTML First

#441

Post by marcus_holmes »

xgb84j wrote: post #274
josephg wrote: post #210

Earlier quoted context omitted.

I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on. The big projects are of course important. But even chrome needs a simple little website with a download link.

That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane…

I always see this as a communication/management failure.

Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.

A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.

The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.

Re: HTML First

#442

Post by skydhash »

docmars wrote: post #407
Xeamek wrote: post #331

Earlier quoted context omitted.

>React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens. React might be 10 years old, but it changed like 5 times during that time. Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?). It's almost disingenuous to ignore tha…

React's first flavor (class-based components) are fully backwards compatible with today's React versions. It doesn't seem odd to me that a popular library identifies its pain points and improves its APIs & patterns over time. That's the beauty of open source software with large communities guiding their growth. Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already qu…

> This was a natural evolution from NextJS

It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.

Re: HTML First

#443

Post by marcus_holmes »

MrJohz wrote: post #301
andybak wrote: post #234

Earlier quoted context omitted.

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

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`

Re: HTML First

#444

Post by chii »

LudwigNagasena wrote: post #439
chii wrote: post #436

Earlier quoted context omitted.

I argue that it is a framework issue. If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.

React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.

if you're using react and then hand roll custom components and don't do accessibility, then it's just as bad as choosing a component framework which doesn't do accessibility. I am not talking about react (or any framework directly) specifically.

> entirely on you

of course - choosing a framework or hand rolling one makes no difference. It's still not production ready, if it doesn't have accessibility built in.

Re: HTML First

#445

Post by nightowl_games »

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…

Cant you just use vanilla JavaScript at that point?

Re: HTML First

#446

Post by magnus-hanso »

The overall sentiment of this approach is valid, but there are some tweaks to it that I've found effective.

Rather than using Tailwind, applying BEM syntax to styles in an inverted-triangle style has been good for existing websites where using Tailwind isn't an option. Especially if the code has very clearly defined components.

Instead of inlining the JS, I'll still keep that all pretty separate from the HTML. That's probably the thing I disagree with the most here. Maybe very simple things could be used this way-Might be a case-by-case decision there. It's also nice to write a few JSDoc comments to help bring some TypeScript-ness to the table.

I like the push for being more View-Source friendly. My work pushes for squeezing out as much performance as possible on a site, but even we have found that build steps for things like minifying/concatenating has diminishing returns compared to the overall workflow overhead when there is probably an image on the page that could be trimmed down.

Like what a lot of people have said here, I think much of it comes down to what you are building, too.

Re: HTML First

#447

Post by gitaarik »

caseyross wrote: post #421

I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do. The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bi…

You can already get very close to this style of writing html/js using Lit.dev

Re: HTML First

#448

Post by mediumsmart »

It’s ok to use whatever stack, framework or tooling you are most comfortable with as long as the result loads in 1 second on mobile, half a second on desktop and scores 4 x 100 on https://pagespeed.web.dev/ without using any divs, or, god forbid, statements like container class=“wrapper”, but that goes without saying really.

Re: HTML First

#449

Post by gitaarik »

max_ wrote: post #174
silentguy wrote: post #165

Earlier quoted context omitted.

I have used HTMX with Flask and Jinja. It makes the process much simpler to do the frontend development as a backend developer. But I can see its limitations. It's not suitable for anything bigger than a hobby project. Also, it doesn't help with keeping the frontend and the api totally separate. You have to return the html object from API which has its own set of problems.

I would like to know more about these limitations. I haven't used HTMX on more than a hobby project myself. >You have to return the html object from API which has its own set of problems. If you mean that HTMX can't consume JSON. Can't you just create a separate end point for JSON responses?

Of course that is possible, but wouldn't that make the project more complex again?

Re: HTML First

#450

Post by boredtofears »

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…

I have a suspicion the reason most people reach for a framework is primarily about two different things: modern tooling (modules/bundling, typescript, etc) and templating. They don't really "need" a virtual dom diffing rendering pipeline, but the fact that you get all these other things out of the box with little setup is what makes it the go-to solution.

Then of course you're left to reimplement basic browser functionality that you now lost (or more likely, you just grab another package that solves that and throw it in your payload).

Post reply on HN