9 ms·

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 th

This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives. I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something. With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.

philihp 3y ago
For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR. I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.
- tonyennis 3y ago
  Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo
  - codeptualize 3y ago
    Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides? Nothing is more convincing than real world success stories.
    - tonyennis 3y ago
      Coming soon
  - docmars 3y ago
    Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?
    - whstl 3y ago
      I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash. Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech. These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework. There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.
      - darkerside 3y ago
        Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.
- codeptualize 3y ago
  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.
- iopq 3y ago
  and this is why that example doesn't work - you find out onclick doesn't work where you thought it would work whereas you can addEventListener anywhere you want
- epiccoleman 3y ago
  > starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do. Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground. I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out. Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted. I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense. We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.
jackblemming 3y ago
[flagged]
- codeptualize 3y ago
  If they did I'd honestly love to get the details and be proven wrong. With just this list it's hard to imagine how this would work. The only scenario where I can sort of imagine it being potentially helpful is an agency setting with many not-too-complex projects and limited ongoing development. I can imagine updating projects being a hassle. That said I don't have experience in that field, and I bet there are other ways to deal with that.
- mock-possum 3y ago
  > wow all of this is too complex and stupid Not that they were necessarily wrong, I also tend to reach this conclusion on most big web projects I work on.
wheelerof4te 3y ago
"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 3y ago
  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 3y ago
  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.
tabacitu 3y ago
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 3y ago
  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 3y ago
  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 3y ago
    This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.
    - timeon 3y ago
      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.
hinkley 3y ago
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 3y ago
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 3y ago
  Perhaps web publishing shouldn't be presupposed to be 'software development'?
  - zztop44 3y ago
    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 3y ago
      Hopefully WASM will fill that area, and browsers can go back to being browsers.
      - shadowgovt 3y ago
        Not as long as the only way that wasm interfaces to the DOM is through the JavaScript layer.
    - docmars 3y ago
joeyguerra 3y ago
The entire WWW is the example
ln_00 3y ago
Aem edge delivery service, Hey.com
avidphantasm 3y ago
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 3y ago
  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 3y ago
37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?
- ativzzz 3y ago
  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 3y ago
    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?
  - jasonwatkinspdx 3y ago
    I think this is a rational strategy. They aren't changing concepts just randomly for that alone. As we learn problems with the last approach we try something new to address it. If you're starting a new app green field this is an ideal time to try to shed some baggage.
  - 3y ago
meowtimemania 3y ago
Most anything built with php or traditional SSR pages follows these concepts to some extent.
wheresmycraisin 3y ago
> This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. Not everything has be a Large Enterprise Application.
- RunSet 3y ago
  Perhaps, but can you name even one successful, big, bloated institutional project that operates primarily on the principles of HTML First?
  - wheresmycraisin 3y ago
    How is that a response to "Not everything has be a Large Enterprise Application."? If I said "not everything has to be blue" would you reply "what's one thing that's blue?"?
al_borland 3y ago
Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.
- docmars 3y ago
  One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board. This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development. End-users are none the wiser, that is of course unless I do a terrible job using these tools.
  - professorsnep 3y ago
    For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project. [1]: https://docs.astro.build/ https://docs.astro.build/
    - docmars 3y ago
      Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!
  - nightowl_games 3y ago
resonious 3y ago
I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content. One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out. But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.
- listenallyall 3y ago
  > it's very hard to find high profile examples of sites that are "HTML first" Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?
- gedy 3y ago
  > One semi-objective thing we lost was accessibility. TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs
  - chii 3y ago
    I argue that it is a framework issue. If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.
    - LudwigNagasena 3y ago
      React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.
rando832 3y ago
https://www.gnu.org https://www.gnu.org
H12 3y ago
Counterpoint: The article is titled "HTML First" not "HTML Only" Admittedly I had the same reaction you did as I was reading the article. All I could think was how poorly these approaches would scale when the need arose for even modest ly complex state management. While the body of the article doesn't address this, IMO the title does. I think it's generally good advice to suggest only reaching for the tools intended for complex environments when they become necessary, not before.

philihp 3y ago

For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR. I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.

tonyennis 3y ago
Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo
- codeptualize 3y ago
  Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides? Nothing is more convincing than real world success stories.
  - tonyennis 3y ago
    Coming soon
- docmars 3y ago
  Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?
  - whstl 3y ago
    I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash. Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech. These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework. There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.
    - darkerside 3y ago
      Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.
codeptualize 3y ago
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.
iopq 3y ago
and this is why that example doesn't work - you find out onclick doesn't work where you thought it would work whereas you can addEventListener anywhere you want
epiccoleman 3y ago
> starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do. Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground. I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out. Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted. I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense. We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.

jackblemming 3y ago

[flagged]

codeptualize 3y ago
If they did I'd honestly love to get the details and be proven wrong. With just this list it's hard to imagine how this would work. The only scenario where I can sort of imagine it being potentially helpful is an agency setting with many not-too-complex projects and limited ongoing development. I can imagine updating projects being a hassle. That said I don't have experience in that field, and I bet there are other ways to deal with that.
mock-possum 3y ago
> wow all of this is too complex and stupid Not that they were necessarily wrong, I also tend to reach this conclusion on most big web projects I work on.

wheelerof4te 3y ago

"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 3y ago
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 3y ago
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.

tabacitu 3y ago

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 3y ago
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 3y ago
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 3y ago
  This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.
  - timeon 3y ago
    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.

hinkley 3y ago

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 3y ago

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 3y ago
Perhaps web publishing shouldn't be presupposed to be 'software development'?
- zztop44 3y ago
  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 3y ago
    Hopefully WASM will fill that area, and browsers can go back to being browsers.
    - shadowgovt 3y ago
      Not as long as the only way that wasm interfaces to the DOM is through the JavaScript layer.
  - docmars 3y ago

joeyguerra 3y ago

The entire WWW is the example

ln_00 3y ago

Aem edge delivery service, Hey.com

avidphantasm 3y ago

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 3y ago
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 3y ago

37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?

ativzzz 3y ago
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 3y ago
  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?
- jasonwatkinspdx 3y ago
  I think this is a rational strategy. They aren't changing concepts just randomly for that alone. As we learn problems with the last approach we try something new to address it. If you're starting a new app green field this is an ideal time to try to shed some baggage.
- 3y ago

meowtimemania 3y ago

Most anything built with php or traditional SSR pages follows these concepts to some extent.

wheresmycraisin 3y ago

> This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference. Not everything has be a Large Enterprise Application.

RunSet 3y ago
Perhaps, but can you name even one successful, big, bloated institutional project that operates primarily on the principles of HTML First?
- wheresmycraisin 3y ago
  How is that a response to "Not everything has be a Large Enterprise Application."? If I said "not everything has to be blue" would you reply "what's one thing that's blue?"?

al_borland 3y ago

Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.

docmars 3y ago
One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board. This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development. End-users are none the wiser, that is of course unless I do a terrible job using these tools.
- professorsnep 3y ago
  For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project. [1]: https://docs.astro.build/ https://docs.astro.build/
  - docmars 3y ago
    Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!
- nightowl_games 3y ago

resonious 3y ago

I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content. One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out. But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.

listenallyall 3y ago
> it's very hard to find high profile examples of sites that are "HTML first" Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?
gedy 3y ago
> One semi-objective thing we lost was accessibility. TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs
- chii 3y ago
  I argue that it is a framework issue. If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.
  - LudwigNagasena 3y ago
    React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.

rando832 3y ago

https://www.gnu.org https://www.gnu.org

H12 3y ago

Counterpoint: The article is titled "HTML First" not "HTML Only" Admittedly I had the same reaction you did as I was reading the article. All I could think was how poorly these approaches would scale when the need arose for even modest ly complex state management. While the body of the article doesn't address this, IMO the title does. I think it's generally good advice to suggest only reaching for the tools intended for complex environments when they become necessary, not before.