[HN Gopher] HTML First
___________________________________________________________________
HTML First
Author : tonyennis
Score : 496 points
Date : 2023-11-12 16:00 UTC (6 hours ago)
(HTM) web link (html-first.com)
(TXT) w3m dump (html-first.com)
| ricardobeat wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| zlg_codes wrote:
| Could you expand on this? Class names in CSS are just as
| important, if not moreso, than naming variables in
| typical programming.
|
| Back in the late 90s and early 2000s, the dominant
| ideology is to use semantic class names, e.g. ".sidebar"
| instead of ".blue_bar" or similar. Essentially, don't
| describe how something _looks_ with its name.
|
| Even when building JS apps, I use CSS classes
| semantically with ".selected" ".menubar", etc.
|
| I am interested in reading your philosophy on CSS
| classes.
| zztop44 wrote:
| The exception is when using a framework which isolates
| CSS at the component level, in which case your class
| names don't matter anywhere near as much because you'll
| only ever see them alongside the corresponding HTML.
| mock-possum wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jbverschoor wrote:
| 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 wrote:
| (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...
| usrbinbash wrote:
| > "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 wrote:
| Yep. I've said this often but whatever:
|
| JS, CSS, and HTML aren't concerns, they are technologies that
| have cross-cutting concerns.
| pc86 wrote:
| 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 wrote:
| I don't think you'd mix in React with this approach.
| pc86 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| zlg_codes wrote:
| I think the GP is referring to when people misunderstand
| the scope of their project, start without a framework,
| and the complexity reaches a point where the framework
| would actually help.
|
| I'm not sure what that looks like, because if it gets
| complex enough it's a sign I need to refactor, imo.
| moritzwarhier wrote:
| I once built a project-tailored combobox using Alpine.js
| - this is about where it breaks down.
|
| It worked, it was a lot of fun to write because it went
| really fast, even with some bells and whistles. Whole
| thing was my escape hatch when datalist attribute didn't
| work. It also worked well.
|
| Alpine JS feels like a simpler version of Vue 2 without a
| build step and without any of the complex or confusing
| stuff (and of course with a focus on HTML not rendered by
| JS).
|
| But when I saw what this turned into as a BE colleague
| copied it to the next form, making some adjustments... oh
| my, I prefer external and reusable JS (or a JS-first
| approach to templating, like React) any day.
|
| Still, Alpine is really awesome for minimal interactions
| and simple JS.
|
| When working outside React, it's hard not to miss it for
| the simplicity of doing everyday stuff inline in the
| HTML.
| alethiophile wrote:
| Alpine is primarily designed to be reused via server
| templating. You use a single template per component to do
| the in-HTML side, using the server template's facilities
| to handle variations as necessary. Then you can factor
| out complex common behaviors into Javascript using
| Alpine.data.
|
| It definitely does have a maximum size of project it's
| suitable for. In particular, it's thoroughly individual-
| component-based; changing anything outside the component
| requires tacking on non-native hacks, and doing a full
| interactive app with it would be a painful exercise. But
| for adding simple interactivity to a primarily server-
| rendered web page, I've found it to be quite useful.
| evantbyrne wrote:
| It might be easier to staff for. But developing a React
| frontend takes way more time than just server rendering
| HTML and layering in JS for the vast majority of use cases.
| willsmith72 wrote:
| that's just speculation. I can say also anecdotally from
| my experience, developing a react frontend takes way less
| time.
| tambourine_man wrote:
| >But you're already using it for the rest of your site
|
| I'm not
| DustinBrett wrote:
| Also with "onlick" you have to lick it to trigger the event.
| globalise83 wrote:
| I see you are also a fan of lickable.js
| debo_ wrote:
| What are HNs policies around tongue-in-cheek comments?
| tempodox wrote:
| Tongue-in-cheek is OK after a lick.
| seadan83 wrote:
| I thought the point of the article was more to avoid react if
| all you want to do is change background color. Thus more: don't
| use react in the first place, rather than: here is how to use
| less react.
| 8organicbits wrote:
| 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.
| ChrisAntaki wrote:
| These vanilla JavaScript features are pretty great IMO
|
| - https://developer.mozilla.org/en-
| US/docs/Web/API/Document/qu...
|
| - https://developer.mozilla.org/en-
| US/docs/Web/API/Document/qu...
|
| - https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| - https://developer.mozilla.org/en-
| US/docs/Web/API/Element/ins...
|
| - https://developer.mozilla.org/en-
| US/docs/Web/API/EventTarget...
|
| - https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
| calvinmorrison wrote:
| Tbf they got better. Jquery basically existed because the js
| builtins were hairy
| HerrBertling wrote:
| 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,...)
| Dunedan wrote:
| 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.
| irrational wrote:
| I love that people are finally coming around to abandoning the
| build step.
| corethree wrote:
| React was designed to solve all these problems. Now these
| problems are used to solve react.
|
| Programming, like life, is a flat circle.
| robinhood wrote:
| No, it was designed to address problems that were not solvable
| by the then-current state of simple technologies.
| corethree wrote:
| 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 wrote:
| 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 wrote:
| 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?
| evantbyrne wrote:
| > The dom was a failure, react was a failure. What do you
| think going back to the DOM will do?
|
| It'll give me that extra 50% effort back. Although I've
| used React for years, I have never been on the bandwagon.
| Having built many React SPAs with different teams at this
| point I'm confident it has always been a step backwards.
| corethree wrote:
| Yeah but react was designed to address a problem. I don't
| know if you recall but people were complaining a lot back
| then. There were tons of frameworks attempting to solve
| the issue. Only react came out in top.
|
| By stepping back we are just going back to the same
| problem.
|
| The next abstraction will attempt to solve the same
| problem again. Very likely in a similar way react failed,
| the next abstraction will introduce new issues and there
| will be another trend to go backwards again.
| evantbyrne wrote:
| I don't have fond memories of early React; It was
| extremely verbose not having hooks until relatively
| recently, build tools were necessary but a horrible mess,
| and it was falsely advertised as being faster than
| vanilla JS. Hype around Facebook carried React. It has
| improved massively since then, but so has vanilla JS. I
| don't see a transition away from React as a step back at
| all. React made rendering new elements client-side and
| attaching events cleaner, but that was never a hard
| problem per se and we have web components now.
| corethree wrote:
| I never said a transition back from react is not an
| improvement. Again you're not getting it.
|
| I'm saying we had problems with vanilla js initially and
| we've never moved forward. The fact that we are going
| back to vanilla js is reopening all the old issues are a
| sign that we are in stagnation.
|
| Nothing has changed. It's a circle of attempting to
| improve and failing.
| infamia wrote:
| > The dom was a failure, react was a failure. What do you
| think going back to the DOM will do?
|
| Facebook (rightly) said the VDOM was needed at because of
| rough edges around the performance of DOM implementations
| in assorted browsers. The DOM has improved over the past
| 15 years or so to the point where things like HTMX and
| AlpineJs are viable for more use cases. React and the DOM
| have not failed, they are tools that have their uses and
| limitations. Looking for one solution to rule them all is
| ultimately an exercise in futility and disappointment.
| Instead we should be looking at ways to integrate React
| and hypermedia so they interoperate more smoothly (e.g.,
| web components or similar solutions).
| corethree wrote:
| No. The entire front end ecosystem is simply cruft added
| onto something that was fundamentally designed for
| something else. The "improvements" are attempts at fixing
| a flawed design while maintaining the old core design
| Similar to the cruft on top of C++.
|
| >Looking for one solution to rule them all is ultimately
| an exercise in futility and disappointment
|
| React and the dom were also exercises in futility and
| disappointment. They didn't seem that way at the time but
| as time went on it became clear what their problems were.
| The same thing can be said of htmx and alpine and
| whatever big framework that comes next.
|
| Additionally who says their can't be one solution to rule
| them all? You think if your quotation eludes to some
| fictional story of lotr suddenly it makes sense? There is
| nothing in reality or logic that says we can create a
| design that can do better than all the apis that
| currently exist.
|
| This idea that you can only male tools that do one thing
| well is fundamentally illogical. There are tons and tons
| of tools that do multiple things well. Take your car. It
| doesn't just get you from point a to point b. It air
| conditions you, it plays music... It provides safety, it
| gives you directions.
| infamia wrote:
| I think this is because HTML, CSS, vanilla JS, browser DOM
| implementations, and networks have all gotten better.
| Whereas the complexity/churn around JS tooling (and to a
| lesser extent React) has grown. Additionally, the overuse
| and abuse of React, to the point people are making largely
| static sites with React, which is largely a total waste of
| time. This has caused people to take a second look at their
| options, which should be viewed as totally natural.
|
| I don't think of it as "going backwards", so much as
| reassessing and questioning the tools we are using and
| using the best one at hand. I don't know of anyone who
| suggests using hypermedia for all applications, just use it
| where appropriate and use React when simpler technology
| falls short.
| pphysch wrote:
| How was React designed to "avoid the build step" or "make View
| Source useful"?
| corethree wrote:
| React was designed as an abstraction layer on top of the
| source. Why?
|
| Because the source was too complex.
|
| Now we want to expose the source and get rid of the
| abstraction... Why?
|
| Because the abstraction is too complex.
|
| Recurse and repeat.
| pphysch wrote:
| There won't be a repeat. WASM is a clearly better
| compilation target than JS, and browsers have greatly
| improved the "vanilla" DX.
|
| TypeScript ecosystem is the Enterprise Java of this decade,
| except it's built on shakier foundations, i.e. you can run
| some ancient JVM, but good luck relying on an ancient
| browser version & node dependencies. There will probably
| still be tons of job-security in the next couple decades,
| but it's not forward-looking technologically.
| corethree wrote:
| Building a language and a framework on top of wasm is
| just another abstraction.
|
| Ironically you mention the jvm which further proves the
| existence of the flat circle.
|
| We've done it before... We will do it again.
| cphoover wrote:
| Yes, I remember when Microsoft FrontPage was the go to
| wysiwyg editor for web development along with Dreamweaver
| most styles were added inline.
|
| At some point wysiwyg editors fell out of favor as they
| generated both unmaintainable styles and markup.
|
| Style sheets took hold and the insanity that was inline
| styles were dropped in favor of external style sheets.
|
| Today we have tailwinds.css and inline styles are coming
| back in vogue.
|
| Wysiwyg editors are coming back in the form of code
| generators that convert designs into react components.
|
| This author is even a proponent of inline event handlers
| which were the standard way of doing things before
| JavaScript really became a powerful language and added
| "addEventlistener".
|
| Flat circle repeated over and over again.
|
| Part of me wonders if these authors are just too young to
| remember those days. Otherwise why wouldn't they mention
| the historical context when writing these kind of articles?
|
| It's funny when younger people espouse these new ideas as
| new and revolutionary when really they are a return to
| older patterns that fell out of style for whatever reason
| and are now being resold with different packaging.
| corethree wrote:
| There's no theory behind program design and organization.
| We have no formal definition about whether one design is
| better than the other.
|
| Thus, History is doomed to repeat itself as software
| technology moves horizontally forever, with practitioners
| never knowing if the current abstraction was better than
| the previous one.
| ativzzz wrote:
| How poignant - another post on the front page -
| https://news.ycombinator.com/item?id=38236607
|
| Top quote in the article
|
| > I don't think computing is a real field. It acts like a pop
| culture, it deals in fads, and it doesn't even know its own
| roots. And worse than that it does not know about the really
| good things that were done in the past. -- Alan Kay
| hypertexthero wrote:
| 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
|
| From the old-school Introduction to Web Design:
|
| https://web.archive.org/web/20210414030104/https://www.cours...
| tithos81 wrote:
| This is perfect for Svelte
| apavlinovic wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mixmastamyk wrote:
| Textbook ad-hominem mixed with a side order of appeal to
| authority.
| zlg_codes wrote:
| Yeah, kinda gross. It takes zero effort to call someone's
| writings "blogspam". Would love to see comment OP's website
| so we can compare it to some random "agency".
|
| Probably some "entrepreneur" chud.
| Jtsummers wrote:
| 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
| gbro3n wrote:
| Alpine.js would have been a better recommendation according to
| the authors advice as it is straight forward JS plus HTML
| attributes.
| dartos wrote:
| 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 wrote:
| 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 wrote:
| Maybe the author swapped the encouraged and discouraged.
| recursivedoubts wrote:
| yeah, kinda.
|
| source: I'm the creator of hyperscript.
| Jtsummers wrote:
| 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.
| athrowaway3z wrote:
| I suspect this is a 'List of tips' written explicitly to
| promote hyperscript.
|
| Its example is also pretty weak. Vanilla solutions (Tip 1)
| works just as well:
|
| <div> <input type="text"
| oninput="this.nextElementSibling.innerText = this.value"/> <div
| id="output"></div> </div>
| assimpleaspossi wrote:
| note that the <input> tag does not use and does not need a
| closing slash and never has in any HTML specification.
|
| https://html.spec.whatwg.org/dev/embedded-
| content.html#the-i...
| josephg wrote:
| Yep. It's one of a handful of _void elements_ along with
| <img> and <br>.
|
| Also using a slash to self close a tag is not part of the
| html spec and it never has been part of the spec. The
| browser doesn't know what that means on any tag. If you
| write <div /> the browser ignores the slash and thinks you
| still haven't closed your Div.
| zlg_codes wrote:
| I'm adding context to this because you're only telling
| part of the story:
|
| self-closing tags are necessary for void elements in XML
| and XHTML, both technologies that are still supported on
| the Web. Since XHTML processes HTML as XML, it forces it
| to be well-formed. Unlike HTML, which has all sorts of
| tag-soup and quirks modes and other things, because it's
| lax in its syntax.
|
| Void elements lacking the need for a closing tag or
| closing slash is one of the weird edge cases in HTML.
| While it's not in the HTML spec, it may still be seen in
| the wild in XML and XHTML documents and is not
| _universally_ bad or unsupported.
| Jtsummers wrote:
| Which makes the example even more egregious. There are
| certainly better ones that:
|
| 1. Can't be easily done with vanilla JS and so can justify
| using a library.
|
| 2. Don't need a library with a DSL in direct opposition to
| the claimed principle (avoid DSLs).
| graypegg wrote:
| 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 wrote:
| >> 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| gemstones wrote:
| That applies to backends equally, but you don't get
| thinkpieces on how that makes it a great idea for frontend
| devs to avoid all those silly DTOs and design patterns that
| complicate the server code.
| ralmidani wrote:
| I'm not able to make a page look nice (or even decent) without
| a CSS framework. But I think I'm at least OK at understanding
| how to make the interactions and workflows follow the
| "Principle of Least Astonishment".
|
| In other words, I'm not scared of UX in general, just not
| confident in my current abilities in UI (which is just one
| aspect of UX).
| smallerfish wrote:
| Here to bust your assumptions. I skew backend but love CSS, and
| am one of the better UX engineers I know of. I also dislike
| javascript a lot, and find that the htmx approach cuts a
| significant amount of complexity out of your app (e.g. your
| views can talk directly to your daos.)
| gemstones wrote:
| I've met enough people that aren't like you that your lived
| experience, real as it may be, doesn't really change my
| opinion much.
|
| For every one of you who isn't scared of CSS there are like
| 40 people into HTMX that make bad UXs even by the standards
| of internal company tooling.
| yyzzx wrote:
| Similarly for every React/$oftheday dev who creates a
| snappy, race condition free, spinner free, app that feels
| almost as snappy as the web prior to React/$oftheday, there
| are 40 who create sluggish, unmaintainable tyre fires.
| zlg_codes wrote:
| What literature exists on UI and UX that isn't
| condescending or clueless in tone?
|
| Interfaces are as unique as humans are. There's a reason we
| have emacs, vim, _and_ Notepad.
| kevlened wrote:
| Refactoring UI fits those constraints. While it's by the
| creators of tailwind, it doesn't make assumptions about
| the css you use to achieve your desired UI.
|
| https://www.refactoringui.com/
| zlg_codes wrote:
| To be fair, most UX "experts" are too busy chasing interfaces
| that are "inclusive", i.e. built for toddlers.
|
| Show me a powerful program with a "good" UI by modern standards
| and I'll show you a mess. VS Code is a prime example.
| m-a-r-c-e-l wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| You're absolutely right. We had additionally one common
| JS/CSS file each.
|
| Every approach has its pros and cons.
| varun_ch wrote:
| 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 wrote:
| 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 wrote:
| I think what the OP meant is: Tailwind requires a build step
| to extract use classes. Otherwise you need to ship all of it.
| graypegg wrote:
| 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.
| moritzwarhier wrote:
| This was only the case in Tailwind 1 and heavily
| discouraged by the documentation, except for development.
|
| Tailwind requires a build step and shipping the 1.x
| development build was explicitly not meant for production.
|
| Trying to use tw 1 like this without a build step, you
| can't even define a custom color scheme.
|
| If this is what you want, I'd use a library that actually
| supports this. Maybe tachyons? But tbh, without the build
| step I'd consider using Tailwind at all a massive mistake.
| Then I'd prefer handwritten CSS.
|
| Custom properties should make sth like this a lot more
| viable though. I'm sure there are libraries that better fit
| this use case, if you want to use a CSS library.
| JimDabell wrote:
| > Maybe if you use a CDN, so hopefully the user might have
| a local cache of it from somewhere else, that can be
| avoided?
|
| Browsers partition caches by origin now for privacy
| reasons, so this is no longer possible. If the user doesn't
| have it cached from your website, they don't have it
| cached.
| robinson7d wrote:
| Did your experience involve the (recommended) build step? It
| uses, at least last I checked, a purgeCSS step to remove
| unused rules and decrease the css size.
| epiccoleman wrote:
| Tailwind has a standalone CLI which can be used for the build
| step. I do sort of agree that it's a bit of an odd
| recommendation in the context of this article, but the build
| step can be extremely minimalistic, and another nice thing is
| that the results are still inspectable CSS.
|
| I use tailwind on my personal site, which is otherwise entirely
| just vanilla HTML, and it doesn't feel very intrusive to run
| the CLI in watch mode when I'm writing styles.
| usrbinbash wrote:
| The only thing a build step changes about CSS/JS resources of
| this kind, is a minimization of the libs...which is entirely
| achievable without building, by simply including the already-
| minimized version.
|
| I think what the article is about when it says to steer clear
| of builds, is complex builds, where transpilations and similar
| changes in format _have_ to happen, in order for the page to
| work.
| lolinder wrote:
| > The only thing a build step changes about CSS/JS resources
| of this kind, is a minimization of the libs...which is
| entirely achievable without building, by simply including the
| already-minimized version.
|
| This isn't true, though--Tailwind's build step isn't just
| stripping out white space, it removes unused selectirs, too,
| which can't be done in advance.
| usrbinbash wrote:
| I wasn't aware of that, thanks :-)
| kyleyeats wrote:
| I made an atomic CSS library that doesn't need a build step, if
| anyone wants one (spoiler, nobody does):
| https://casscss.github.io/cass/
| amenghra wrote:
| Imho, bullet points on the border box seems weird to me
| (https://ibb.co/d0sDsQ2).
| kyleyeats wrote:
| Thanks for the note! The left padding and margin situation
| on the ul is the bane of my existence.
| amenghra wrote:
| Copy what other more popular frameworks are doing :P
|
| I haven't looked at your css, but maybe changing the box
| model could help?
| rs_rs_rs_rs_rs wrote:
| You don't ship Tailwind...
| isodev wrote:
| The OP was making a point that the build step should not be
| required to run/display a web app.
|
| For example, tailwind without a build step is just the entire
| library. This means one can go a long way and even have a
| functioning web application without introducing a build step.
|
| I would say stripping unused CSS is in the same context as
| optimizing images, fonts etc perhaps generally a "cleanup &
| prepare assets for production" step.
| tabacitu wrote:
| I read it the same way, yes. Good point with the cleanup: -
| it's one thing to need to run build for it to work; - it's
| another thing to run build to make it smaller;
| MrJohz wrote:
| Tailwind doesn't exist without a build step (at least since
| v2) -- the whole point of Tailwind is that it _is_ a build
| tool, an alternative syntax for writing CSS.
|
| There's a kind of development version where that build step
| runs in the browser on page load, but it's still a build step
| in the sense of generating all that CSS dynamically, and it
| will produce a poor experience for a user if you try and use
| it in production.
| nathanfig wrote:
| Deno Fresh uses Twind, which avoids the build step:
| https://twind.dev/
|
| But IIRC it doesn't offer quite everything full Tailwind does.
| In general I was frustrated with Fresh for not being up-front
| about the fact that it is largely built on Preact and Twind,
| and you must buy into those libraries first.
| audnaun252 wrote:
| Article doesn't even have anchor tags
| thiago_fm wrote:
| 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 wrote:
| 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 wrote:
| 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 which takes
| this no build approach and makes it easy to build portable
| applications, using Starlark running in go to configure the
| backend.
| 101008 wrote:
| I used this exact approach: Django backend, Django templates
| and htmx. It has been a delight.
| npilk wrote:
| This is what I've used for my last couple of projects,
| including 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.
| LudwigNagasena wrote:
| 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 wrote:
| 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 wrote:
| 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 _web_ app.
| dartos wrote:
| 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 wrote:
| 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.
| ativzzz wrote:
| I think you are totally correct- we should we building them
| as electron apps instead :)
| jonkoops wrote:
| I agree in principle that HTML is the best option for a good
| user-experience, but it quickly breaks down in terms of
| developer-experience and maintainability. However, we don't
| need to compromise on either by using a solution like Qwik[1].
| Where the page progressively becomes more interactive with
| JavaScript, and doing as much work as possible on the server
| beforehand.
|
| 1. https://qwik.builder.io/
| zlg_codes wrote:
| > nowadays we have an abundance of tutorials, courses,
| conference talks and open source projects that can help
| autodidacts to learn anything related to web development.
|
| That method was horrible, as someone who struggled with poor
| knowledge sources until HTMLDog and MDN became a thing.
|
| ...Conference talks? lmao your class is showing, the average
| self-taught hacker can't afford to go to those. Anyway, View
| Source is a good way to learn how to do something you see for
| the first time. It's a necessary feature to double-check what's
| being sent to the browser when you're developing, too, and
| keeps website operators honest by giving you a way to inspect
| how they build their site.
|
| Personally I think webapps are the wrong solution for a ton of
| problems, but the industry won't accept that until the bottom
| line is affected. I'm waiting for native apps that communicate
| over the same commercialized protocol. QUIC but its own piece
| of software instead of co-opting the Web.
| xhrpost wrote:
| > Where possible, default to defining style and behaviour with
| inline HTML attributes
|
| Wow, have we just come full circle after 25 years?
| FFP999 wrote:
| I literally--literally, not figuratively--facepalmed when I
| read this.
| vorticalbox wrote:
| This comment or that part in the link?
| croes wrote:
| And it isn't even done in the example.
|
| >class="bg-green"
| laurent123456 wrote:
| Thankfully he got the `onlick` attribute right.
| amjnsx wrote:
| These tailwinders are everywhere these days.
| ilrwbwrkhv wrote:
| 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.
| alib wrote:
| I love this. Could you please consider changing the example from
| a clickable div - which is an accessibility nightmare - to a
| button?
| tonyennis wrote:
| Good catch - fixed.
| zlg_codes wrote:
| 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?
| andai wrote:
| 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....
|
| This is my homage to the old SodaPlay Constructor. (Never made an
| editor, sorry!) Feel free to view-source!
| mlhpdx wrote:
| I don't believe the author is advocating for single file
| systems, but I don't want to speak for them.
| xg15 wrote:
| 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 wrote:
| <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 wrote:
| 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 wrote:
| 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
| gardenhedge wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Your suspicion is incorrect. Currently running 10 or so
| codebases with 8 devs using this approach. Thanks for
| catching the typo
| codeptualize wrote:
| 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 wrote:
| Coming soon
| codeptualize wrote:
| Good old times, I used to have a file watcher that would
| refresh the page on change using a browser extension, not
| anywhere near the convenience of HMR though haha.
|
| I do agree with you, it's why I'm skeptical about the results
| of following this advice. I vividly remember how much things
| sucked, and obv the web has come a long way, but the tools
| have gotten even further. If I see how much mileage I get out
| of the tools I use on the daily, I would not be nearly as
| productive without them, and produce a lot more buggy,
| inaccessible, and shitty apps.
| wheelerof4te wrote:
| "I really don't see how these would work in anything other than
| very basic scenarios, even less how they would achieve the
| objectives."
|
| Well, what are the objectives? If they are complex, so should
| the code be complex. That's the nature of our job. By adding an
| advanced framework you up the complexity by default. Instead of
| adding more code, you add more build dependencies. This is
| especially wasteful on websites.
|
| In my opinion, people today are afraid of writing code.
| Everyone wants some framework to write code for them. That is
| not how we push our industry forward.
| codeptualize wrote:
| In some sense I agree, I am very mindful of the dependencies
| I add and I am not afraid to write something custom if that
| better fits the situation.
|
| But this article is not showing me how to do that and the
| things listed are not going to have an impact on the
| complexity of my projects as these basic things are solved
| quite well.
|
| > By adding an advanced framework you up the complexity by
| default
|
| If you know your project will remain simple then by all
| means. That's often not how it works though and then you end
| up writing a framework yourself once the scope gets increased
| and features are added.
|
| Adding to that that using a framework gives you so many
| things for free. There are so many aspects to a good website
| and leaning on a group of people specialising in all those
| things is often a smart move with better outcomes.
|
| I think the initial complexity might be a little bit higher,
| but there often is a big return on investment later on, and
| also immediately in terms of productivity.
|
| I'm not going to stop you from not using a framework, I think
| it's great to experience it, have been there many times
| before, got burned (badly), and now make different decisions.
| jaapbadlands wrote:
| No one is afraid of writing code, we're afraid of maintaining
| code, and solving tedious and repetitive problems that
| already have solutions. Frameworks abstract complexity, which
| in practical terms decreases the complexity I personally have
| to deal with, and shifts the complexity to the minds of a
| team of open-source developers who support the framework or
| library in parallel. Abstraction is exactly how we push the
| industry forward, not by building less, more basic, and
| shittier applications in a some faux-noble quest to use
| inline event handlers.
| wheelerof4te wrote:
| "No one is afraid of writing code, we're afraid of
| maintaining code, and solving tedious and repetitive
| problems that already have solutions."
|
| Then, enjoy maintaining React apps once React inevitably
| bites the dust and ends up in the JS framework graveyard.
| codeptualize wrote:
| When there are so many projects that run on React, and so
| many companies rely on React, it's inevitable that it
| will be supported for a long time to come, even if it
| would go out of fashion.
|
| And speaking from experience maintaining React apps is
| quite nice. React has great backwards compatibility, and
| where it doesn't there are usually codemods available.
| Dependencies can be tricky, but that's not exclusive to
| React.
|
| Also don't forget React evolves, backed by multiple #huge
| companies, and still innovating.
| pault wrote:
| The chances of this happening before your project is
| obsolete are pretty slim.
|
| Edit: it depends on what you mean by "bites the dust". If
| you mean "isn't cool anymore" then I'd say that's kind of
| irrelevant. If you mean "isn't supported anymore", I
| don't see that happening any time within the next decade
| at least. Rails isn't cool anymore but it's still
| supported and lots of people are still (more or less)
| happily using it at their day jobs. React is so widely
| used it'll be kept on life support long after it has been
| supplanted by something better, if and when that happens.
| codeptualize wrote:
| Another good example is jQuery, the last release was 2
| months ago, and there is plenty of activity on GH.
| fsckboy wrote:
| I love maintaining and cleaning up code (I will insist on
| cleaning up according to my taste even if it already
| works fine in production, just like when I carve the
| turkey I eat some crispy and fatty pieces hot from the
| oven) It takes a great weight off my short term memory
| and ADD that I know that the code already worked, so if
| it stops working, I did it, recently.
|
| But here's the thing, hot-shot devs, and hot-shot dev
| wannabes look down on maintenance; and humans are social
| creatures, me included. So I'm not going to do a job for
| you that you look down on, unless you carry me in (and
| out) on a sedan chair.
|
| Same for writing doc, I'm good at it and enoy it, but
| there's no pleasure in doing something that other people
| don't really value.
| tabacitu wrote:
| Why? Why does it need to be good for big projects in order to
| be good practice?
|
| I'm genuinely asking. I never understood this argument that
| people bring.
|
| In my view, the web is 95% small to medium projects. Most
| technologies should be focused on that - simple solutions for
| simple projectS. Add complexity later.
| codeptualize wrote:
| I'd be more than happy to see small or medium projects and
| how these tips improved them. Any real world examples would
| be great.
|
| I would also add that a lot of us do work on the bigger
| projects, which makes sense as bigger projects require more
| people. So at least in my life, and I expect many others, it
| is quite relevant.
|
| I also don't believe the article qualifies that these tips
| are only for small to medium projects, I'd read it very
| differently if it did, but I would still like to see some
| real world examples though.
| xgb84j wrote:
| Because in practice there is little value in making easier
| things easier. While 95% on the web are small projects, 95%
| of work is done on large projects.
|
| Many developers also dislike using many different frameworks,
| because that would require more learning. If you have to
| choose one technology it's better to use one where you can do
| everything. Not one where you can do 95% really fast, but 5%
| not at all.
|
| I personally always use "complex" frameworks like Angular or
| React because sooner or later feature requests come in, where
| those frameworks pay off. On average it saves time for me to
| always use those frameworks. That might be different for you
| depending on the work you do.
| codeptualize wrote:
| This. Even for basic websites you benefit from some form of
| templating/components for example to get the nav & footer
| on each page.
| timeon wrote:
| Even basic websites? It is developer vs user then.
|
| I think otherwise. I.e.: blog shouldn't be web app just
| because it's content management is.
| codeptualize wrote:
| Not at all. There are a lot of frameworks that support
| static exports and/or pre-rendering. Often those produce
| incredibly fast results, in many cases faster than hand
| rolled solutions.
|
| If you use a CMS you have already a templating situation
| and dynamic content, using a framework, or jamstack like
| situation is not that different, depending on the
| specifics it might produce faster results.
| zilti wrote:
| You don't need a frontend framework for that. Fuck people
| who do. They're the reason most websites are slow as
| molasses on my three year old phone, despite them being
| very basic sites. Just stuffed to the brim with
| unnecessary bullshit.
| MrJohz wrote:
| While I agree that there is probably an overuse of
| frontend rendering when templating in the backend would
| be fine, I suspect most of the problems you see have
| nothing to do with that. In my experience, the number one
| issue with slow sites is an overuse of trackers and
| advertising that drags everything down.
| codeptualize wrote:
| If you statically export you won't even notice, and when
| navigating it will actually be a lot faster when only the
| content is replaced..
|
| Have you checked this is the reason? not slow network?
| and not ads/analytics and blocking assets? That's not
| exclusive to frameworks btw, and probably less likely as
| most optimize these things for you.
|
| The website that is linked originally has a bunch of
| blocking assets.. lighthouse score is not amazing either.
|
| Just like the original article, you might want to test
| your assumptions a bit more.
| squidbeak wrote:
| Do you have any data to support that 95% claim? As big as
| FAANG and other huge development teams are, it seems to me
| it's still only the tip of the pyramid, with the
| overwhelming majority of people in the industry working
| full time on small or midsized projects. It'd be
| interesting to see some concrete info on it.
| josephg wrote:
| I suspect even at Google a lot more than 5% of effort
| goes into small to midsized projects. Bazel, ninja,
| protobuf, grpc, the API documentation website for Gmail,
| VP9, the Google transcode api, takeout, various corp
| network tools & services and so on.
|
| The big projects are of course important. But even chrome
| needs a simple little website with a download link.
| xgb84j wrote:
| That's a good point. I personally always like Angular and
| React, because even with most simple projects there is
| this one feature that is so ridiculously complicated that
| making it slightly easier to develop and maintain is
| important to me. I'll gladly write thousands of lines of
| boilerplate just so I make it easier for me to succeed in
| developing this one endboss feature. If you do not have
| at least this one insane feature, Angular and React are
| definitely overkill.
| xgb84j wrote:
| The point where frameworks like Angular and React pay off
| and what I think of as complex projects are those where
| there is a some nontrivial feature. This coukd be a
| project with 1 developer working on it for 6 months.
|
| For example a static page with a booking process with
| various entry points on the website, which slightly
| change the booking logic. Also you can book as a new
| user, as a logged in user, for somebody else etc. Also
| the logic is changing at regular intervals, because the
| business owner is trying different things out.
|
| Using Angular with reactive forms makes this easier to
| develop, maintain and hand off to other Angular devs.
|
| While it makes writing the static parts of the website
| more complicated, it makes developing the booking process
| easier. And overly complicated business processes are
| what is mentally challenging for me. This is where I want
| all the help I can get. Writing static pages is something
| I can do in any framework even when I am tired. Making
| this part easier or reducing boilerplate is nice but
| doesn't make me much happier. Being able to build
| ridiculously complicated forms without my head exploding
| does :) Of course if you work on projects with relatively
| straight forward requirements there is 0 advantage in
| using Angular or React for you. It always depends on the
| type of work you do.
| andybak wrote:
| The "big" projects can do what the hell they want. They can
| afford to throw a ton of money at a problem.
|
| The small projects are where the people I care about are
| struggling.
| ceuk wrote:
| Big project =/= Big company
|
| e.g. WhatsApp back before the acquisition
|
| Making it easier for people to build big, complex apps
| doesn't favour large organisations with lots of
| resources. The opposite in fact.
| andybak wrote:
| nb I'm not agreeing with your original hypothesis.
|
| However I'm taking about even lower down the food chain
| than this.
| MrJohz wrote:
| Are people really struggling at that level, though? It
| has never been easier to write a complex page with
| minimal Javascript - there are more and more HTML
| elements that do what you expect (expandos and modals as
| some recent examples), Javascript is cleaner and more
| consistent across browsers (you really don't need jQuery
| anymore), and CSS is more powerful but also so much
| simpler (flex+grid solve so many problems).
|
| Then if that's not enough, you've got things like HTMX if
| you're keen on doing everything in terms of html
| templating, you've got tools like Svelte if you want an
| isolated chunk of dynamic UI in a mostly static page,
| you've got bundlers like Vite that just work without any
| configuration if you get to the point where you need a
| build step, and you've got a multitude of lightweight
| frameworks for the next step.
|
| And on top of that, pretty much all the old ways still
| work. The browser is an incredibly stable environment!
| Outside of a handful of security-related removals, if it
| got into a mainstream browser, without a feature flag or
| an explicit "experimental" warning, it's pretty much
| there for life. So if you want to go back to the old
| ways, there's not much stopping you - but a whole bunch
| of quality-of-life development improvements along the way
| to make things even easier than they were back then.
| hinkley wrote:
| We have forgotten the old lessons. Backend first was a defense
| mechanism against people who believe their eyes and not the
| experts.
|
| When you make a product that looks like it works but doesn't,
| they don't understand. They put you on a path to overpromise
| and underdeliver.
|
| One of the lesser known features of unit tests are that they
| give the code that management can't see more QA prior to being
| wired up. They narrow that awkward window from first paint to
| shipping.
| csbartus wrote:
| Agree.
|
| I've created my first website in 1999 with plain HTML, CSS,
| vanilla JS, hosted on Geocities.
|
| Since then I've been using PHP/WordPress/Yii/Laravel,
| Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to
| create both sites and apps.
|
| With React / TSX components / CSS-in-TS / Effects / Context I'm
| home. Finally a fully fledged programming language for the web
| / front-end. A language made explicitly for the front-end,
| built om modern principles like functional, reactive
| programming.
|
| Now I can do software development. Before that, with HTML, CSS,
| plain JS, PHP it was ... just hacking, nothing else. (Rails was
| good for full-stack, was not shining on the front-end)
|
| I'll skip frameworks when the web stack will be ready for the
| apps, too. Now it's (perhaps) good enough for sites, I should
| admit.
| squidbeak wrote:
| Perhaps web publishing shouldn't be presupposed to be
| 'software development'?
| zztop44 wrote:
| But very often it is software development. And there isn't
| always some bright line between them.
|
| Like it or not, the web is an excellent platform for
| delivering software applications to users, especially one-
| off or infrequently used applications.
|
| Let's use software development tools, rather than web
| publishing tools, to develop that software.
| zilti wrote:
| Hopefully WASM will fill that area, and browsers can go
| back to being browsers.
| gijoeyguerra wrote:
| The entire WWW is the example
| ln_00 wrote:
| Aem edge delivery service, Hey.com
| selimnairb wrote:
| Even if this isn't always practical for larger projects today,
| I would argue that this should "ultimately" be the goal---at
| some point the "standard" browser runtime should be expressive
| enough to not require lots of tooling to make most apps.
| MrJohz wrote:
| I'm not sure that's always the case -- we don't expect
| assembly to be a high-level language after all! The more
| specific and batteries-included the browser becomes, the
| harder it is to go off the beaten track. My standard example
| here is date pickers -- theoretically it's just a simple
| component, and yet there is no one-size-fits-all option. What
| works for booking an appointment won't work as well for
| putting in a date of birth. What works for a date of birth
| won't work if you're trying to book a set of nights in a
| hotel. You might want to include prices for individual days
| directly in the date picker. You might want to show which
| days are valid and which aren't. You might want to show
| several months, you might want to show just a week.
|
| I don't necessarily disagree that more components in browsers
| is a bad thing (I've been very happy to use the new modal
| element, for example), but I think the browser is working
| better right now as a lower-level (albeit still fairly high-
| level) platform that allows people to build a variety of
| documents and applications on top.
| jasonwatkinspdx wrote:
| 37 Signals has adopted some of these ideas. Would their apps
| qualify as "big" for you?
| ativzzz wrote:
| To be fair, 37 Signals (Basecamp) which is behind ruby on
| rails, changes their front end philosophy with every new
| major version of rails
|
| And to be fairer, it's generally a pretty good philosophy for
| greenfield apps at that particular point in time, but if I
| started an app on rails 4 or 5 there's no way I'm updating my
| front end every time they change their minds about how front
| end should work
|
| They believe this now, in 4-5 years it'll be XYZ next thing
| mekoka wrote:
| People buy into ideas and once they've paid the price, they
| dislike when that investment is challenged with new
| information. The resistance that I see in these thread to
| the idea that going back to HTML might be enough, to me
| looks very much like that.
|
| Basecamp (formerly 37signals) has a track record of
| challenging the status quo, whether in business or
| engineering practices and to _actually_ be fair, they 're
| not changing their front-end philosophy on a whim or to
| simply follow a fad. They're trying to solve real problems.
| In the past, their flagship product served as proof that
| exposed many established counter-advices as merely baseless
| beliefs. Over the years, they've demonstrated how many "bad
| ideas" could actually work better for you, once you allow
| yourself to become a bit more pragmatic.
|
| They might not be BIG, but they're also not small. Imo,
| what they say and do engineering-wise tends to matter much
| more to average developers than what Facebook or Google
| might recommend.
|
| I think the question stands, is Basecamp a good enough
| example?
| meowtimemania wrote:
| Most anything built with php or traditional SSR pages follows
| these concepts to some extent.
| tonyennis wrote:
| 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 wrote:
| Never read the comment section!
| keepamovin wrote:
| 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/-
| vlttnv wrote:
| 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 wrote:
| 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...
| tonyennis wrote:
| "list of assertions with zero discussion as to how they make
| eng more productive" - this is fair. Initial versions of the
| post had much more of this but I felt it added noise to the
| core principles. I will be following up with some more posts
| and real world examples though. "Like the industry settled on
| certain things for a reason" - In my experience An industry
| "settling" on something hasn't been a great indicator of its
| effectiveness. Industries tend to settle on practices that
| increase the value of its practitioners and increase barriers
| to non-practitioners. The legal industry, for example, is
| still remarkably expensive, laborious and bureaucratic, and
| while outsiders recognise this, there are few people within
| the industry who seek to change it. Thanks for the feedback
| graypegg wrote:
| Congrats on the big post!
|
| Though I do think some of your ideals are worth challenging
| either because I think you're making an incorrect assumption or
| holding too close to some particular dogma, it's always good to
| hear people pushing for simplicity in the space. Keep pushing
| :)
| wheelerof4te wrote:
| Do you believe someone in the future will actually create a
| complex web application using pure
| HTML+CSS+Javascript/Typescript?
|
| Is that even possible at this point?
|
| Thanks.
| codeptualize wrote:
| > We use static-tailwind, a version with no build step, in
| development.
|
| So you do use a build step for production? Or are you shipping
| a bunch of unused styles?
| jokoon wrote:
| 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 wrote:
| 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 wrote:
| A lot of this stuff is a response to the worship of complexity
| by the webdev industry.
| TheCycoONE wrote:
| 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 wrote:
| 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 wrote:
| 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_h
| armf...
|
| [2]: https://www.w3.org/TR/CSP/
|
| [3]: https://content-security-policy.com/nonce/
|
| [4]: https://content-security-policy.com/hash/
|
| [5]: https://web.dev/articles/csp#use_case_3_ssl_only
| TheCycoONE wrote:
| Neither of those work for the inline event handlers
| proposed by this article. You need unsafe-inline or unsafe-
| hashes.
| mattlondon wrote:
| 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 wrote:
| I was going to comment, but you've done it for me. Your
| additional advice is spot on. But I actually think, "do
| whatever you like, the web is designed to be flexible".
|
| The most crucial (half made) point here is that if you want
| your website to be useable beyond the output, document it ...
| include comments, make your reasoning explicit and not implied.
| And yeah, a repo is probably a great place for this. It doesn't
| even need to be linked on the visible part of your site (I
| mean, who's the primary audience here), just do the old "we're
| hiring " trick and print a link to the site's GH in the
| console. The docs will probably solve a few problems for you
| too when you need to change things down the line (I constantly
| read and improve my own comments during refactors, and usually
| kick myself when I haven't made them).
| kuon wrote:
| 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 wrote:
| 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 wrote:
| Raul Gurru Miau {Miau} 8
| sylware wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| mock-possum wrote:
| 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.
| mro_name wrote:
| doesn't the inline JS (onlick="this.classList.add('green')")
| harm/complicate CSP headers?
| lol768 wrote:
| Yes, it all flies in the face of accepted strict Content-
| Security-Policy best practice.
| zlg_codes wrote:
| I've not seen the reasoning for this in the thread.
|
| Best practices are generally called that for a reason.
| zelda-mazzy wrote:
| 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_ wrote:
| Have you used HTMX?
|
| I am yet to find a reason for using frameworks like React
| instead of HTMX.
| silentguy wrote:
| 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_ wrote:
| 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?
| recursivedoubts wrote:
| _> It 's not suitable for anything bigger than a hobby
| project._
|
| This is patently false. It is being used in multiple
| significant production systems:
|
| https://www.commspace.co.za/
|
| https://zorro.management/
|
| https://www.contexte.com/
|
| https://turboscribe.ai/
|
| and many more. There are times where htmx isn't the right
| choice, but the idea that its not useful for anything more
| than a hobby project is simply false.
| ativzzz wrote:
| The middle 2 links are by solo developers - I wouldn't
| call those significant production systems. Generally
| tools like React are helpful for managing complexity
| across large systems where nobody understands the whole
| app and layers of of features, bug fixes and
| optimizations have been baked in over the years and
| nobody understands the whole app anymore
| max_ wrote:
| The reason "nobody understands the app anymore" is due to
| the complexity of React and not the application.
|
| HTMX tries to reduce the complexity.
| ativzzz wrote:
| No, nobody understands the app because it is simply
| impossible to hold in your head 5-10 years worth of
| development by 100+ people across a complex product with
| complicated use cases and customer need (unless you were
| there the whole time and you are a very hard worker)
|
| By the time you create the correct abstractions, customer
| needs and the market will have changed and thus your
| abstractions are now incorrect
| recursivedoubts wrote:
| contexte is a (small & now full stack, after using react)
| team:
|
| https://htmx.org/essays/a-real-world-react-to-htmx-port/
| David-Guillot wrote:
| To be accurate in the past year we went from 3 to 7 in
| that team, and I think everyone has been using htmx at
| least once, and 4 of us are using it on a regular basis.
| robertoandred wrote:
| What's the reason to use a framework like HTMX instead of
| React?
| David-Guillot wrote:
| Cost.
|
| React will require you to hire a React dev to handle all
| the complexity.
|
| htmx will be mastered by your "back-end" devs (who actually
| are web devs) in less than a week.
| mostlylurks wrote:
| React is so simple to use that you definitely don't need
| to hire a "react dev" to "handle all the complexity".
| Like >95% of the effort is just understanding the basics
| of standard front end technologies (HTML, JS, and CSS),
| something that "back-end" devs (especially ones that
| label themselves as such) are by no means guaranteed to
| understand, which is an issue, since you'll have to
| understand these things even when working with htmx.
| robertoandred wrote:
| What kind of web dev can't handle React? Meanwhile, htmx
| uses clunky, non-standard attributes that rely on logic
| and templates that are split up in a million different
| places. Plus it requires a context switch to do anything
| client side.
| max_ wrote:
| It reduces development complexity.
|
| - No complex build set-up (just link the script & use it)
|
| - Less congitive load when reading the code. Especially if
| it's not yours.
|
| - Very decent learning curve.
| robertoandred wrote:
| But all it is is fancier fetch()s. It can't remotely
| approach the functionality of React, so it just shifts
| any complexity to different places.
| mostlylurks wrote:
| React makes it fairly easy to implement your app in a way
| that makes it easily portable to different platforms. With
| things like HTMX, you'll more or less have to rewrite
| everything if you ever end up in a situation where you'd like
| to release the application on mobile, or as a desktop app,
| especially if you want it to work when you can't rely on the
| user having a stable internet connection.
| alfonsodev wrote:
| 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 wrote:
| Browsers have had built-in templating engines (xslt) for
| decades.
| zlg_codes wrote:
| 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.
| TheRealPomax wrote:
| 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 wrote:
| 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
|
| [2]: https://www.w3.org/People/Bos/CSS-variables
| timeon wrote:
| For me, it does not matter if it is inline CSS, style
| attributes or Tailwind. I do not like them.
| catlifeonmars wrote:
| 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 wrote:
| 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 wrote:
| 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/61276afbab042e204e54268f6a...
| Then that complexity is hidden from the client.
| xixixao wrote:
| 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 wrote:
| 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?
| gemstones wrote:
| 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.
| pech0rin wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| > "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 wrote:
| 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.
| codeptualize wrote:
| So pelican and hugo are not frameworks? How is a static
| site generator any different from statically exporting
| next.js/nuxt.js or similar?
|
| I've used all the things mentioned, and I quite like the
| ergonomics of frameworks for static websites. Added
| benefit is that I can make static sites dynamic if
| necessary.
|
| And to be clear, these static exports are incredibly fast
| and performant.
|
| > you could roll your own SSG in a weekend
|
| Sure, I could do that, or I could build my app/website in
| that weekend..
| zlg_codes wrote:
| I can't speak for Hugo but no, Pelican is not a
| framework. It's a static site generator. I cannot make
| general purpose, dynamic websites with Pelican. I can
| fake a few things, I can hook it up to cron to mimic it,
| but Pelican itself is concerned primarily with your data
| store, your theme, and generating static files to upload
| directly to your webspace.
|
| Sure, you can make plugins for Pelican to make it
| generate things the way you want, but it's still just a
| generator/builder using Jinja templates and Markdown or
| some other text transformation tool.
|
| Also, there's no real indicator that I used Pelican to
| build my site. There's no cruft I'm including in my
| <head> element or anything else. It outputs regular-ass
| HTML.
|
| I'm sure it's nice to be able to swap into dynamic web
| app mode if you decide a project's going differently than
| expected, but I don't run into that much with the things
| I design. I usually know from the beginning which tech
| I'll need to achieve the goal.
|
| Frameworks force the dev into specific ways of doing
| things, so if a program fits into that architecture, go
| nuts. I'm curious what you guys need on your sites that
| require so much JS.
| zlg_codes wrote:
| I'm sorry, but the majority of the change has been inflicted by
| for-profit outfits who EEE'd the W3C to get what they wanted.
| None of us asked for a Javascript-dominated Web where you
| download megabytes of code before you see the first page.
|
| You make it better by separating concerns or finding better
| ways to do the same thing.
|
| By this point, QUIC and HTTP should fork instead of QUIC
| insisting on taking over HTTP.
|
| We can make this space better by pushing out complex "web"
| applications to their own protocol they can fuck up on their
| own instead of pushing the system requirements of a browser up
| every year.
| stanislavb wrote:
| 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 wrote:
| 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 wrote:
| 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
| andrewstuart wrote:
| Meh.
|
| I say build software in the way that you like. Or the way the
| boss says.
| miggu wrote:
| thanks I'll use it on my auntie's cupcake website
| joaomeloplus wrote:
| I think the recommendation to use tailwind and avoid build steps
| and incompatible.
| zlg_codes wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The default date picker is laughable. For example there is no
| way to control the format in which the date is displayed.
| ckolkey wrote:
| Unless I'm mistaken, it's shown in a format localised to
| the user, so... i'd much rather you keep your hands off
| that, and I'll enjoy my DD.MM.YYYY
| ssss11 wrote:
| Yes but companies don't think that way. Companies have a
| style that they want to apply to their product regardless of
| which browser renders it.
| _a_a_a_ wrote:
| Well fuck them.
| guhcampos wrote:
| Thanks.
| divbzero wrote:
| This applies beyond date pickers too. To me, usability trumps
| consistency when your users access the website across a
| variety of platforms: mobile vs. desktop, touch vs. mouse,
| _etc._
| MrJohz wrote:
| I find I'm in the opposite position - I would rather the date
| picker is not consistent, because different date pickers have
| different purposes. The date picker I want to use to put in
| my date of birth is different to the one I want to use to add
| an appointment to my calendar, and that's different to the
| one I want to use to browse prices for different days, and
| that's different to the one I want to use to be able to
| select a range of dates, and even that's often different to
| the one I want to use to select the two dates of a return
| journey.
|
| Of the classic form controls, choosing a date is probably the
| one that has the most application-specific needs, and
| therefore the one that I would most expect to vary between
| applications.
| RoddaWallPro wrote:
| "shift/control-clicking to get multiple things is a flat no-go
| from a UX perspective" - Do you mean that this is NOT how you
| should do multiselects? If that is what you mean, then how _do_
| you do them? If I have a list of items and I want to select 10
| or 15 of them in a row, I currently don't know of a better UI
| to do that with than shift+click.
| andirk wrote:
| <Aside> from the rest of the discussion, `input` element is
| infamously shitty for having vastly different ways of
| interacting with it, whereas most other HTML elements have one
| signature.
| sethkim wrote:
| I built something recently with the same ideas in mind:
| 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 wrote:
| Been doing this with mkws and on https://mkws.sh since day one!
| moron4hire wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I agree completely, but hiccup rather than html.
| Zpalmtree wrote:
| aka make your website look like shit because half the default
| elements can't be styled
| meatjuice wrote:
| 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 wrote:
| 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 wrote:
| 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...
| mirkodrummer wrote:
| 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 wrote:
| 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.
| guhcampos wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-12 23:00 UTC)