6 ms·

It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex

It's so odd to live long enough and see the steady pipeline of "look at this much simpler way of doing web apps, just write HTML, not like the previous complex way" projects, which then turn into the previous complex way as the eyes turn towards the next "simple way of doing web apps, just write HTML...". Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course eventually they all grow "full-stack" solutions). EDIT: And how could I forget, Tailwind, whose tagline reads: "Rapidly build modern websites without ever leaving your HTML" The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline.

PaulHoule 3y ago
ASP had some strange things where you could write what looked like a client side handler on a button and it would call a function in the server. Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.) He thing about HTMX is that it really wants support on the server side. For instance, you might have a <select> that gets drawn as part of an HTML page or that gets updated with new <option>(s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.) It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.
- throwaway290 3y ago
  > Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. I'm sure it's the matter of time for isomorphic HTMX-based frameworks... but they won't degrade gracefully. but then they will, as a new feature. the circle of life!
- wink 3y ago
  The "beauty" of ASP was (is?) that it could be so many wonderful things. For me it was inheriting a codebase that was basically many HTML pages with VBScript AND JScript dynamic parts, in the same file. Imagine what everyone was saying about spaghetti PHP intermixed with HTML - but with 2 backend languages plus HTML and CSS, at least that was early enough that clientside JS was limited to changing images on hover...
  - xtracto 3y ago
    Aaaah php, cpanel and html/js : the mother of all buzzwords: serverless server side rendering.
- matwood 3y ago
  I wrote ASP then, and it worked fine. We also wrote our own htmx like handlers. The main reason that people forget is that js was just too slow on the client to really do anything. The only way to get performance was render pieces on the server and replace the client html. I remember having the server render js multi-dimensional arrays consisting of key and html snippet that client js could reference to do html manipulation more quickly. Good times.
  - 3cats-in-a-coat 3y ago
    I'm not sure JS being slow was the reason. It's rather lack of trust that JS can and should be used for such things, and the difficulty of mixing client and server logic together. You kinda want to simplify things and relegate JS simply the role of detecting an event and delegating it to the server for processing and injecting the result back. But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential. I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done. Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this. We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.
    - PaulHoule 3y ago
      In that time frame I was building very complex applications (semantic graph editors, decision support software for sales teams with 10,000 salespeople, etc.) in frameworks like GWT (Java compilers to Javascript) this wasn't long after the firstversion of Google Docs came out. Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-numbing, particularly considering that you didn't have tools like async/await to help manage asynchronous communications. I built frameworks for managing the flow of data in that kind of application and didn't feel it was so catastrophic when Microsoft banned synchronous communications in Silverlight... I knew what to do. Having had that experiment I tend to laugh at today's Javascript frameworks because they work really hard but aren't suitable for the kind of apps I built back then. Sometimes it seems there is a lot of "lost" technology in software like the production rules systems of the 1980s, CASE systems and Lotus notes from the 1990s, Google docs in the 2000s that are like Stonehenge or the Egyptian Pyramids seen from the state of programming in 2023.
- tracker1 3y ago
  ASP.Net is different than Classic ASP... ASP.Net had a "WebForms" model, where the default behavior was a postback with a rerender on a lot of handler actions. That also included a ViewState input attached to your page/forms that was used for (re)hydration to handle change and other event detection. The use of viewstate with a lot of the component libraries at the time was pretty aweful. Not to mention feature/browser detection was just plain wrong as Firefox started to gain traction, before Chrome. I can say I migrated away and mostly separated render/js/backend with ASHX handlers until MVC took hold. These days, I tend to prefer the modern SPA models for browser applications. Though will also use static generators, server generation or other techniques if you don't need an interactive application. HTMX seems pretty interresting as a kind of in-between, closer to the ASP.Net Webforms without the complete excessive overhead in the box.
Cthulhu_ 3y ago
Don't forget Polymer, whose main marketing was that it's the tech behind... McD's menu screens. It turned into lit html, I have no idea what the state of that is now, haven't heard from it for a while now.
- peebeebee 3y ago
  WebComponents are still very much alive. :) And LitHtml is a very nice wrapper around them.
- greenyouse 3y ago
  Polymer powered a few other things at Google too. Look at the DOM for YouTube, that dev team started with Polymer for Web Components and talked about how they built an internal library of custom HTML for the site. Doing that shared library approach seemed like a good way to scale out development across teams. It seems like it's still alive and well over there. (also used at ING, Comcast, Vercel, and others) I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it? It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...
alentred 3y ago
Almost all of these projects bring something innovative too. My take: we are missing the "refactor" step from the loop. It probably concerns other areas more than web dev by the way, but I would like to see more projects that not only build on top of the past experiences, but also remove the complexity from the solutions, instead of adding the features to deal with it. Achieve the same result with fewer layers, less code, less "stuff". For what it’s worth, HTMX looks exactly like the latter kind.
savanaly 3y ago
>The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline. Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make sure it's part of the build step), forget what name I had decided on, check the original HTML to remember the name, then go back to the CSS file and write the class name and then finally within that block add my style.
- uxp8u61q 3y ago
  Sounds like you're using a rather poor IDE.
  - LordDragonfang 3y ago
    What does your IDE/workflow look like that you avoid this?
- 3cats-in-a-coat 3y ago
  Are you programming on a phone?
- graypegg 3y ago
  I’ve messed around with tailwind a bit now, and honestly I could never use it in even a moderately complex site without some sort of “component” framework. I think you’re talking about just serving a .html file for every page in a site right? Having all of your styles duplicated everywhere would be much more confusing than writing CSS (and having to invent one name per groups of common things.) IMO it’s only viable if you can create your own components. Which you will also have to give a name.
  - tomnipotent 3y ago
    > some sort of “component” framework It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components. > Having all of your styles duplicated everywhere Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the classes involved. Compression is going to solve most of the issues with repeating classes everywhere, and while not recommend you can still use something like Sass/SCSS and Tailwind directives like @apply to separate classes into their own files. .my-class { @apply p2 mr-4 mb-2; }
AtlasBarfed 3y ago
Coldfusion may have been one of the granddaddies, which java's JSP copied shamelessly. So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:" Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks. React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript. But HTMX seems to get love that angular/react/etc never got from a HN front page perspective. I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision. The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.
- Dylan16807 3y ago
  > React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript. Why? Can't run java in a browser. (And don't bring up applets.) I suppose you could keep most of a testing framework as Java code, and adapt the rest for testing javascript, but that seems fussy enough for a rewrite to makes sense. Edit: Okay, if people are going to downvote, then I'll elaborate. I understand amusement in people moving from one server language to another, only to recreate the same things they already had, because they could have just stuck with the original. But you can't just stick with a server language when you're writing an interactive web page. Trying to port the tools you like is making the best of the situation, not creating work out of nothing.
  - AtlasBarfed 3y ago
    Mostly because React was yet another "we're so much simpler/uncomplicated than all that enterprisey Java" sale job (just like Rails was) and lo and behold, React went full enterprisely in like less than 12 months (at least it took Rails something like 3-4 years to get to full complexity, and Rails/Ruby contributed huge amounts of groundbreaking frameworks and idioms along the way).
strangescript 3y ago
"The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline." There are a ton of ways to solve this issue but most people just look at tailwind on the surface and go shitpost about it on social media. Its the equivalent of saying "I wrote this 2k line program in one file, its so bad and disorganized <insert language here> is bad!"
- 3cats-in-a-coat 3y ago
  Yeah, ok. Do tell me what are those ways. Maybe @apply? Then put some effort into realizing this is literally what you could do in CSS the entire time, but better, shorter, simpler, and with clear precedence rules, and complete assistance from the browser dev tools. Look at this here and the ridiculous extent they insist on "NO, YOU MUST COPY AND PASTE ZEH STYLES!": https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles It's rampant dysfunction on full display, my friend. It's as clear as daylight. Copy/paste is the rookie approach, and Tailwind targets rookies. So it focuses on "it's not your fault, copy paste is good, they... they don't get you" approach and then throw @apply in there as some half-baked solution for those who are starting to wake up from the Matrix. You are in an abusive relationship. Seek counsel.
  - strangescript 3y ago
    "precedence rules, and complete assistance from the browser dev tools" Huh? I am not sure what you mean here. Tailwind generates css that is completely explorable in any browser dev tooling. Its precedence is the order of the css classes just like any other css class. You can solve class overload by just making components. Create a Button component one time, have it contain the tailwind classes you want, and then all through your app, just call your Button component and never think about it again. You can also just define custom tailwind classes in the config you want to do something really specific or crazy. If that is too much work you can use Daisy UI which is just a tailwind plugin and it creates a ton of classes that essentially compress tailwind classes down to manageable chunks if you are fine with Daisy's style.
nonethewiser 3y ago
Style attributes’ values being long doesnt make it any less html-like.

PaulHoule 3y ago

ASP had some strange things where you could write what looked like a client side handler on a button and it would call a function in the server. Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.) He thing about HTMX is that it really wants support on the server side. For instance, you might have a <select> that gets drawn as part of an HTML page or that gets updated with new <option>(s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.) It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.

throwaway290 3y ago
> Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. I'm sure it's the matter of time for isomorphic HTMX-based frameworks... but they won't degrade gracefully. but then they will, as a new feature. the circle of life!
wink 3y ago
The "beauty" of ASP was (is?) that it could be so many wonderful things. For me it was inheriting a codebase that was basically many HTML pages with VBScript AND JScript dynamic parts, in the same file. Imagine what everyone was saying about spaghetti PHP intermixed with HTML - but with 2 backend languages plus HTML and CSS, at least that was early enough that clientside JS was limited to changing images on hover...
- xtracto 3y ago
  Aaaah php, cpanel and html/js : the mother of all buzzwords: serverless server side rendering.
matwood 3y ago
I wrote ASP then, and it worked fine. We also wrote our own htmx like handlers. The main reason that people forget is that js was just too slow on the client to really do anything. The only way to get performance was render pieces on the server and replace the client html. I remember having the server render js multi-dimensional arrays consisting of key and html snippet that client js could reference to do html manipulation more quickly. Good times.
- 3cats-in-a-coat 3y ago
  I'm not sure JS being slow was the reason. It's rather lack of trust that JS can and should be used for such things, and the difficulty of mixing client and server logic together. You kinda want to simplify things and relegate JS simply the role of detecting an event and delegating it to the server for processing and injecting the result back. But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential. I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done. Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this. We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.
  - PaulHoule 3y ago
    In that time frame I was building very complex applications (semantic graph editors, decision support software for sales teams with 10,000 salespeople, etc.) in frameworks like GWT (Java compilers to Javascript) this wasn't long after the firstversion of Google Docs came out. Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-numbing, particularly considering that you didn't have tools like async/await to help manage asynchronous communications. I built frameworks for managing the flow of data in that kind of application and didn't feel it was so catastrophic when Microsoft banned synchronous communications in Silverlight... I knew what to do. Having had that experiment I tend to laugh at today's Javascript frameworks because they work really hard but aren't suitable for the kind of apps I built back then. Sometimes it seems there is a lot of "lost" technology in software like the production rules systems of the 1980s, CASE systems and Lotus notes from the 1990s, Google docs in the 2000s that are like Stonehenge or the Egyptian Pyramids seen from the state of programming in 2023.
tracker1 3y ago
ASP.Net is different than Classic ASP... ASP.Net had a "WebForms" model, where the default behavior was a postback with a rerender on a lot of handler actions. That also included a ViewState input attached to your page/forms that was used for (re)hydration to handle change and other event detection. The use of viewstate with a lot of the component libraries at the time was pretty aweful. Not to mention feature/browser detection was just plain wrong as Firefox started to gain traction, before Chrome. I can say I migrated away and mostly separated render/js/backend with ASHX handlers until MVC took hold. These days, I tend to prefer the modern SPA models for browser applications. Though will also use static generators, server generation or other techniques if you don't need an interactive application. HTMX seems pretty interresting as a kind of in-between, closer to the ASP.Net Webforms without the complete excessive overhead in the box.

Cthulhu_ 3y ago

Don't forget Polymer, whose main marketing was that it's the tech behind... McD's menu screens. It turned into lit html, I have no idea what the state of that is now, haven't heard from it for a while now.

peebeebee 3y ago
WebComponents are still very much alive. :) And LitHtml is a very nice wrapper around them.
greenyouse 3y ago
Polymer powered a few other things at Google too. Look at the DOM for YouTube, that dev team started with Polymer for Web Components and talked about how they built an internal library of custom HTML for the site. Doing that shared library approach seemed like a good way to scale out development across teams. It seems like it's still alive and well over there. (also used at ING, Comcast, Vercel, and others) I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it? It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...

alentred 3y ago

Almost all of these projects bring something innovative too. My take: we are missing the "refactor" step from the loop. It probably concerns other areas more than web dev by the way, but I would like to see more projects that not only build on top of the past experiences, but also remove the complexity from the solutions, instead of adding the features to deal with it. Achieve the same result with fewer layers, less code, less "stuff". For what it’s worth, HTMX looks exactly like the latter kind.

savanaly 3y ago

>The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline. Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make sure it's part of the build step), forget what name I had decided on, check the original HTML to remember the name, then go back to the CSS file and write the class name and then finally within that block add my style.

uxp8u61q 3y ago
Sounds like you're using a rather poor IDE.
- LordDragonfang 3y ago
  What does your IDE/workflow look like that you avoid this?
3cats-in-a-coat 3y ago
Are you programming on a phone?
graypegg 3y ago
I’ve messed around with tailwind a bit now, and honestly I could never use it in even a moderately complex site without some sort of “component” framework. I think you’re talking about just serving a .html file for every page in a site right? Having all of your styles duplicated everywhere would be much more confusing than writing CSS (and having to invent one name per groups of common things.) IMO it’s only viable if you can create your own components. Which you will also have to give a name.
- tomnipotent 3y ago
  > some sort of “component” framework It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components. > Having all of your styles duplicated everywhere Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the classes involved. Compression is going to solve most of the issues with repeating classes everywhere, and while not recommend you can still use something like Sass/SCSS and Tailwind directives like @apply to separate classes into their own files. .my-class { @apply p2 mr-4 mb-2; }

AtlasBarfed 3y ago

Coldfusion may have been one of the granddaddies, which java's JSP copied shamelessly. So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:" Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks. React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript. But HTMX seems to get love that angular/react/etc never got from a HN front page perspective. I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision. The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.

Dylan16807 3y ago
> React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript. Why? Can't run java in a browser. (And don't bring up applets.) I suppose you could keep most of a testing framework as Java code, and adapt the rest for testing javascript, but that seems fussy enough for a rewrite to makes sense. Edit: Okay, if people are going to downvote, then I'll elaborate. I understand amusement in people moving from one server language to another, only to recreate the same things they already had, because they could have just stuck with the original. But you can't just stick with a server language when you're writing an interactive web page. Trying to port the tools you like is making the best of the situation, not creating work out of nothing.
- AtlasBarfed 3y ago
  Mostly because React was yet another "we're so much simpler/uncomplicated than all that enterprisey Java" sale job (just like Rails was) and lo and behold, React went full enterprisely in like less than 12 months (at least it took Rails something like 3-4 years to get to full complexity, and Rails/Ruby contributed huge amounts of groundbreaking frameworks and idioms along the way).

strangescript 3y ago

"The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline." There are a ton of ways to solve this issue but most people just look at tailwind on the surface and go shitpost about it on social media. Its the equivalent of saying "I wrote this 2k line program in one file, its so bad and disorganized <insert language here> is bad!"

3cats-in-a-coat 3y ago
Yeah, ok. Do tell me what are those ways. Maybe @apply? Then put some effort into realizing this is literally what you could do in CSS the entire time, but better, shorter, simpler, and with clear precedence rules, and complete assistance from the browser dev tools. Look at this here and the ridiculous extent they insist on "NO, YOU MUST COPY AND PASTE ZEH STYLES!": https://tailwindcss.com/docs/reusing-styles https://tailwindcss.com/docs/reusing-styles It's rampant dysfunction on full display, my friend. It's as clear as daylight. Copy/paste is the rookie approach, and Tailwind targets rookies. So it focuses on "it's not your fault, copy paste is good, they... they don't get you" approach and then throw @apply in there as some half-baked solution for those who are starting to wake up from the Matrix. You are in an abusive relationship. Seek counsel.
- strangescript 3y ago
  "precedence rules, and complete assistance from the browser dev tools" Huh? I am not sure what you mean here. Tailwind generates css that is completely explorable in any browser dev tooling. Its precedence is the order of the css classes just like any other css class. You can solve class overload by just making components. Create a Button component one time, have it contain the tailwind classes you want, and then all through your app, just call your Button component and never think about it again. You can also just define custom tailwind classes in the config you want to do something really specific or crazy. If that is too much work you can use Daisy UI which is just a tailwind plugin and it creates a ton of classes that essentially compress tailwind classes down to manageable chunks if you are fine with Daisy's style.

nonethewiser 3y ago

Style attributes’ values being long doesnt make it any less html-like.