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

341–350 of 551 posts

Re: HTML First

#341

Post by oblib »

Personally I prefer to take away from this the aspects that might work for me, as opposed to looking for anything I can come up with to rip the author a new ass.

In my case, I decided to keep using jQuery as opposed to React or other newer frameworks when I started building an app I was getting ready to update around 5-6 years ago. Not because I found anything negative about React.js and other, newer, JavaScript libraries, but because jQuery still does what I needed and I was familiar with it.

I have no doubt that React is a great choice for teams but end users don't care at all about what's under the hood, they care about usability and stability. What I cared about was my personal productivity.

If I were managing a team I likely would've used React.

Re: HTML First

#342

Post by codeptualize »

zlg_codes wrote: post #330
codeptualize wrote: post #325

Earlier quoted context omitted.

And it's totally fine if it works you, I'm not saying one is better, I'm saying both are valid choices and if you statically export from a framework, it's not that different from what you describe. > Frameworks force the dev into specific ways of doing things Not really. Take Next.js, you can also use markdown (or more dynamic flavors of markdown like MDX/markdoc), you can use a headless cms, it doesn't really matter…

> Example: Using Next.js again, out of the box it does instant navigation by preloading new content on hover, and not doing full refreshes when they aren't needed. Great for the user, less bandwidth used, much faster sites. That's just one example. I don't understand what you mean here. What content is being preloaded, what is being hovered on, why do you need only partial page loads? Is this for a doomscrolling UI w…

Could be, but also just page transitions, think a blog, documentation site, often you keep the navigation and just replace the content. If you are curious, it's quite easy to try. The results are really snappy, it's really nice.

But, I'm not trying to convince you. If you are happy with Pelican and it works for you, great.

All I'm pointing out is that we use these things because they do actually solve problems, often make things faster not slower, and allow me to make better websites and apps for my users. From simple websites, to complex applications.

Re: HTML First

#343

Post by [deleted] »

oliyoung wrote: post #339

` ` Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics. This is a terrible idea.

[deleted]

Re: HTML First

#344

Post by 6031769 »

qwertox wrote: post #340

I gave up this year, it's no longer possible to keep fighting these react, vue, angular monsters with their bundlers and transpilers and all the junk that comes with them, like node with npm which always throws at you the message that your brand new, seconds old project has 7 severe and 8 critical vulnerabilities in it, because it must download thousands of files, possibly including a wrapper for boolean values. The…

Rage! Rage against the machine!

You (and indeed everyone else) has no real need for heavy JS front end bloatware. Just say no. Serve light pages from the backend (or cache) and do all the fancy work in CSS (if you must).

Say hello to fast render times and global accessibility.

Re: HTML First

#345

Post by Xeamek »

ralmidani wrote: post #43

Maybe I’ve already drunk the koolaid, but if I end up building a new app from scratch, I would really like to experiment with something similar to what the author describes: Django for most (if not all) of the server-side code, Django templates generating HTML, htmx handling most interactivity with html attributes and, when necessary, hyperscript (for use cases that can’t be covered easily by htmx). I would probably…

I think you might find that relevant. (But in short, the author expressed being verry happy with switching to 'stack' you described) https://youtu.be/3GObi93tjZI

Re: HTML First

#346

Post by codeptualize »

codeptualize wrote: post #218
tonyennis wrote: post #95

OP Here. This got more engagement than expected, some of the bits I've picked up in discussion: "Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development. "Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production.…

> We use static-tailwind, a version with no build step, in development. So you do use a build step for production? Or are you shipping a bunch of unused styles?

It looks like the latter, and loaded blocking as well.. I get it, convenient, but that's not really great for the argument.

https://html-first.com/stylesheets/tailwind-full.css 68kb of blocking unused css.

In total ~100kb of blocking scripts and styles. Most frameworks would optimize this for you out of the box..

Re: HTML First

#347

Post by lwhi »

What goes around comes around.

Once upon a time these first principles were the bedrock of web development.

Re: HTML First

#348

Post by Xeamek »

ativzzz wrote: post #251
max_ wrote: post #243

Earlier quoted context omitted.

The reason "nobody understands the app anymore" is due to the complexity of React and not the application. HTMX tries to reduce the complexity.

No, nobody understands the app because it is simply impossible to hold in your head 5-10 years worth of development by 100+ people across a complex product with complicated use cases and customer need (unless you were there the whole time and you are a very hard worker) By the time you create the correct abstractions, customer needs and the market will have changed and thus your abstractions are now incorrect

It's both.

Sure, if you have project like facebook then you problably won't get away from complexity, and you NEED a tool to help you manage that.

But at the same time, if you assume you need such tool from the beginning, chances are you will over-complicate your solution and it will become a self fulfilling prophecy of trying to tackle complexity by adding more complexity

Re: HTML First

#349

Post by Yodel0914 »

6031769 wrote: post #344
qwertox wrote: post #340

I gave up this year, it's no longer possible to keep fighting these react, vue, angular monsters with their bundlers and transpilers and all the junk that comes with them, like node with npm which always throws at you the message that your brand new, seconds old project has 7 severe and 8 critical vulnerabilities in it, because it must download thousands of files, possibly including a wrapper for boolean values. The…

Rage! Rage against the machine! You (and indeed everyone else) has no real need for heavy JS front end bloatware. Just say no. Serve light pages from the backend (or cache) and do all the fancy work in CSS (if you must). Say hello to fast render times and global accessibility.

For smallish or personal sites I'm 100% on board. For a large enterprise-y app, which in a previous era would have been a rich client deployable, the benefits of these hulking UI frameworks outweighs the costs.

Re: HTML First

#350

Post by arcanemachiner »

ckolkey wrote: post #279
mmcnl wrote: post #264

Earlier quoted context omitted.

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

Unless I'm mistaken, it's shown in a format localised to the user, so... i'd much rather you keep your hands off that, and I'll enjoy my DD.MM.YYYY

ISO-style timestamps are the only only one that makes any sense.

YYYY-MM-DD or GTFO.

Post reply on HN