Live data from Hacker News

HTML First

html-first.com

331–340 of 551 posts

Re: HTML First

#331
post #201

Earlier quoted context omitted.

"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions." Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.

The chances of this happening before your project is obsolete are pretty slim. Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily usi…

>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 that fact.

So while it's unlikely that there won't be a thing called "React" in the future, it's not that crazy of an idea.

Re: HTML First

#332
post #246

Earlier quoted context omitted.

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…

This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse, etc.

Usability depends on the knowledge of your users how to correctly use the widget though - and that knowledge is greatly helped by consistency.

Re: HTML First

#333
To me this reads like a polite version of motherfuckingwebsite.com. Don't get me wrong, I love the idea and forked the pug/jade templating language just to build my site in pure HTML but without endless closing tags noise.

Re: HTML First

#334

To me this reads like a polite version of motherfuckingwebsite.com. Don't get me wrong, I love the idea and forked the pug/jade templating language just to build my site in pure HTML but without endless closing tags noise.

[deleted]

Re: HTML First

#335
I stopped reading after "This is good from an individual perspective because it allows a greater number of people to become web programmers, to build great web software, and increase their income.".

Re: HTML First

#336

This whole post is an anti-pattern and bad advice. It read as from someone who didn’t go through the growing pains of building complex websites. This is how we started building websites until things started to break with side effects, conflicting class names, bad introspection etc. and React came to the rescue. The pattern you want is progressive enhancement and your output to be clean, compact html that’s augmented…

Building websites with React also has its pitfalls and using React means introducing a lot of complexity. If you aren't already using NodeJS on the backend, it's probably best to avoid ReactJS unless it's actually necessary.

Re: HTML First

#337

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.

https://github.com/tonyennis145/dumb-tailwind/

Is it this? (A 3.9 MB CSS file?)

My personal gripe with build steps is not the build step itself, rather the unreliability of the JavaScript ecosystem and the often head-scratchingly opaque error messages.

Build steps such as a hypothetical `css-compile` don't address limitations of browsers, but limitations of network connections that may struggle to download (and frankly, at 3.9 MB, devices that struggle to parse) large amounts of CSS and JavaScript.

Even if browsers can download multiple files at once, they can't download files they don't know about, which is why ES modules in the browser haven't taken off as a way to eliminate the build step.

Re: HTML First

#338
The no-code (HTML markup only) SaaS platform I'm working on seems to fit well with this philosophy: https://www.saasufy.com/

As a demo, I was able to build a chat app with it: https://saasufy.github.io/chat-app/ You can log in via GitHub OAuth (also implemented with HTML tags).

Less than 120 lines of HTML markup in total for the entire functionality.

The source is here: https://github.com/Saasufy/chat-app

There is no custom backend logic, all the logic is in that repo as HTML + CSS.

Re: HTML First

#339
``

Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics.

This is a terrible idea.

Re: HTML First

#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 times where I could use the Python backend servers to also serve the frontend seem to be over for me.

Post reply on HN