HTML First • Hacker News Board

Re: HTML First

#261

Post by zeroCalories » Sun, Nov 12, 2023, 10:04 PM UTC

c-fe wrote: post #246

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…

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…

The optimal date picker depends heavily on the platform too. Don't want your crusty custom date picker over my platform specific date picker that I know well.

Re: HTML First

#262

Post by corethree » Sun, Nov 12, 2023, 10:05 PM UTC

infamia wrote: post #159

corethree wrote: post #134

Earlier quoted context omitted.

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 ha…

No. The entire front end ecosystem is simply cruft added onto something that was fundamentally designed for something else. The "improvements" are attempts at fixing a flawed design while maintaining the old core design Similar to the cruft on top of C++.

>Looking for one solution to rule them all is ultimately an exercise in futility and disappointment

React and the dom were also exercises in futility and disappointment. They didn't seem that way at the time but as time went on it became clear what their problems were. The same thing can be said of htmx and alpine and whatever big framework that comes next.

Additionally who says their can't be one solution to rule them all? You think if your quotation eludes to some fictional story of lotr suddenly it makes sense? There is nothing in reality or logic that says we can create a design that can do better than all the apis that currently exist.

This idea that you can only male tools that do one thing well is fundamentally illogical. There are tons and tons of tools that do multiple things well. Take your car. It doesn't just get you from point a to point b. It air conditions you, it plays music... It provides safety, it gives you directions.

Re: HTML First

#263

Post by zlg_codes » Sun, Nov 12, 2023, 10:05 PM UTC

laurent123456 wrote: post #28

apavlinovic wrote: post #20

This is a blog spam post written by an author that has no credibility in the space rather than creating an agency that touts itself as "A software agency that doesn't suck.". How bizarre. Even more, the author uses every possible library under the sun, from Tailwind to Framer, only to evangelise about raw HTML and topics he provides no credibility on. To add to that, even the links to learn more about their agency al…

I like how he concludes "The practices and principles described on this site are still considered niche in the industry as a whole". Like he's the only one out there who knows about the details/summary tags, or who uses static HTML documents instead of React.

Are the practices that the author wrote about common? Judging from comments, frameworks are more common than plain JS, and half of those using frameworks don't fully understand what's possible without one.

I think it's fair to say a practice is niche if you don't see it anywhere and appear to be one of the few talking about it.

Let's see your website.

Re: HTML First

#264

Post by mmcnl » Sun, Nov 12, 2023, 10:06 PM UTC

c-fe wrote: post #246

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…

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…

The default date picker is laughable. For example there is no way to control the format in which the date is displayed.

Re: HTML First

#265

Post by ssss11 » Sun, Nov 12, 2023, 10:06 PM UTC

c-fe wrote: post #246

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…

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.

Re: HTML First

#266

Post by xgb84j » Sun, Nov 12, 2023, 10:06 PM UTC

squidbeak wrote: post #173

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…

Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.

The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.

For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.

Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.

While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.

Re: HTML First

#267

Post by azangru » Sun, Nov 12, 2023, 10:06 PM UTC

In other words, return to web development practices from the early 2000s? Isn't this just the pendulum swinging the other way? Haven't there been genuine problems with that style of authoring websites that the last twenty years in web development have been trying to solve?

Re: HTML First

#268

Post by corethree » Sun, Nov 12, 2023, 10:07 PM UTC

evantbyrne wrote: post #158

corethree wrote: post #146

Earlier quoted context omitted.

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 cl…

I never said a transition back from react is not an improvement. Again you're not getting it.

I'm saying we had problems with vanilla js initially and we've never moved forward. The fact that we are going back to vanilla js is reopening all the old issues are a sign that we are in stagnation.

Nothing has changed. It's a circle of attempting to improve and failing.

Re: HTML First

#269

Post by mostlylurks » Sun, Nov 12, 2023, 10:07 PM UTC

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 the .html(s): .js and .css.

Re: HTML First

#270

Post by zlg_codes » Sun, Nov 12, 2023, 10:10 PM UTC

LudwigNagasena wrote: post #52

It is so much easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveraging the extreme simplicity” effort wholly misguided. It’s neither “enjoyable” nor “seamless” to manually synchronise the backend, the frontend logic and the DOM of your app without frameworks. And maybe the trite talking point of helping young developers by sendin…

> nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development.

That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing.

...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site.

Personally I think webapps are the wrong solution for a ton of problems, but the industry won't accept that until the bottom line is affected. I'm waiting for native apps that communicate over the same commercialized protocol. QUIC but its own piece of software instead of co-opting the Web.