4 ms·

> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications Are we actually, in f

by donatj 1y ago

> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications Are we actually, in fact, if we're being honest? I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. Sometimes they add unnecessary complexity and flashiness and of course there are some games and such, but when it comes to actual business apps they all just boil down to updating text records in a database at a human pace. I am genuinely interested to hear examples of these "highly interactive" web apps others are building I keep hearing about but never seeing.

timw4mail 1y ago
It's all the buzzwords to justify the overcomplexity of web frontends.
burnte 1y ago
I totally agree, maybe 1 in 100 web pages actually NEED any of the code they run. Mostly it's reinventing the wheel. Where a flat site with fixed HTML and pretty CSS would be fine, they add a splash page so they can show a logo, they'll break navigation and reimplement the browser inside the page with JS so you can't use the back button, they'll style everything on the fly when nothing is dynamic, etc. Nonsense.
_fat_santa 1y ago
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.
pyrale 1y ago
It really depends on what you call CRUD, but for instance, in the past, I've had frontends hiding the crud behind more "friendly" gestures. For instance, a write such as rescheduling a sale could be done with drag&drop, reads would feed a local store of events/sales that could be browsed either as a workweek panel of which sales are happening, or as a monthly calendar aggregating sales and showing which day is a "hot" day and which day is quiet and needs more blockbusters to drive sales. Add in search features, graphs of forecasted sales and a news feed on the sales a specific user was managing. It's not that complex or fancy compared to what can be found in b2c, but it's not just a crud where users are directly tasked to update values in fields either. And yes, it could have been a crud, but I believe our users would have been worse off.
- skydhash 1y ago
  You can have interactivity within a single form, whithout having a whole app code humming in the background. And with the drag and drop example, I often see designers missing the obvious accessibility issue where the user can’t use a mouse.
  - pyrale 1y ago
    So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning. Accessibility issue is a good point, but the accessible way doesn’t need to be the only way.
    - skydhash 1y ago
      > So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning. That's pre-javascript workflow. You can have your DnD without making your app an SPA. And why not have the DnD and the more complete change form?
      - pyrale 1y ago
        You're mixing two things here: having an app with more than just CRUD interactions, and making that app an SPA. My point was giving an example of an app that's a bit more featured than just some forms in a CRUD interface, not that you can only do that with a SPA. > And why not have the DnD and the more complete change form? It was, in fact, what we did.
oneeyedpigeon 1y ago
I feel exactly the same way as you, and I get flashbacks to every time someone talks about the new framework on the block that serves to fix a problem that 0.1% have, while making things worse for the other 99.9%.
- alternatex 1y ago
  Even though your first instinct might be to immediately pull away when people talk about SPAs, remember that this discussion is about how using a SPA feels vs a server-rendered app that refreshes on every user action. It's not a discussion about the technologies used to build it. There are plenty of JS frameworks and some have a more ergonomic dev experience than others, but what is an undeniable fact is that most users prefer SPAs for highly interactive apps. There is a ton of research into user retention that proves this. Google aren't building SPAs because they like Angular.
motorest 1y ago
> Are we, in fact, if we're being honest? Obviously, yes. > I haven't seen anything like that. 99.9% of applications I interact with are just simple CRUD apps. Irrelevant. Being CRUD is completely orthogonal to whether the WebApps are interactive or not. Look at Gmail. You can hand wave over it and claim it's a CRUD app. However, no one in their right mind would try to deny the app is a "highly interactive, component-based, state-driven, design-system-heavy applications". Also, it's silly to pretend that SPA-type apps are only justified if you check each box in the buzzword bingo card. One of the primary selling points of designing SPA or non-static lage, SPA-like WebApps is performance. Meaning, you are able to put together a highly performant web page if you do not require full page reloads each time anyone clicks on something, if you can easily implement optimistic logic in components, and if you can update only a subset of components when you receive a response from a request. I recommend discovering the concept of perceived performance and afterwards you read through common patterns and strategies to optimize perceived performance. After you do that, go through a though experiment where you start off with an old timey dynamic HTML/server-side rendered WebApp and consider the challenge of achieving the same type of improvements in user experience, or even doing the same tricks. You'll quickly arrive at the same conclusions at the whole world around you already arrived at.
- donatj 1y ago
  Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. You receive like an email a minute? There's a Web 1.0 form for sending emails. Where's this "high levels of interactivity"? It's a form and a list of emails that updates occasionally. It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
  - motorest 1y ago
    > Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. That's perfectly fine. If you can't see it, you can't see it. You need to know what to look for to see it, though. If you're oblivious to web development then every page is just a page. > You receive like an email a minute? Irrelevant. The range of operations that Gmail supports and falls within the lazy classification of CRUD operations goed way beyond sending and receiving emails. For example, see gmail's support for tagging, email classification, multiple types of inboxes, etc. > It's literally basic web 2.0 junk from the early 2000s (...) Tell me you're completely clueless about web development and WebApps in general without actually saying it. Just keep in mind that you also have the option of not commenting on things you're oblivious about.
eadmund 1y ago
> 99.9% of applications I interact with are just a series of simple CRUD operations. The vast majority of web apps out there could be implemented as REST systems (in the real, Fielding, HATEOAS sense, not the JSON-over-HTTP sense). There are a few out there which need to be web apps, but those are relatively rare.
- robertlagrant 1y ago
  Only if you trust the client, presumably.
  - ndriscoll 1y ago
    I don't see how that's related. The HATEOAS idea was that you send the client the relevant data and next set of possible actions with each response (e.g. a web page with forms for possible things they can do). If they try to perform in invalid action, you still just reject on the server. The client doesn't tell the server what it can do. The point is you need the logic on the server since you can't trust the client, but you can make the client "dumb" with just super generic ability to show data and submit forms, and then you don't need to write your application logic a second time in the client. The server sends it instructions for the generic renderer to perform.
austin-cheney 1y ago
> I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. The painful reality is that this is true, but only at work. There is so much that you use written in web technologies that are no CRUD. Some of that is Electron apps like VS Code and some of it is applications packaged in docker containers. Almost all of this non-work and non-CRUD stuff is open source. If you aren't writing code outside of work, where its only CRUD, your perspective of the universe is about 2mm wide. That is where the Dunning-Kruger starts to set in and why all this shit gets reinvented every couple of years. Its easy to think that: 1) you are awesome and 2) the world is painful when your perspective of the universe is only 2mm wide. For everybody else, these things that most developers complain about really aren't painful enough to warrant any call to action because there are other things that bring substantially greater pain.
mickael-kerjean 1y ago
I work on exactly this kind of app, and it’s open source: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash. It’s a Dropbox-like file manager that instead of owning your data integrates with your existing storage, authentication, and authorization systems. Under the hood, there’s a lot going on, very recently I added plugins to handle various kind of file types that are not typically handled by browser, we're talking > 100 kind of file types handled entirely in the browser for niches like astronomy, data engineering, GIS, 3D models, dev and even embroidery patterns
- skydhash 1y ago
  Where do these files come from? And the viewer?
  - mickael-kerjean 1y ago
    The file comes from wherever you have it stored in the first place (FTP, S3, SFTP, virtually anything) and viewer are plugins implementing various interfaces which are packaged up onto a zip file. With this approach, to add support for psd, I just implemented the image viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c0d50256ac28868a3c232ff3f37a9ab/public/assets/pages/viewerpage/application_image.js#L24-L26 https://github.com/mickael-kerjean/filestash/blob/a605988d5c...), to add support for parquet files I implemented the table viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c0d50256ac28868a3c232ff3f37a9ab/public/assets/pages/viewerpage/application_table.js#L16-L20 https://github.com/mickael-kerjean/filestash/blob/a605988d5c...) and still have the freedom for custom stuff like this docx editor based of libre office wasm: https://github.com/mickael-kerjean/filestash/tree/master/server/plugin/plg_application_office https://github.com/mickael-kerjean/filestash/tree/master/ser... Most of the actual implementations of the base interfaces are done in C, compiled to wasm and running via a web worker

by donatj 1y ago

timw4mail 1y ago

It's all the buzzwords to justify the overcomplexity of web frontends.

burnte 1y ago

I totally agree, maybe 1 in 100 web pages actually NEED any of the code they run. Mostly it's reinventing the wheel. Where a flat site with fixed HTML and pretty CSS would be fine, they add a splash page so they can show a logo, they'll break navigation and reimplement the browser inside the page with JS so you can't use the back button, they'll style everything on the fly when nothing is dynamic, etc. Nonsense.

_fat_santa 1y ago

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.

pyrale 1y ago

It really depends on what you call CRUD, but for instance, in the past, I've had frontends hiding the crud behind more "friendly" gestures. For instance, a write such as rescheduling a sale could be done with drag&drop, reads would feed a local store of events/sales that could be browsed either as a workweek panel of which sales are happening, or as a monthly calendar aggregating sales and showing which day is a "hot" day and which day is quiet and needs more blockbusters to drive sales. Add in search features, graphs of forecasted sales and a news feed on the sales a specific user was managing. It's not that complex or fancy compared to what can be found in b2c, but it's not just a crud where users are directly tasked to update values in fields either. And yes, it could have been a crud, but I believe our users would have been worse off.

skydhash 1y ago
You can have interactivity within a single form, whithout having a whole app code humming in the background. And with the drag and drop example, I often see designers missing the obvious accessibility issue where the user can’t use a mouse.
- pyrale 1y ago
  So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning. Accessibility issue is a good point, but the accessible way doesn’t need to be the only way.
  - skydhash 1y ago
    > So you’d need to select a sale, enter a change form, select a new date and validate the change. As opposed to moving the item on your planning. That's pre-javascript workflow. You can have your DnD without making your app an SPA. And why not have the DnD and the more complete change form?
    - pyrale 1y ago
      You're mixing two things here: having an app with more than just CRUD interactions, and making that app an SPA. My point was giving an example of an app that's a bit more featured than just some forms in a CRUD interface, not that you can only do that with a SPA. > And why not have the DnD and the more complete change form? It was, in fact, what we did.

oneeyedpigeon 1y ago

I feel exactly the same way as you, and I get flashbacks to every time someone talks about the new framework on the block that serves to fix a problem that 0.1% have, while making things worse for the other 99.9%.

alternatex 1y ago
Even though your first instinct might be to immediately pull away when people talk about SPAs, remember that this discussion is about how using a SPA feels vs a server-rendered app that refreshes on every user action. It's not a discussion about the technologies used to build it. There are plenty of JS frameworks and some have a more ergonomic dev experience than others, but what is an undeniable fact is that most users prefer SPAs for highly interactive apps. There is a ton of research into user retention that proves this. Google aren't building SPAs because they like Angular.

motorest 1y ago

> Are we, in fact, if we're being honest? Obviously, yes. > I haven't seen anything like that. 99.9% of applications I interact with are just simple CRUD apps. Irrelevant. Being CRUD is completely orthogonal to whether the WebApps are interactive or not. Look at Gmail. You can hand wave over it and claim it's a CRUD app. However, no one in their right mind would try to deny the app is a "highly interactive, component-based, state-driven, design-system-heavy applications". Also, it's silly to pretend that SPA-type apps are only justified if you check each box in the buzzword bingo card. One of the primary selling points of designing SPA or non-static lage, SPA-like WebApps is performance. Meaning, you are able to put together a highly performant web page if you do not require full page reloads each time anyone clicks on something, if you can easily implement optimistic logic in components, and if you can update only a subset of components when you receive a response from a request. I recommend discovering the concept of perceived performance and afterwards you read through common patterns and strategies to optimize perceived performance. After you do that, go through a though experiment where you start off with an old timey dynamic HTML/server-side rendered WebApp and consider the challenge of achieving the same type of improvements in user experience, or even doing the same tricks. You'll quickly arrive at the same conclusions at the whole world around you already arrived at.

donatj 1y ago
Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. You receive like an email a minute? There's a Web 1.0 form for sending emails. Where's this "high levels of interactivity"? It's a form and a list of emails that updates occasionally. It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
- motorest 1y ago
  > Explain what about Gmail is "highly interactive" because I'm genuinely not seeing it. That's perfectly fine. If you can't see it, you can't see it. You need to know what to look for to see it, though. If you're oblivious to web development then every page is just a page. > You receive like an email a minute? Irrelevant. The range of operations that Gmail supports and falls within the lazy classification of CRUD operations goed way beyond sending and receiving emails. For example, see gmail's support for tagging, email classification, multiple types of inboxes, etc. > It's literally basic web 2.0 junk from the early 2000s (...) Tell me you're completely clueless about web development and WebApps in general without actually saying it. Just keep in mind that you also have the option of not commenting on things you're oblivious about.

eadmund 1y ago

> 99.9% of applications I interact with are just a series of simple CRUD operations. The vast majority of web apps out there could be implemented as REST systems (in the real, Fielding, HATEOAS sense, not the JSON-over-HTTP sense). There are a few out there which need to be web apps, but those are relatively rare.

robertlagrant 1y ago
Only if you trust the client, presumably.
- ndriscoll 1y ago
  I don't see how that's related. The HATEOAS idea was that you send the client the relevant data and next set of possible actions with each response (e.g. a web page with forms for possible things they can do). If they try to perform in invalid action, you still just reject on the server. The client doesn't tell the server what it can do. The point is you need the logic on the server since you can't trust the client, but you can make the client "dumb" with just super generic ability to show data and submit forms, and then you don't need to write your application logic a second time in the client. The server sends it instructions for the generic renderer to perform.

austin-cheney 1y ago

> I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. The painful reality is that this is true, but only at work. There is so much that you use written in web technologies that are no CRUD. Some of that is Electron apps like VS Code and some of it is applications packaged in docker containers. Almost all of this non-work and non-CRUD stuff is open source. If you aren't writing code outside of work, where its only CRUD, your perspective of the universe is about 2mm wide. That is where the Dunning-Kruger starts to set in and why all this shit gets reinvented every couple of years. Its easy to think that: 1) you are awesome and 2) the world is painful when your perspective of the universe is only 2mm wide. For everybody else, these things that most developers complain about really aren't painful enough to warrant any call to action because there are other things that bring substantially greater pain.

mickael-kerjean 1y ago

I work on exactly this kind of app, and it’s open source: https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash. It’s a Dropbox-like file manager that instead of owning your data integrates with your existing storage, authentication, and authorization systems. Under the hood, there’s a lot going on, very recently I added plugins to handle various kind of file types that are not typically handled by browser, we're talking > 100 kind of file types handled entirely in the browser for niches like astronomy, data engineering, GIS, 3D models, dev and even embroidery patterns

skydhash 1y ago
Where do these files come from? And the viewer?
- mickael-kerjean 1y ago
  The file comes from wherever you have it stored in the first place (FTP, S3, SFTP, virtually anything) and viewer are plugins implementing various interfaces which are packaged up onto a zip file. With this approach, to add support for psd, I just implemented the image viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c0d50256ac28868a3c232ff3f37a9ab/public/assets/pages/viewerpage/application_image.js#L24-L26 https://github.com/mickael-kerjean/filestash/blob/a605988d5c...), to add support for parquet files I implemented the table viewer interface (https://github.com/mickael-kerjean/filestash/blob/a605988d5c0d50256ac28868a3c232ff3f37a9ab/public/assets/pages/viewerpage/application_table.js#L16-L20 https://github.com/mickael-kerjean/filestash/blob/a605988d5c...) and still have the freedom for custom stuff like this docx editor based of libre office wasm: https://github.com/mickael-kerjean/filestash/tree/master/server/plugin/plg_application_office https://github.com/mickael-kerjean/filestash/tree/master/ser... Most of the actual implementations of the base interfaces are done in C, compiled to wasm and running via a web worker