TodoMVC
I've seen a lot of projects doing "web applications", but thinking "js" first. Now don't get me wrong: JS is a important part of the modern web. But, HTTP + HTML is the tried and tested backbone of it.
My problem of thinking only in JS (JAM Stack) is - as usual: Complexity. Another layer of abstraction. Another liability. Usually in the form of an "API".
I put the word API into quotes for a reason. If I think about an API, I think about a solid, well designed and simple piece of software. It allows me to interface with a higher abstraction I do not care to understand in itself completely. Those "JS REST APIs" however, only try bridge the gap between a SPA and the business logic on the backend. Its endpoints are so tightly coupled to use cases, that they work only under very specific assumptions and parametrization. And that might be ok...
...when your application has to be a SPA for whatever reasons. But look at the rising adoption of server side rendering [SSR]. Suddenly 90% of the impressions of your SPA are rendered by the server. Something has gone very wrong. But don't worry: It's a very common phenomenon in the tech world. We are constantly reinventing the wheel. So what can we do about it?
Personally, I like to "retrofit". Do you know http://todomvc.com/? The page, where the same TODO application is implemented in almost all of the current JS frameworks? I have implemented the same application without JS [1] - only plain old HTML + HTTP (written in Go).
Try it over here: https://todomvc.pbedat.de
Sources: https://gitlab.com/pbedat/todomvc
Is this implementation superior to the other TodoMVC implementations? Clearly not! It's a SPA managing its state only on the client side. But if I want my TODOs persisted across devices, I would not have to think about introducing another layer of complexity: I would just switch my state implementation from cookies, to anything else. And I think, that's a huge bonus.
[1]: I've used inline JS like, `<input type="checkbox" onchange="form.submit()" />` to get more interactivity (tha's what JS was about in the first place)
My problem of thinking only in JS (JAM Stack) is - as usual: Complexity. Another layer of abstraction. Another liability. Usually in the form of an "API".
I put the word API into quotes for a reason. If I think about an API, I think about a solid, well designed and simple piece of software. It allows me to interface with a higher abstraction I do not care to understand in itself completely. Those "JS REST APIs" however, only try bridge the gap between a SPA and the business logic on the backend. Its endpoints are so tightly coupled to use cases, that they work only under very specific assumptions and parametrization. And that might be ok...
...when your application has to be a SPA for whatever reasons. But look at the rising adoption of server side rendering [SSR]. Suddenly 90% of the impressions of your SPA are rendered by the server. Something has gone very wrong. But don't worry: It's a very common phenomenon in the tech world. We are constantly reinventing the wheel. So what can we do about it?
Personally, I like to "retrofit". Do you know http://todomvc.com/? The page, where the same TODO application is implemented in almost all of the current JS frameworks? I have implemented the same application without JS [1] - only plain old HTML + HTTP (written in Go).
Try it over here: https://todomvc.pbedat.de
Sources: https://gitlab.com/pbedat/todomvc
Is this implementation superior to the other TodoMVC implementations? Clearly not! It's a SPA managing its state only on the client side. But if I want my TODOs persisted across devices, I would not have to think about introducing another layer of complexity: I would just switch my state implementation from cookies, to anything else. And I think, that's a huge bonus.
[1]: I've used inline JS like, `<input type="checkbox" onchange="form.submit()" />` to get more interactivity (tha's what JS was about in the first place)