32 ms·

HTML First

• ricardobeat 3y ago
  “Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.
  • Retric 3y ago
    The primary stated goal is “substantially widen the pool of people who can work on web software codebases.” That’s very different from typical advice for programmers. Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.
  • 1shooner 3y ago
    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.
    • dartos 3y ago
      I think there are some other benefits of tailwind. Say you have a set of css classes for different components. Then say one component on one page now needs to be styled differently. You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes. All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place. That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable
      • 1shooner 3y ago
        Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives. But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence. Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
        • dartos 3y ago
          I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying. Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick. But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier. I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.
          • 1shooner 3y ago
            A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS. >Classes that appear later in a class attribute take precedence over one’s that appear earlier. This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
    • mattlondon 3y ago
      Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO. There is no harm in a plain CSS file, and applying classes at the element level in the HTML. If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.
      • threatofrain 3y ago
        > 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.
        • mattlondon 3y ago
          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 anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)
          • iudqnolq 3y ago
            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.
    • mock-possum 3y ago
      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.
      • aniforprez 3y ago
        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
      • wildrhythms 3y ago
        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.
        • ricardobeat 3y ago
          People don’t seem to mind the 7 layers of mapping between their markup and HTML, why are styles different? I find that much more of a problem when it comes to understanding what’s happening for the average dev.
  • jbverschoor 3y ago
    Problems are multidimensional. If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation. In any case, CSS can be seen as aspect oriented programming. The real problem described here is the lack of great tooling across languages / frameworks.
  • NortySpock 3y ago
    (coming from a C# shop with too many interfaces) I think it's a natural counter-reaction to overly abstracted systems. If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer. Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component. https://htmx.org/essays/locality-of-behaviour/#conflict-with-other-development-principles https://htmx.org/essays/locality-of-behaviour/#conflict-with...
  • usrbinbash 3y ago
    > “Locality of behaviour” is such a poorly defined rule. And "separation of concerns" isn't? What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together? The answer is: "It depends". Not separating anything leads to spaghetti. Separating as much as possible, all the time, everywhere, leads to overly abstracted code that is easily as hard to maintain as spaghetti.
    • sodapopcan 3y ago
      Yep. I've said this often but whatever: JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.
• pc86 3y ago
  I want to agree with this based on the title, but why would you do something like this: <div class="bg-green" onlick="this.classList.add('green')">Click me</div> if you're already using React? Yes the React code is a lot more verbose and has a bunch of "cruft" for lack of a better word. But you're already using it for the rest of your site, so you should (IMO) continue using it rather than mixing and matching approaches.
  • 8organicbits 3y ago
    I don't think you'd mix in React with this approach.
    • pc86 3y ago
      Isn't it much easier to know you're going to use React (or Svelte or Vue or anything else) and just start there? Starting a build in HTML-first only to bolt on a JS framework after the fact seems like a lot of wasted effort.
      • listenallyall 3y ago
        The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.
        • pc86 3y ago
          Sure, I'm just talking about that middle ground where you're trying to go with this approach and find that you now need a bunch of JS framework features.
          • listenallyall 3y ago
            are you trolling? 10 people in this thread have already explained that the point is to avoid using a heavy framework, yet you keep insisting that one is necessary.
• Dunedan 3y ago
  I'm a big fan of that approach, but it's kind of funny (and sad) that such a simple page doesn't even look as intended with JavaScript disabled, as there are some placeholders of CloudFlare's Email Address Obfuscation visiable in some of the code listings.
• 8organicbits 3y ago
  Does anyone have a good list of vanilla approaches? I'm a fan of details/summary, but I'm sure there are more I don't know.
  • oceanstone 3y ago
    These vanilla JavaScript features are pretty great IMO - https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector https://developer.mozilla.org/en-US/docs/Web/API/Document/qu... - https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll https://developer.mozilla.org/en-US/docs/Web/API/Document/qu... - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... - https://developer.mozilla.org/en-US/docs/Web/API/Element/insertAdjacentHTML https://developer.mozilla.org/en-US/docs/Web/API/Element/ins... - https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener https://developer.mozilla.org/en-US/docs/Web/API/EventTarget... - https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
    • calvinmorrison 3y ago
      Tbf they got better. Jquery basically existed because the js builtins were hairy
  • HerrBertling 3y ago
    I like datalist quite a bit for „poor man‘s autocomplete“ - you can dynamically fill it via JS and will get the suggestions shown in the completion fields above the keyboard on mobile and… well, something (?) on desktop. Not as nice as an autocomplete, but with way less issues re accessibility etc. Edit: Forgot two things: - You can disable the `fieldset` attribute to disable all inputs within. So properly nest your forms and you‘ll have a simpler way of controlling forms. - Buttons can have a `value` attribute which works great to differentiate between various action paths for e.g. list items (delete, edit,…)
• irrational 3y ago
  I love that people are finally coming around to abandoning the build step.
• corethree 3y ago
  React was designed to solve all these problems. Now these problems are used to solve react. Programming, like life, is a flat circle.
  • robinhood 3y ago
    No, it was designed to address problems that were not solvable by the then-current state of simple technologies.
    • corethree 3y ago
      All the things React does is doable with plain javascript. There aren't any extra features added. React was designed to address complexities. It is an abstraction. Now we want to go backwards. Getting rid of the abstraction to get rid of complexities. But getting rid of complexities was the whole point of react.
      • evantbyrne 3y ago
        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 functionally.
        • corethree 3y ago
          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 ui construction. The dom was a failure, react was a failure. What do you think going back to the DOM will do?
• hypertexthero 3y ago
  Not bad, and reminded me of Simple & Useful: > Can html be styled well enough and simply enough so that anyone can write for the web, using just a text editor, and share that work with anyone else, regardless of the platform they are using, the speed of their connection and any disabilities they may have? https://s3.amazonaws.com/simpleuseful/index.html https://s3.amazonaws.com/simpleuseful/index.html From the old-school Introduction to Web Design: https://web.archive.org/web/20210414030104/https://www.courses.psu.edu/art/art101_jxm22/index.html https://web.archive.org/web/20210414030104/https://www.cours...
• tithos81 3y ago
  This is perfect for Svelte
  • iFreilicht 3y ago
    Why?
• apavlinovic 3y ago
  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 all lead to Twitter, rather than LinkedIn, Clutch and Sortlist.
  • laurent123456 3y ago
    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.
    • graypegg 3y ago
      The details tag is a mainstay of the "You don't need JS" genre. Every time I see it mentioned in one of these, it's always presented like it's new, unknown, and maybe a bit secretive. "OoOOoOo, bet you would write a component for this right? Well aren't you feeling silly??" I think it's showed up on every app I've worked on for the past 5 years.
    • zlg_codes 3y ago
      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.
  • deleted 3y ago
    [deleted]
  • mixmastamyk 3y ago
    Textbook ad-hominem mixed with a side order of appeal to authority.
• Jtsummers 3y ago
  This one confuses me: > Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious? [0] https://hyperscript.org https://hyperscript.org
  • gbro3n 3y ago
    Alpine.js would have been a better recommendation according to the authors advice as it is straight forward JS plus HTML attributes.
  • dartos 3y ago
    I think hyperscript has some people trying to hype it up bc it’s related to HTMX, but imo is more of a fun novelty.
  • mattlondon 3y ago
    I would agree - the example of an an attribute of `_` and then some obscure DSL statement as a value looks super weird and confusing. I would rather there was just an explicit `onclick` (or some other event) in there with a vanilla JavaScript statement so I know what is happening.
  • brennopost 3y ago
    Maybe the author swapped the encouraged and discouraged.
  • recursivedoubts 3y ago
    yeah, kinda. source: I'm the creator of hyperscript.
    • Jtsummers 3y ago
      I'm not saying hyperscript isn't serious (I have no opinion on it at all actually). I'm saying the claim "avoid DSLs" followed by an example using a DSL is a sign of unseriousness on the part of the author of HTML First. Six principles and one of them is presented with an example that blatantly violates that same principle. I could see a mistake like this slipping through if there were many more principles and examples, but this is a relatively short piece for such an error to slip in.
• graypegg 3y ago
  I love the ideas here, but honestly the examples are a bit weak here. > Where possible, default to defining style and behaviour with inline HTML attributes but their example wouldn't work. <div class="bg-green" onlick="this.classList.add('green')"> should probably be <div onclick="this.classList.add('bg-green')"> which I think makes it a little more clear how weird this could get if you wanted to add more styles. You just keep growing the params passed to the ClassList add method, in a string. I would personally find <button></button> button:active { background: green; } to be much more readable, but the author seems to imply this is complicated due to their approach of "Locality of Behaviour". -- > Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax I totally agree! But why is your example of a library not built around javascript or a custom syntax feature: <input type="text" _="on input put me into #output"> <div id="output"></div> That "on input put me into #output" I think is more jarring that the library shown as the bad example. Even better, this could just be some JS, without a framework at all. -- > Prefer "naked" HTML to obfuscation layers that compile down to HTML Their example is to not use Rails ERB tag helpers, in your templates. I don't think this is that big of an issue, these helpers can actually handle a lot of things that will look messy if you use the minimal amount of templating to write them. The example leaves off unique dom ids, turbo tags (very HTML/no JS focused!) and iteration.
  • tomrod 3y ago
    >> Where possible, default to defining style and behaviour with inline HTML attributes This was my critiquing point as well. Style configurations should be separate from actions, with only references linking the two. It's the only way that makes sense for anything meaningful. Yes, I could technically write a python app where all SQL database connections have hardcoded SQL as one one long file, but that is poor practice. This suggested principle seems the same to me.
• gemstones 3y ago
  Can the people that want this HTML-first world style it to look the ways they want themselves? My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS. Why listen to UX thoughts from a population who are scared of UX?
  • paulryanrogers 3y ago
    This strikes me as a cynical take. Having floated between backend and frontend a lot, frontends naturally tend to become very complex; even before the web. And with three different Turning complete stacks (HTML+JS+CSS) the web already feels pretty heavy before adding in another stateful framework and build tooling to support them. Folks can disagree about how to keep the system simple when looking at it from different points of view. All those opinions are worthy of consideration.
    • gbro3n 3y ago
      JS frameworks seem inevitable. Any time I've worked with native JS in a reasonable size projects, it becomes necessary to create libraries and common conventions, that starts to look like something approaching a small framework. A framework is just common patterns for solving problems. I think what a lot of developers object to is the stack of build tools required to transpile, bundle and link code together when using these frameworks, in addition to the complexity that comes with dependency management, rather than the use of the framework themselves.
  • weego 3y ago
    Having worked with it for 20+ years I've just been left convinced that the biggest mistake frontend dev has made in that time is to pretend that CSS is a language that should be 'engineered' instead of a design flavour that should be build up / torn down lightly on demand. It's esoteric corners should have been fixed and simplified so designers could learn and explore design through markup as needed, rather than double-downed on to where we are now.
  • usrbinbash 3y ago
    I am very happily listening to UX thoughts from people who specialize in UX. What I am decidedly NOT happy with, is the frontend using as much, or even more, internal logic, magic, and build steps as the actual business logic. To put this another way: I will happily listen to an interior designer on his thoughts about the color of the drapes. But if he tells me that this color means he has to bring his own crew of stonemasons, carpenters, and electricians, because somehow that color requires massive changes to the architecture and power lines of the house, I am going to grab a piece of cloth that vaguely has the color I want, and make the drapes myself.
• m-a-r-c-e-l 3y ago
  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, commercial web programming >25 years, 3 successful web companies founded as CTO
  • danielovichdk 3y ago
    Well. This was how we did web development before it turned into so many abstractions that most comments either is too young to know or simply not understanding that adding more abstraction is not ideal. People here say "show me this on a big project" well how about they showed us how the thing they are doing on a big project has turned out. The cleanliness of HTML and CSS is astonishing. That's a quality mark in my view. If you to move away from that you miss out on certain aspects imo.
  • mostlylurks 3y ago
    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.
    • m-a-r-c-e-l 3y ago
      You're absolutely right. We had additionally one common JS/CSS file each. Every approach has its pros and cons.
• Shock9889 3y ago
  This is all nice and suckless, until you will have to scale your codebase and/or add some more features (possibly alter someone's code) and deal with exponential complexity of DOM manipulation. React came to solve all this
• varun_ch 3y ago
  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..
  • moritzwarhier 3y ago
    I don't use Tailwind anymore at the moment, but in my experience, it does not lead to shipping massive CSS/JS resources. In fact I don't know about any client-side JS at all that is emitted by Tailwind (my last experience was 2.x, not sure if anything has changed). Regarding the CSS size, my experience was the opposite, Tailwind output was usually a lot smaller than hand-written CSS. I have nothing against plain CSS either though; but it's at least as easy to make a mess.
    • troupo 3y ago
      I think what the OP meant is: Tailwind requires a build step to extract use classes. Otherwise you need to ship all of it.
      • moritzwarhier 3y ago
        It's true that it requires a build step, since tw 2, AFAIK there's not even a way anymore to ship "all of it". CSS rules are generated on-demand for the classes that match tailwinds syntax.
    • graypegg 3y ago
      I think GP is talking about how, without the tailwind build step, you ship all of tailwind, which is unquestionably a lot of CSS that you aren't using. Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided? Still though, tailwind is pitched WITH it's build step normally, making the author's point about avoiding a build step a bit odd.
• audnaun252 3y ago
  Article doesn't even have anchor tags
• thiago_fm 3y ago
  The person who created that website should have a look at the recent Rails updates :-) Or check out DHH's most recent thoughts on minification etc.
• ralmidani 3y ago
  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 stick with downloading minified Bootstrap for styling (Tailwind requires a build step, and I don’t think I have done well in the past when I waded into “class soup”). Has anyone here tried something along these lines for a non-trivial app? How is it going?
  • ajayvk 3y ago
    I have used this approach for internal tools and it has been great. It makes it much easier for one person to build the whole app, frontend and backend, and makes ongoing maintenance much easier. I am working on https://github.com/claceio/clace https://github.com/claceio/clace which takes this no build approach and makes it easy to build portable applications, using Starlark running in go to configure the backend.
  • 101008 3y ago
    I used this exact approach: Django backend, Django templates and htmx. It has been a delight.
  • npilk 3y ago
    This is what I’ve used for my last couple of projects, including https://www.semiform.ai https://www.semiform.ai - not sure I’d call it “non-trivial”. I’ve really enjoyed this stack. The structure just seems to click in my head better.
  • Xeamek 3y ago
    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 https://youtu.be/3GObi93tjZI
• LudwigNagasena 3y ago
  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 sending unoptimized unminimized comment-rich source code directly to end-users held at least some weight in the 00s; 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.
  • dartos 3y ago
    It depends, I think. For “apps” vanilla js isn’t enough. But for a blog with some animations or simple validation, things like next or gatsby is WAY too much
    • treyd 3y ago
      My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as a webapp.
      • dartos 3y ago
        Why? The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far. It’s not good for everything all the time, but it is good for most UI focused software most of the time.
        • zlg_codes 3y ago
          Is there no appreciation for using the right tool for the job? When you build an app on Electron, you're forcing the client to run another browser, alongside whatever other browsers they're running. Due to the complexity of the Web, running a browser now takes hundreds of megabytes of RAM, sometimes a gig or two. Now imagine you have 8 different Electron apps you use. You have the system resource use of 8 separate browsers now. Congrats. Secondly, there's no integration between Web apps and the OS. Only recently did things like light and dark mode get OS-level support, so there's that much, but long story short, Web apps don't integrate well with the system. They tend to be shipped in containers, too, so while it may be "good security" it results in a worse runtime environment and uses more resources. The Web is a document platform, first and foremost. The building of V8 and Node.js, the myriad frameworks, etc, are the result of companies trying to turn an existing protocol into a moneymaker. Tim Berners Lee never intended the Web to be an application platform or a vector for DRM. For-profit interests created all of that extra complexity, and took over standards committees to push their ideas through. Web apps work best when they take advantage of some of the Web's strengths. If your program needs to talk on the network a lot and it's already working with HTML, then yes maybe it should be a webapp. The problem is everyone's ignoring the complexity, resource use, and tangled knot of abstraction on the client's end. It's "not a big deal", until it is, then we'll go back to rediscovering how easy native development is with a smart enough Makefile. All the major UI toolkits are cross-platform, there's little excuse.
• xhrpost 3y ago
  > Where possible, default to defining style and behaviour with inline HTML attributes Wow, have we just come full circle after 25 years?
  • FFP999 3y ago
    I literally--literally, not figuratively--facepalmed when I read this.
    • vorticalbox 3y ago
      This comment or that part in the link?
      • FFP999 3y ago
        The advice to put inline styles in your HTML.
  • deleted 3y ago
    [deleted]
  • croes 3y ago
    And it isn't even done in the example. >class="bg-green"
    • laurent123456 3y ago
      Thankfully he got the `onlick` attribute right.
  • amjnsx 3y ago
    These tailwinders are everywhere these days.
• deleted 3y ago
  [deleted]
• ilrwbwrkhv 3y ago
  HTML should have been improved by now. What is sad is that fundamental things like a put request through a form can't still be done by simply a method. Keeping html hobbled is literally a conspiracy.
  • Devasta 3y ago
    https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16 It doesn't make sense that you would want to PUT a form apparently.
• deleted 3y ago
  [deleted]
• alib 3y ago
  I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?
  • tonyennis 3y ago
    Good catch - fixed.
    • alib 3y ago
      You rock.
  • zlg_codes 3y ago
    Why is a clickable div an accessibility nightmare when the button element has a lot of browser-preset styles that are harder to override? Assuming you put all the relevant state styles into place like :hover and :active and whatnot, what's the problem? Button elements are best used in a form. If you aren't submitting a form, what's the button there for?
    • meowtimemania 3y ago
      button { all: unset; } This removes all the preset browser css styles. An accessible,styled <button> is much easier to achieve than an accessible, styled <div>
      • zlg_codes 3y ago
        What makes it more accessible? I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.
        • alib 3y ago
          That’s exactly it. With native buttons and links you get all the accessibility for free. If you attach events to non-interactive elements, you have to do all the accessibility work yourself. In a custom interface, a button outside a form is perfectly valid and the best choice for the above reason.
• andai 3y ago
  The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for web sites. For web apps, at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.) I used to be really big on this, though (and it makes me sad that these days most sites are 1 big unreadable line of HTML). In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!), though I did eventually make a "build system" (my build system is cat) so I could have a sane editing experience. Boom, self-contained portable software in 1 human-readable file! Along the same lines, I think the coolest thing about web development is that you can make your first (interactive!) programs with Notepad and whatever browser ships with your machine. (Just drag the HTML file onto the browser!) It's magic! Edit: Just found an unexpected benefit of self-contained HTML: makes your software immune to bit rot. I tried loading an old project of mine on Web Archive but it hadn't archived the external JS file! Sad! Meanwhile, this one loads fine because all the JS is in the HTML! Winning! https://web.archive.org/web/20210508133239id_/https://andai.tv/springs/ https://web.archive.org/web/20210508133239id_/https://andai.... This is my homage to the old SodaPlay Constructor. (Never made an editor, sorry!) Feel free to view-source!
  • mlhpdx 3y ago
    I don’t believe the author is advocating for single file systems, but I don’t want to speak for them.
    • andai 3y ago
      Sorry, I didn't mean to imply this! My original comment had "I even go so far as to..." but it got lost somewhere in editing.
  • xg15 3y ago
    I'm sceptical on this: by now there are lots of ways to "peek behind the curtain" in the developer panel: we have the DOM view, network tab, heap view, built-in javascript prettifyer. Sure, "view source" is still important, but I'd question if its importance is still as absolute as the HTMX people make it out to be.
• cantSpellSober 3y ago
  <details> and <summary> are great, but animating them to slide open instead of "pop" is difficult to implement without JS when the contents are not a fixed height. Sliding open guides the user that something has changed, improves the UX. I've found that using the `open` attribute in CSS behaves differently across browsers as well. Sometimes it doesn't even work consistently in a single browser implementation.
• gardenhedge 3y ago
  This seems like it came from a newbie/inexperienced dev. > substantially widen the pool of people who can work on web software codebases This isn't a problem. There's already more people who can work on web software than there ever was. > A second goal of HTML First is to make it more enjoyable and seamless to build web software Subjective. If people enjoy it like this that is fine but these shouldn't be touted as principles everyone should follow.
  • tonyennis 3y ago
    Not newbie or inexperienced, have built & managed multiple large teams & been thinking about this for a long time https://x.com/tonyennis/status/1139071584935637000?s=20 https://x.com/tonyennis/status/1139071584935637000?s=20
    • gardenhedge 3y ago
      There's a few reasons for the ratio mentioned in your tweet. Rapid industry growth in the past decade and the fact that junior devs are cheaper to have on a team. It's got nothing to do with writing a website in HTML vs React.
• codeptualize 3y ago
  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’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something. With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.
  • philihp 3y ago
    For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR. I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.
    • tonyennis 3y ago
      Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo
      • codeptualize 3y ago
        Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides? Nothing is more convincing than real world success stories.
        • tonyennis 3y ago
          Coming soon
• tonyennis 3y ago
  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. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point. "OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in. "This is a blog spam post written by an author that has no credibility in the space": Brutal
  • reidjs 3y ago
    Never read the comment section!
  • keepamovin 3y ago
    I like this. I share a philosophy similar to this: hew close to the grain of the material. It's heartening to see articles like this. I've created many expressions of my ideas on this in code over the years: Brutal.JS, VanillaView, Bang/Good.html and I recently created one that is even simpler and I'm very happy with. It's similar to a unification of these ideas with Custom Elements. You can check it out here: https://github.com/00000o1/- https://github.com/00000o1/-
  • vlttnv 3y ago
    Personally, I am happy to see someone else thinking about cutting down stuff and simplifying. Similar posts have started popping up more frequently and as a fan of simplicity, reliability and maintainability I am very happy! Don't get discouraged.
  • x0x0 3y ago
    Well, also, you make some claims that could be interesting then provide zero proof or even discussion at all. The entire world: interesting in eng being more productive and interested in more maintainable software. So the first 2 sections are interesting. You then chase them with a list of assertions with zero discussion as to how they make eng more productive, or lead to more maintainable software. Also without even a hint of why people eg prefer not defining styles inline (protip: fun at first. Now try changing one of them... have fun reviewing 3000 inline bits of css.) Like the industry settled on certain things for a reason, and you don't even attempt to engage with that reason. You also cite dhh when you like his reasoning and ignore him when you don't. about which, well...
• jokoon 3y ago
  I made some web app with the least amount of logic in the JS, and almost all of it in a flask server, with a few ajax calls. I have to admit that managing asynchronous js callbacks is really a pain to deal with. JS is really an awful, awful language.
• lincon127 3y ago
  Relying on simpler frameworks when you can make sense. But the notion of getting rid of build steps is a complete lark, just be more efficient with build steps, and if necessary, don't include them in production. Also why would you want to prioritize adding your attributes to HTML? Are you making a document and hosting it as a website? In what other world is that preferred? CSS isn't hard to navigate, if anything one should be encouraging better CSS practices. Yes, frontend scripts can obfuscate styling, but perhaps just don't rely on that if you don't need to, which is already a no-brainer, since it's harder to give an attribute via some JS rather than shoving it into a style document. Some of these make sense and are obvious, like using only what you need (which is preached for half of the article). But the rest of it confusing, if not outright ridiculous. Why are we even assuming that being able to copy an entire HTML page is a good thing? Frankly I don't care, and it's not like there are literally millions of resources to use to learn HTML even if you can't view a few pages' HTML. Idk man, kind of a head scratcher
  • SuaveSteve 3y ago
    A lot of this stuff is a response to the worship of complexity by the webdev industry.
• TheCycoONE 3y ago
  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.
  • sawmurai 3y ago
    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 :)
    • Jiocus 3y ago
      While I agree that the article overlooks the security aspects of inline scripting[1], we do have content security policy[2] at our disposal using CSP nonce[3] and hash[4] keywords to allow inline script and CSS. On the other hand, the articles ease-of-use argument of inlining doesn't really hold up after factoring in CSP. In my opinion, it's consideration as unsafe isn't intended literally. It has more to do with: - The human error aspect of understanding and tightly implementing CSP, - Separating style and JS into their own files provides some security as is (and allows ignorance of CSP to continue even though it has it's use case here as well). Now, if your company takes this pretty seriously, they likely require that CSP should be part of your security process already. If that's the case, any use of unsafe inline in your markup will be blocked by default until concrete steps are taken to have nonce or hash in place. Edit: I did not intend to sound harsh - just wanted to chip in about the nuances about the possibilites we are provided :) --- [1]: https://web.dev/articles/csp#inline_code_is_considered_harmful https://web.dev/articles/csp#inline_code_is_considered_harmf... [2]: https://www.w3.org/TR/CSP/ https://www.w3.org/TR/CSP/ [3]: https://content-security-policy.com/nonce/ https://content-security-policy.com/nonce/ [4]: https://content-security-policy.com/hash/ https://content-security-policy.com/hash/ [5]: https://web.dev/articles/csp#use_case_3_ssl_only https://web.dev/articles/csp#use_case_3_ssl_only
      • TheCycoONE 3y ago
        Neither of those work for the inline event handlers proposed by this article. You need unsafe-inline or unsafe-hashes.
• mattlondon 3y ago
  I get the sentiment of this, but I struggle to recommend it (not least for the spelling mistakes, especially in the code examples) My main criticism is that you cannot really advocate for "View-Source Friendly" HTML with the view of widening the pool of people who can work on it, and then simultaneously recommend that people use libraries like HTMX or Hyperscript that have their own unique syntaxes that aim to be compact and concise, but actually are just confusing and unfathomable unless you are already familiar with them. This flies totally in the face of the main goal of this site because you're advocating for people to use niche and sparsely-used custom DSLs for coding part (...yes only part!) of your site's business logic. I also don't really see the value in trying to aim for view-source compatibility on a page-by-page basis - a better approach might just be a link to your source repo in Github (or elsewhere) that contains your entire project along with e.g. README.mds etc. And if you expect people to "view source" to learn, how can you expect people to do that when you have inscrutable non-HTML/non-JS nonsense like `_="on input put me into #output"` in there? I get it - I learnt HTML originally back in the day by looking at the yahoo pages source code, but we are not in the early 90s now: people can learn HTML from other places these days that offer a better experience than looking at a sites source in a vacuum (e.g. Github but also so many more ways now than those early days - there are millions of decent online courses, youtube videos, bootcamps that teach the syntax (i.e. all you get viewing source) as well as the rationale and the reasoning for decisions made and approaches used) I would modify this guide and offer some different/additional advice: - Use vanilla JS + vanilla Web APIs (Element, Fetch, Promises/async-await etc) for all business logic, and split code into modules (e.g. https://byexample.xyz/javascript/ECMAScript2015/modules/ ) so that your code is simple, has fewer dependencies, and is understood by 100% of web developers (unlike HTMX, Hyperscript et al that no one understands without having to go specifically learn it specially) - Use HTML-based Forms validation rather than custom-logic wherever possible. - Structure your DOM logically and use the correct semantic HTML elements for their intended purpose (e.g. use <button>, don't use <div onclick="...">) so that your page is accessible and easily navigated by keyboard users ("power users" and otherwise) - Either add CSS classes directly via inline handlers, or do it via javascript, but whatever you do make sure you are consistent within the same project. Good luck with your project.
  • somishere 3y ago
• kuon 3y ago
  There is a valid philosophy behind this, but the arguments are a bit flawed. For ezample CSS is not only styling (as in theming) it is important for GPU animations and is hard to sync with app state ans JS without some tooling.
• shadowgovt 3y ago
  I don't think I buy the premises under the goals here. > The main goal of HTML First is to substantiall widen the pool of people who can work on web software codebases. Fair goal. > A second goal of HTML First is to make it more enjoyable and seamless to build web software. Also a fair goal. > The way we achieve these goals is by acknowledging that HTML is very easy to understand, and thus using HTML as the bedrock of our product - not only to define content and structure, but also to set styling and behaviours. It's not. It's a large, heterogeneous collection of behaviors based on the arrangement of various tags with coupling between the tags defined by hundreds upon hundreds of pages of individual tag descriptions. And that's before we even consider that there's a matrix of browser compatibility layered atop that. If I code up some complex behavior in React (such as the details-summary example here), the result is obvious, shows up in the deubgging tools, and works on every browser that supports React. Most importantly, the knowledge is composable: that approach to showing and hiding content works regardless of the content being a "details" and "summary" or a shopping cart contents pane or a modal dialog. With vanilla HTML, every aspect of the default behavior is dictated by the browser, and very few pieces compose with each other sanely (what happens when I nest <details> tags? I have to try it to find out; if it's a React component, I can read the JavaScript and know). I'm not saying one shouldn't use vanilla HTML or should only use <div> with style for the whole layout or anything like that; there are semantic concerns that make using HTML where possible a good idea. But I'm not going to trip over myself to memorize every behavior and interaction of the declarative HTML model if it's easier to build things like collapsible details tags in React.
• R1321020101 3y ago
  Raúl Gúrru Miau {Miáu} 8
• sylware 3y ago
  I would add that for noscript/basic (x)html version of web sites, 2D "semantic" HTML documents are not harmful, and table navigation is ok for screen readers if not done too weirdly. Of course, I am not talking about the abomination of "semantic web" we had a decade ago.
• didip 3y ago
  I like the spirit of the article. My personal preference is server side templating using as much default HTML as possible with JS as progressive enhancement (using HTMX or something similar).
• willsmith72 3y ago
  > If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see I don't see why this is beneficial "<button onclick="this.classList.add('bg-green')"> Click Me </button>" I don't like this at all
• anon23432343 3y ago
  I'm not a big fan of JSX... But that trend to put everything back into HTML were possible is also wrong... Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app. Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s What about i18n? or a10y? The examples of the form don't support any of that. Have fun writing the right input every time without a well abstracted text input that does the hard and annoying stuff for you. We switched to components for a reason but it seams like people forgot. And yes not every blog or form needs to be writen in nuxt or some other big framework.
  • deleted 3y ago
    [deleted]
  • mock-possum 3y ago
    Also not a fan of JSX. VUE’s component definitions are slightly better - at least it’s using actually HRML tags and <template>s. Personally, my favorite is Lit’s approach, writing HTML in tagged template literals. It’s still mixing your HTML with your JavaScript, but it feels much cleaner, closer to the vanilla experience of marking up content.
  • c-cube 3y ago
    I have to use gmail for work, and I use the html version. It doesn't eat hundreds of MBs of ram or slow down my browser like, say, Google cloud's UI does. Ymmv. (of course the html version is not as good as a non webmail would be. Such is life I guess.)
• mro_name 3y ago
  doesn't the inline JS (onlick="this.classList.add('green')") harm/complicate CSP headers?
  • lol768 3y ago
    Yes, it all flies in the face of accepted strict Content-Security-Policy best practice.
    • zlg_codes 3y ago
      I've not seen the reasoning for this in the thread. Best practices are generally called that for a reason.
• zelda-mazzy 3y ago
  In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier. Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand the sentiment behind this, tools like React or Angular have significantly lowered the barrier to entry in their own ways.
  • max_ 3y ago
    Have you used HTMX? I am yet to find a reason for using frameworks like React instead of HTMX.
    • silentguy 3y ago
      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.
      • max_ 3y ago
        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?
        • gitaarik 3y ago
          Of course that is possible, but wouldn't that make the project more complex again?
      • recursivedoubts 3y ago
• alfonsodev 3y ago
  The main feature that introduces the need of a build step is having a template engine in order to reuse blocks of code, like footer, header, menu, etc.. I think Dreamweaver MX introduced something like template files, and it would make a "build" step that would copy the files from template to actual html files. Then it started to get complex, with data sources and generating pages in the backend. (php, asp, cold fusion?)
  • ndriscoll 3y ago
    Browsers have had built-in templating engines (xslt) for decades.
    • zlg_codes 3y ago
      That's cute, now show me someone who's made something modern and usable with that tech. I used XSLT and XML to build a video game collection tracker. Just a page that could display things. It was a nightmare. I later spent a weekend building it in Python, added "export to JSON" and then made a tiny SPA with vanilla JS to do the job. It's very powerful and can do some neat things, but it's taught poorly and not easy to teach yourself.
      • ndriscoll 3y ago
        I'm not sure what you mean with it being a nightmare. It's my go-to for personal stuff. Most recently I used it to make a template for my photo albums. For personal stuff it works fantastically because it's easy to just use a simple text editor for everything with zero other tools required. It's out of fashion these days, sure, but you could easily make e.g. a forum or a news site or a blog or a facebook type of thing. Anything where you want, well, templated html. So almost all of the web. I know once upon a time the WoW armory was built with xml/xslt. It's convenient because then you've already also automatically got a data API; just ignore the stylesheet.
        • zlg_codes 3y ago
          In my case, I needed to put together table headings that were clickable that would sort the dataset. XSLT can do that, but midway through doing the task, I realized that I was working with stuff that belonged in a database, accessible from more places via SQLite. Since I needed a multitude of different ways to sort and filter the data set, I made use of VIEWs to abstract the filtering and turned it into a CLI tool. There's still an appreciation in me for XML (specifically SVG), so maybe I'll try something else with the tech. Care to share a link or example to more of what you're talking about?
• TheRealPomax 3y ago
  If you're creating a web page, use HTML. If you're creating an application interface, use a UI framework like React. Don't use React for web pages, don't use plain HTML for application interfaces. But don't pretend that web pages and application interfaces are the same thing just because they both use the browser, or because "the application runs on the web".
• tannhaeuser 3y ago
  What's the opinion on re-introducing HTML attributes for style properties, eg. <div width=40pct color=red> (possibly with additional enumerated attributes usable in short value-only syntax as in <div disabled>) rather than <div style="width: 40%; color: red">? I mean, introducing a secondary syntax for item-values, like CSS did, quite never made sense to me personally even though it was nevertheless thoroughly defended ([1]). I guess it doesn't make sense to me coming from an SGML background which had style sheets capable of stateful/automaton-based assignment of attributes for ages. But now with tailwind so popular and little more than inline styling with sane defaults perhaps, and this manifesto expressing a strong preference for markup attributes, isn't it time to come to the realization that, whatever point CSS had when it was new, surely is driven ad absurdum by its obscene syntax proliferation and extreme redundancy (something even W3C CSS WG's chairman/staff contact already was warning against over ten years ago [2])? Personally, I don't care for web "apps", seeing the unique value of HTML rather as authoring format for web "docs". For mere apps where JavaScript is obligatory anyway, I think I'd actually prefer CSS-in-JS. [1]: https://wiumlie.no/2006/phd/css.pdf https://wiumlie.no/2006/phd/css.pdf [2]: https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables
  • timeon 3y ago
    For me, it does not matter if it is inline CSS, style attributes or Tailwind. I do not like them.
• catlifeonmars 3y ago
  The majority of web pages fall into one of two categories: long-form content where the primary interaction is reading, and applications (consoles, editors, tools). I do not think the latter benefits from an HTML-first approach as outlined in the featured article.
• 3cats-in-a-coat 3y ago
  It seems the author was trying to apply KISS to web sites here, but being unnecessarily dogmatic they added additional complexity over mundate aspects such as whether you call your CSS /dist/output.css or /styles.css. This is completely irrelevant. HTML is a presentation layer, as such it's 99% the output of some other layer. HTML first therefore is the wrong mindset. You can't have an HTML first CMS for example, that's a recipe for spaghetti disaster. You need to define clear, constrained models that then you can adapt for given media. I feel almost weird arguing with this site, because in general I also prefer simple HTML where possible, and I can't stand overdesigned JS-generated framework monsters. But going from one extreme to another is not smart. No simple rule is a substitute for "intelligence first", and intelligence has lots of subtle rules and relies on rich context to make the right decisions for that context. Nice domain name though.
• hwc 3y ago
  I agree. I also really like writing software that builds HTML to be served as a static page. E.g. https://gist.github.com/HalCanary/61276afbab042e204e54268f6a42f065 https://gist.github.com/HalCanary/61276afbab042e204e54268f6a... Then that complexity is hidden from the client.
• xixixao 3y ago
  Specifically on the “use libraries that leverage html attributes” point: I find this “dishonest” to the overarching ideals of this manifest: If you want to follow standards, and allow view source, you can absolutely write vanilla JS, and end up with more idiomatic and approachable source than _="on input put me into #output" And then as you grow out of the simple examples you’ll probably adopt a library like React which will restrict you less than these html attribute “abusing” alternatives. Of other points, I especially like the “no built step”. A native support for JSX would really smooth out the path from vinalla to React.
• xg15 3y ago
  I'm missing a bit "if you have to use javascript, use vanilla javascript where possible" here. HTML attributes are no silver bullet. You can still have a bloated framework that puts some ill-fitting, homegrown data model over your code and drowns the codebase in "magic", even if all the interaction with that magic is through HTML elements and attributes. Generally, I think there is lots of good advice here, but I don't really understand the "messianic" attitude of the HTMX crowd. Why all the effort to actively discourage any other approach?
• deleted 3y ago
  [deleted]
• gemstones 3y ago
  I get real confused by these. Imagine if an iOS developer posted a blog about the specifics of files backing UIViews and how the XML configuration language was underutilized. Wouldn’t that be kind of a weird blog post? The declarative syntax of various UI frameworks is an implementation detail. The hard part is in CSS on the web, or style properties in native frameworks. Business logic as well. Presumably encapsulated in a component, which React does well and web technologies are catching up to. Why should I care about this, any more than I should care about XML config files on Android? It’s a markup language that is an artifact of the runtime we’re using. I don’t care about that in other contexts, and it’s the least interesting thing in a web development setting too.
  • meowtimemania 3y ago
    On web, an HTML first approach in many cases can mean a better user experience. Whether to use an HTML first approach or something heavier like React depends on the product being built.
• pech0rin 3y ago
  I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css? The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is never going to work for these types of applications. I find this hand wringing over the complexity of the web so strange. Can we all just move on? The web has changed. I have been programming for over 15 years professionally. Yeah its changed. yeah frontend frameworks are a pain in the ass a lot of the time. So lets make it better, not fall backwards to a “simpler” time.
  • codeptualize 3y ago
    This is a very good point. I would also look in different directions for inclusivity. We now have Framer, Webflow and all the others, you don't have to write any code to make amazing websites.
  • tonyennis 3y ago
    "fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.
    • codeptualize 3y ago
      > "Not that complex" Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages. Things don't need to get very complex to benefit from frameworks and tooling.
      • zlg_codes 3y ago
        Are you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.
• stanislavb 3y ago
  For the sake of being precise - the “form_with” is not equivalent to the presented HTML. The form_with helper injects an additional hidden input element that makes sure that the form cannot be submitted “illegally”.
  • codeptualize 3y ago
    I think this is a great example of all the small details we take for granted in the tools we use, and we would miss without realising when following these tips.
    • tonyennis 3y ago
      That hidden CSRF field can be added without form_with though, and Rails still protects against not including it. I left it out of the example as it didn't seem relevant
      • stanislavb 3y ago
        Yes, it can be added, but manually going over all form. Also, how would it protect against a CSRF without the token in place? Note: I totally agree that we should strive to go HTML first. However, this specific example is a bit unfair.
• andrewstuart 3y ago
  Meh. I say build software in the way that you like. Or the way the boss says.
• miggu 3y ago
  thanks I'll use it on my auntie's cupcake website
• joaomeloplus 3y ago
  I think the recommendation to use tailwind and avoid build steps and incompatible.
• zlg_codes 3y ago
  The Web was never meant to have an interactive scripting layer. It got there by accident. Microsoft's XmlHttpRequest paved the way for page loads without page loads, and it became an accidental standard due to how it worked. We can go back and replace Javascript with whatever we want, or expand the <script> element to be able to handle more than one language type. Not really sympathetic of big web apps having to adjust to such an environment. I already don't consider them truly part of the web. They're something you can make with the Web but don't actually represent the values or accessibility that the basic Web already provides. I only use JS when absolutely required.
• toldyouso2022 3y ago
  My theory is that now that central banks money run out we're going back to sanity. The end of centralbanking-driven-development is coming
• rndmize 3y ago
  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 <input type="date" /> do we get a datepicker across browsers? (Looks like yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.) Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed. There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.
  • c-fe 3y ago
    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 website on all browsers. (Its of course a different story if you need custom functionality.)
    • zeroCalories 3y ago
      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.
    • mmcnl 3y ago
      The default date picker is laughable. For example there is no way to control the format in which the date is displayed.
• sethkim 3y ago
  I built something recently with the same ideas in mind: https://github.com/sethkimmel3/tailgate https://github.com/sethkimmel3/tailgate. It allows people to build generative-AI applications without any of the complication of setting up a backend, and in the simplest cases only requires adding HTML attributes. I originally learned to code with HTML, CSS, and JS, and I think it's still the easiest way to experience the magic of shipping a working application to others. We should keep encouraging more patterns and tooling that lower the barriers of entry to those just starting out.
• adriangrigore 3y ago
  Been doing this with mkws and on https://mkws.sh https://mkws.sh since day one!
  • toastercat 3y ago
    This would be considered a build step, though.
    • adriangrigore 3y ago
      Agree, but only for the HTML files where it makes sense in order to keep duplication at a minimum.
• moron4hire 3y ago
  I think of myself as a very "semantic, HTML-forward" guy when it comes to front-end work and I found myself disagreeing with the vast majority of this.
• firecall 3y ago
  Amen to that! The popular pattern of constructing React components with Organism, Atoms, Molecules and so on, makes following an unfamiliar codebase a nightmare! JSX is hard to use in my eyes. At first I thought it must be me, but I’m glad there is a movement to reject all this front end React based madness. Building API layers with GraphQL and React on the front end just for a few business forms is madness!
• azangru 3y ago
  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?
• wayfinder 3y ago
  Writing your code in a way that makes sense to someone else is a skill. If someone writes the bonkers code in the article’s bad examples, I guarantee their “HTML-first” code will be just as bad.
• omerws 3y ago
  I agree completely, but hiccup rather than html.
• Zpalmtree 3y ago
  aka make your website look like shit because half the default elements can't be styled
• meatjuice 3y ago
  I agree with everything but inline javascript <button onclick="this.classList.add('bg-green')"> Click Me </button> This is going to be problematic when it comes to debugging. I still think scripts should be in a file and loaded in the header.
  • quickthrower2 3y ago
    It is going to be problematic when it comes to refactoring. "Can you make the button's parent container green" request comes in. Now you are hunting through CSS selector going up and down the tree. "Can you put the button that goes green into this page". Now bam! The CSS selector you used breaks as there is another element to confuse the query.
• bmon 3y ago
  Does anyone else find that blue tint on the top of the page makes it really hard to read? I guess I usually scroll the text I'm reading to the top...
• hollowturtle 3y ago
  I strongly believe that no one would hate or love to hate the build step if we didn’t have to mess around with so many unmaintanable configs, dependencies and pipelines of translations like typescript -> js with commonjs or es modules and so on. Still, for me, which ever code I write I want it to be compiled/translated by a machine, that given a “browserlist” knows better than me how to output code that works for the most system around. And that’s especially true if you have a successful product with a lot of customers. I agree on rolling back most of the abstraction madness we built so far, but surely I can’t remember how to write es5 compatible code anymore, should be a no brainer for me. Lastly, I can’t disagree more on improving inclusion with “html first”, whatever approach you choose it’s still super hard to have a web app that has: perfect audit score, adpative ui for all screens, accessibility, print(! what id customers demand that each app page should be printable?) and more I can’t think of now. This job is hard, it’s not for everyone and going back to first principle won’t save us from hardwork anyways
• tarikjn 3y ago
  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 by JS. Which means build step. Everything opposite to this article’s advice.
  • meowtimemania 3y ago
    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.
    • xboxnolifes 3y ago
      What does nodejs have to do with reactjs here?
• guhcampos 3y ago
  Isn't this just Unobtrusive Javascript all over again? We lost that war once, I don't see why we would win now. I'm saying "we" because I am particularly for this approach, too. Don't get me wrong: I absolutely hate React, and am very cinical about the whole "server side rendering" fad (well, we've been doing server side rendering for 30 years, right?). Still, I think the overall web community simply does not care enough, so I've kind of given up.
• matheusmoreira 3y ago
  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 3y ago
    [deleted]
• shellmachine 3y ago
  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.".
• socketcluster 3y ago
  The no-code (HTML markup only) SaaS platform I'm working on seems to fit well with this philosophy: https://www.saasufy.com/ https://www.saasufy.com/ As a demo, I was able to build a chat app with it: https://saasufy.github.io/chat-app/ 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 https://github.com/Saasufy/chat-app There is no custom backend logic, all the logic is in that repo as HTML + CSS.
• oliyoung 3y ago
  `<button onclick="this.classList.add('bg-green')">` Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics. This is a terrible idea.
  • deleted 3y ago
    [deleted]
  • TheMajor 3y ago
    I just can't bring myself to like or be encouraged to use any form of approach that binds together logic and presentation. It looks and smells like terrible programming. Separation of concerns matters and, as you mentioned, more seasoned devs had decades of this being drilled into us.
  • jaza 3y ago
    Amen. Everything else in this article I can stomach. But onclick - just say no.
  • _heimdall 3y ago
    This is actually the most interesting one to me, not because I prefer it but because I want to see what others think. I've been told by quite a few Tailwind users that they much prefer it because it bring styling and markup into the same place. In their view markup and styling are so linked that splitting the code up is painful to follow and maintain. This onclick example follows the exact same argument, that the click handler is so tied to the markup that it should be inline.
• qwertox 3y ago
  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.
  • 6031769 3y ago
    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.
    • Yodel0914 3y ago
      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.
      • 6031769 3y ago
        To the devs perhaps. To the users? Not so much. So many sites these days are so bloated and slow as to be unusable. Those of us devs who chose the other approach have to work harder no doubt but our users are much happier. Isn't that the goal, after all?
        • Yodel0914 3y ago
          Surely that depends on your users. My current users value speed of feature release over almost anything else, because the system needs to adapt to their rapidly changing business rules. In my previous job, correctness was the most highly valued attribute, followed by adherence to consistent design across the org (which was large, and produced many sites that a user would navigate between all-but unknowingly). In either case, if I'd gone on a HTML purity rampage, I would not have been helping my users in any meaningful way.
• oblib 3y ago
  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.
  • TheMajor 3y ago
    This was the end result I came to as well after the bigger frameworks started gaining popularity. I work primarily solo in a single organisation with server-generated (CMS driven) websites. Yes, I could have replaced jQuery with Vanilla, but the syntax for jQuery is still so much simpler, and I care about my limited time and productivity. For me to switch over to something like React would be complete overkill. Again, as part of a bigger team, like you, I'd most likely consider a different approach.
• lwhi 3y ago
  What goes around comes around. Once upon a time these first principles were the bedrock of web development.
• gatkinso 3y ago
  Does anyone find it strange that a syntax highlighting library needs to be loaded on a site singing the praises of HTML? Sometimes I don't think the web platform takes its own original purpose seriously (presenting documents).
• joshghent 3y ago
  The author raises some interesting points. But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine. What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap. I’ve never understood these html purist arguments. As if React/Vue/Angular are desecrating this pure text language. There are other issues of far greater importance - accessibility, multi-language, browser consistency, sane defaults and easy tooling.
  • alethiophile 3y ago
    The customer probably cares if your app takes five seconds to load because of the resource size, or reliably pegs a CPU core whenever you're using it. Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.
• geuis 3y ago
  I'm on board with this conceptually. Most of the independent sites I build I still do this. But some of the things being spouted on this site are junk: <button onclick="this.classList.add('bg-green')"> Click Me </button> No. Absolutely not. Don't ever do this. This is an unmaintainable mess. I started messing with early web dev stuff in the late 90's. It took over a decade to finally get enough momentum to move people away from this kind of crap. I'm going to lovingly refer back to https://www.csszengarden.com/ https://www.csszengarden.com/. Separation of concerns is a good thing and should be used as much as possible.
• docmars 3y ago
  I love how many folks here seem to think JavaScript (and its popular libraries / frameworks) are somehow threatening to the web. This is like saying people should write native user interfaces for iOS and Android, "but no, not with Swift or Java" (respectively). All the templating, but without the language or libraries to support its interactivity, navigation, data calls, calculations, you name it. It's rather quite silly.
• JRJurman 3y ago
  A lot of these points are great, but the examples here don't help for building more complex components or pieces, that could contribute to a larger application... If people are looking for a way to build native web-components using HTML-First principles, I've been working on a library to do just that! https://tram-one.io/tram-lite/ https://tram-one.io/tram-lite/
• jcmontx 3y ago
  We are getting back on track!
• rank0 3y ago
  Why on earth do so many projects like this have to hide behind this weird inclusive language? Why can’t we be honest with ourselves and admit that our pet projects are just pet projects? Not everything has to save the world or even take any sort of moral stance at all!
• caseyross 3y ago
  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, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity. So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already? We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags: 1. `<sync value='variableName' />`: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case). 2. `<test if='variableName'></test>`: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy. That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for `<template>`), the web platform would be well positioned to cover all others in time as well.
  • smegsicle 3y ago
    whats keeping them from being provided by an import as in htmx?
  • gitaarik 3y ago
    You can already get very close to this style of writing html/js using Lit.dev
• iamcreasy 3y ago
  The article says 'For styling this can be enabled with an SPC library like Tailwind or Tachyons.' What does SPC stand for?
• dools 3y ago
  I published this article on Template Animation (aka DOM Templating) 12 years ago: https://benkoworks.com/your-templating-engine-sucks-and-everything-you-have-ever-written-is-spaghetti-code-yes-you/ https://benkoworks.com/your-templating-engine-sucks-and-ever... It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM: https://github.com/iaindooley/Fragmentify https://github.com/iaindooley/Fragmentify https://github.com/iaindooley/fragmentify-js https://github.com/iaindooley/fragmentify-js Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side: https://github.com/dgrinton/remote-standalone https://github.com/dgrinton/remote-standalone The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.
• squigglydonut 3y ago
  Thank you
• notjoemama 3y ago
  > Where possible, default to defining style and behaviour with inline HTML attributes I'm not aware that an inline style, and particularly the inline JS in their example can be nonced to prevent script and style injection. So no. I will not be following that part of the guideline. Not until the security aligns with reality.
• wackget 3y ago
  > "Prefer vanilla approaches using HTML" > Proceeds to insert JavaScript and CSS into HTML attribute. > "HTML is easy to understand" > Proceeds to import external JavaScript library which uses an ultra-obscure, totally unclear HTML attribute `_=`
• revskill 3y ago
  User/Customer needs SPA, not HTML, they just don't care the tech, lol.
• magnus-hanso 3y ago
  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.
• mediumsmart 3y ago
  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/ https://pagespeed.web.dev/ without using any divs, or, god forbid, statements like container class=“wrapper”, but that goes without saying really.
• yummybear 3y ago
  Another web development prophet with quick solutions for simple cases.
• woopsn 3y ago
  The style presented is far from the norm at the moment not just because of gate-keeping and over-engineering, but because web software is refactored and improved so many times over. For example, <summary> only supports a weird set of child tags. Personally I like <details>, but due to this constraint it is not always appropriate. Certain aspects of its native style cannot be controlled. Many event handlers are awkward encode into onclick if not impossible. "Naked" HTML requires a lot of boiler plate. The form helpers that are discouraged relate to validation, error reporting, form authorization, and localization. It's not an obfuscation layer. The encouraged styles are easier on the eyes for now, but it's easy to imagine them developing into issues which would be the subject of some ticket, or else disappearing due to general improvement to the code base (DRY principles, SoC, UI touch ups, etc).
• chalcolithic 3y ago
  Locality is underrated
• donperignon 3y ago
  This trend makes total sense given the current web panorama. I have been disabling javascript for a lot of websites during the last year, the experience is not damage at all, it's the oposite, you get a snappier navigation, no ads tracking and if you have bandwidth issues you now can browse those sites without problem. The drawbacks, some interactivity is lost, but nothing major.
• consultSKI 3y ago
  Yeah, I agree with others, not good. Recommending inline CSS is just wrong.
  • _heimdall 3y ago
    I assume that means no Tailwind as well
• pier25 3y ago
  Doesn't Tailwind have a build step?
• nedt 3y ago
  Sorry but this example is just bad <button onclick="this.classList.add('bg-green')"> Click Me </button> First of all people might have difficulties with the color green. So do you add alternatives as well, maybe with media queries, right here inline in HTML? Or do you just use the class *active* as in the discouraged example? And then you could make it even more accessible by providing aria attributes to signify the the active state. Depending on the use case you might not even need the class (you know ... leverage real html attributes). There is a reason why semantics are more important than the concrete style and why they are separated. HTML and CSS first is a great idea but show more care for your users.
• nymanjon 3y ago
  I've successfully used this pattern (HTMX hypermedia style) to create an offline-first web app SPA[^1]. One of the pages is pretty dynamic and I wasn't sure if I would need a traditional front end library to work with it. But, nope, hypermedia to the win, it worked fine without a front end framework. To build it I used my own library called HTMF[^2]. I started out using mpa-enhancer[^3] but found that that pattern is a little to janky sometimes. I think reloading a page every time on every interaction uses too many resources for a browser especially when you use a phone that doesn't have as much power as a laptop. But overall I find the pattern very easy to use and keeps the complexity down. I think some of the issues with traditional SPAs is that they have a lot of state and state is nonlinear in complexity. But using templating systems makes the complexity more linear in nature. Also, I find libraries like React to be overly complex for what it does, see above. The way React works is just odd and counter intuitive. All for problems that are easy to solve. I do think there are places for a React-like library is needed but those are for websites that are inherently highly state-based. But most websites aren't state-based even ones that appear to be state-based at first. The websites I work on are usually just forms and forms are pretty powerful and can get you a long ways before you need to go outside of that paradigm. [^1]: https://github.com/jon49/Soccer https://github.com/jon49/Soccer [^2]: https://github.com/jon49/htmf https://github.com/jon49/htmf [^3]: https://github.com/jon49/mpa-enhancer https://github.com/jon49/mpa-enhancer
• YetAnotherNick 3y ago
  It's easy to preach this. I went to the author's projects using the link in the bottom and found the first project[1] to be using 4 MB of CSS and 1 MB of javascript in the landing page, which is just a static signup. In big projects, the generality of codebase and faster option to do one off tasks matter more rather than best design for the current task. And it is lot harder to have making codebase small or without libraries as a requirement. [1]: https://clerkmoney.com/users/sign_in https://clerkmoney.com/users/sign_in