Transitional JavaScript Apps? What? Well honestly I'm not sure I know completely myself. It is an umbrella term for the progress that has been happ...
For further actions, you may consider blocking this person and/or reporting abuse
It's now over a decade in the past that I created a little script that allowed loading content from a HTML on the same server to the current one instead of navigating to the page (plus some history handling). This turned a classical multi-page-app into a transitional single-page-app, though in a very naive and not very sophisticated way.
This development is not exactly new. It's just updated, seen through the lens of modern front-end frameworks. I think it's worth waiting for the update.
Do you have a sample of this somewhere? I'm not finding it.
No, I wrote it for an employer who did not believe in open source. However, it was a pretty simple script, somewhat along the lines of
That was the main gist, I updated it with fetch, which wasn't stable at the time then; the history handling was a bit more involved, though.
Or did you mean an example of a transitional app?
Where do framework agnostic web components (e.g. litElememt ) fit into this future landscape?
As simply a hobby coder I am left wondering...
Why doesn't a web component that, if not supported / JS disabled, that will default fallback to the inner HTML suitable? Whats wrong with dynamic addition to the DOM & progressive loading when it is supported? Why don't we want to use the distributed power in everyones hands / on their desks to carry out client focused workloads & lighten the demand on our back ends?
Yeah in terms of progressive enhancement they have a decent story in theory. I mean you can accomplish most things with built-ins so adding on top of that makes sense. Except Apple basically veto that and is not supporting extending built-in elements in Safari ever. It was still added to the spec for future discussion but they haven't budged on this issue once in 5 years. So you can can't extend Form or Anchor but need to make your own at which point that unfortunately falls apart.
The next thing to consider is that there is no universal way to server render web components. Recently there is the addition of the Declarative Shadow Root which is cool since now it can be server rendered, but without a DOM on the server there is no unit, no component, it has to come down to whatever templating system you have. I actually was in a meeting with the guys from Lit and they were quite unapologetically like it should be expected you need to use a library to do web components. Lit knows how to server render their webcomponents. In a way its just a different framework.
So I don't really see Lit as framework agnostic. Sure in theory anyone can consume them (client side atleast) but for size reasons you don't want to have 20 components authored with 20 different libraries. In a sense framework agnostic is a fallacy unless you use hand spun ones, and well to do that efficiently requires a certain level of expertise. Not saying people won't do this and those in theory form a strong foundation but then we are stuck with how to server render them.
Lightening the load on the backends isn't really the concern here. The problem is every byte of JavaScript in the browser carries weight. Devices/networks vary and are out of our control. The technologies I'm talking about are all about mitigating the cost of JavaScript in the browser. Advances in edge computing/serverless have us covered on the backend, what we really need is less JavaScript in the browser. That isn't something we can scale to mitigate. We've already went heavy client, that doesn't work for everything, now we are looking how to scale back.
Wow - thanks for the reply, best reply I've ever received & has really helped me understand the driving forces at play. Thanks.
I've been experimenting with going from Server side rendering all the way to offline app capability. For certain apps I think this is possible and desired and others it isn't.
But basically, I start with forms as the core so it can submit even if you have no JS. Then I wrote my own HTMX-like library (HTMF) that focuses on forms instead of having the expectation that JavaScript will be available.
Then for the next step I use a service worker to render the HTML for each page that interacts with HTMF and I save the data to indexeddb and then syncs this data to the back end.
I'm just one person with a day job and family so I don't have a whole lot of time to develop this. But it has been fun and I've tried to keep it fairly minimal on the JS side of things. I haven't gotten this completely implemented yet either. It would be nice to get to the point where it works across all the domains. But I don't see any reason why it shouldn't work.
Links:
github.com/jon49/htmf
github.com/jon49/html-template-tag...
github.com/jon49/WeightTracker/tre...
The problem with SDAs in large organizations is in my experience also that without a mono-repo creating large applications is kind of impossible. The reason is that one is forced to use the all libraries in the same version. Also code sharing becomes an hard to solve problem without a common build (yes there is now webpack module federation which might help).
Microfrontends are one solution. All architectures face scaling problems. MPAs might take longer but we still get there with sufficient desire for re-usability and unified experience. I'm not here to crap on SPAs to be clear. I like SPAs and I think they have a plenty of utility. I'm just saying there are different ways to to attack this, each with different tradeoffs. Everything isn't the same, and that's OK.
Module Federation is an interesting idea, but it doesn't change the fundamental math. Either everything is on the same deps, which means you didn't need module federation if you can enforce it. Or things can have their own version at which point you were probably better bundling with your app to leverage tree shaking (ie.. only load the Lodash functions your app uses). The middle ground is sort of no good for anyone, and when you consider Module Federation has its own overhead (often client side orchestration with fetching waterfalls) what are you left with. I think combining this technology with server side rendering is probably the way to go, but first we need to have the right technology to deliver those woven server experiences.
I am also not convinced that webpacks federation are the full solution. With regards to bundling I wonder why we have not yet yet seen more attempts on server side dynamic bundling.
Why don’t we abandon the DOM altogether? Let’s be realistic we are no longer building “documents”. Why don’t we see more frameworks that use canvas or wasm to draw pixels? I feel like if developers pushed forward this way, away from the DOM, the browsers would follow suit and speed up the canvas API, or otherwise accommodate the shift. It feels like we are building entire sky scrapers out of chewing gum and popsicle sticks. It’s fun, don’t get me wrong, and something like Qwik is incredibly impressive, but it’s getting to be a very VERY strange way to show pixels to a user. Frameworks can draw and scale text, adjust layout responsively, scroll, navigate, listen for events, and do the rest of the small handful of things we actually rely on the DOM for today. If these tasks were in the framework, we could modify how it works to taste, and not be stuck with a black box DOM to work around. Arguably less fun, but certainly more productive.
here's a fun one I made over a few weeks in Deno. I just wrote a custom JSX Factory, and went from there. I was able to build text inputs, scrolling, and animations without loosing too much sleep over it. Canvas can handle it (just barely), and this completely redraws everything on every render.
github.com/marchingband/jdom/
"If anything it only adds to it as the code to hydrate tends to be larger than the code to render."
Good one liner to describe the current area of action!
Well considered salt and spice added to the conversation!