4 ms·

Easy. It's just about any react/angular/vue based site written these days. Take GMail, Jira, your health insurance portal, TurboTax, and a littany of other site

Easy. It's just about any react/angular/vue based site written these days. Take GMail, Jira, your health insurance portal, TurboTax, and a littany of other sites. Practically every one of these uses components, internal state, and design systems to make the site highly interactive, just about every "web app" falls into this category.

donatj 1y ago
All of those examples boil down to very simple forms, web 1.0 style forms. CRUD. Fill out an email form, hit submit. Fill out my tax form, hit submit. Fill out a ticket form, hit submit. It's prettied up CRUD, but it's CRUD. There's no high levels of interactivity, nor any sort of need for client side state in any of them.
- ozim 1y ago
  Wow I see you never had to edit more than 20 things on a list in a Web 1.0 submit form style. Like go over 20 jira tickets to update the names or adjust different properties on different ticket.
  - timw4mail 1y ago
    Jira is a horrible tool I only use because I am forced to.
  - skydhash 1y ago
    The old way was ctrl-clicking to open the form in a new tab/windows. And when AJAX, it was easy to use jQuery to make update request.
  - mdavidn 1y ago
    Jira itself does bulk editing with traditional web forms. I'm thinking of that "wizard" flow: The bulk edit operation itself is the "HTTP resource" the user builds up and submits.
    - ozim 1y ago
      Bulk editing yes. Now read again "different properties on different issues". Like you are not going to bulk edit task requirements or set title for 20 tasks to the same thing.
- ndriscoll 1y ago
  The tax one is especially funny: those "applications" just walk through the same information you'd write on the paper forms! I do free filing every year and "paper forms on the screen with a 'calculate' button for some fields" is the literal UI.
mdavidn 1y ago
All of your examples could've been built using traditional HTML web forms. Better examples would be things like Google Maps, Lucidchart, Google Docs, Photoshop, Zoom, any 3D rendering. These applications can only work with components and internal state. 99% of web "apps" don't need the complexity.

donatj 1y ago

All of those examples boil down to very simple forms, web 1.0 style forms. CRUD. Fill out an email form, hit submit. Fill out my tax form, hit submit. Fill out a ticket form, hit submit. It's prettied up CRUD, but it's CRUD. There's no high levels of interactivity, nor any sort of need for client side state in any of them.

ozim 1y ago
Wow I see you never had to edit more than 20 things on a list in a Web 1.0 submit form style. Like go over 20 jira tickets to update the names or adjust different properties on different ticket.
- timw4mail 1y ago
  Jira is a horrible tool I only use because I am forced to.
- skydhash 1y ago
  The old way was ctrl-clicking to open the form in a new tab/windows. And when AJAX, it was easy to use jQuery to make update request.
- mdavidn 1y ago
  Jira itself does bulk editing with traditional web forms. I'm thinking of that "wizard" flow: The bulk edit operation itself is the "HTTP resource" the user builds up and submits.
  - ozim 1y ago
    Bulk editing yes. Now read again "different properties on different issues". Like you are not going to bulk edit task requirements or set title for 20 tasks to the same thing.
ndriscoll 1y ago
The tax one is especially funny: those "applications" just walk through the same information you'd write on the paper forms! I do free filing every year and "paper forms on the screen with a 'calculate' button for some fields" is the literal UI.

mdavidn 1y ago

All of your examples could've been built using traditional HTML web forms. Better examples would be things like Google Maps, Lucidchart, Google Docs, Photoshop, Zoom, any 3D rendering. These applications can only work with components and internal state. 99% of web "apps" don't need the complexity.