I posted this tweet a couple weeks back:
It shows a bunch of routes that form a the pages you'd need for calendar scheduler like calendly. The ultimate goal of something like this is to build up the information in the steps and submit it all in a form. Interestingly in the past we used urls as stores for things like this. As the user goes through the pages the url builds up. Eventually everything is POST'ed to an endpoint and the user is redirected back to a thank you page.
We don't really think in these terms anymore. We design full components that maintain their own state and show and hide parts of the component using reactivity on the client. This is why even in this day and age when you perform some interactive actions on a modern webpage and refresh things don't persist the data isn't preserved, as a developer you have to wire that part up extra, and sometimes it's not worth it, or considered.
One issue with this old way of doing stuff is that the URL is now occupied by all these parameters. If I wanted to use this as a self-contained widget on a different page, how would I? One thing keeps popping into my head, it's to use an <iframe>. Using an iframe means that you again loose that frame state when you refresh on the parent. In this example you could set the src for the <iframe> on the server dynamically. For example Let's say you want to have a page like /blog/zoo-day, and you want it to also show this calendar widget, you could have a single query param the the query we see in the calendar page /blog/zoo-day&cal=/calendar/sept/22 and pass the full value of the cal query param to the <iframe> src. In order to save the page that this specific user is on you'd need to maintain what was the last page seen on the server by this specific user.
All of this is to say I'm interested in interactivity for these small features without the use of JavaScript. There was a time when post of these sorts of things were done with hefty use of a server, responsible for routing, maintaining state, database access, and as the name implies serving html.
I think in this day and age it would be interesting to have a server framework with the tag line "A server framework for interactive html". Using preact / react to do this is very simple. You can easily create a SSR website that does not provide any interactivity by rendering the JSX to a string. In face fresh and astro both do this by default. Then you can create a custom component for the server that would only contain the <iframe> in it. You could even have a "hook" that tapped into your server to maintain the latest page for that <iframe>, that stores the current page into session.
I like the idea that every component, even a piece of a larger ui unit has a reference-able url.
Why do all of this? Possibly it's nostalgia for a simpler time?
My dream is to have a platform where anyone can add a small piece of interactivity like a widget and share it with others. JavaScript makes that difficult because of cross-site scripting stuff, it could allow someone to easily add malicious calls to the site. Databases also open up a host of issues and complexity with sensitive data / privacy.
I'm imagining everyone getting a profile page and a whole platform is driven by server-widgets as described above. I could then host my own JSON file with a list of which components I'd want use with the properties filled out (including dynamic options for google calendar interrogations, the host site could have a webhook or listen to changes from that file somehow) I control my data, and the widgets i'm interacting with would not have a way to access do anything with it, except show it. Every user on the site would get a profile and can customize it with a single JSON config file.
Top comments (0)