Seaside explicitly chose a "heterodox" approach in being session based and producing URLs that are clearly not RESTful. That being said, the Seaside book covers the Seaside REST package which handles building RESTful APIs.
What if the entire system is visible and editable live within a single IDE? - the "entire system" including everything that's running within clients of your service and everything that's running on all your scaled out servers .. and everything that's running in your "IDE".
Without having to make it smalltalk, can we borrow this idea today and implement it in JS?
In the short term, I can imagine a system which exposes a REPL from each backend instance and a websocket-driven REPL from each browser client, and ties them together in a unified interface that allows enumeration and provides convenient syntax for evaluation against multiple targets. Such a system might offer some interesting possibilities around realtime client and server hot-patching and problem investigation, if it could be made bulletproof enough not to also serve as a gigantic SPoF or security vulnerability. But I don't know if it's really similar to what you're thinking of.
I may be underestimating the complexity of this, but it does seem doable with some clarifications to concepts. For example, in the smalltalk world, every GUI object created is expected to be inspectable and modifiable. If we then require that we want to call a button instantiated in every browser an independent object, that would be a misfit. It might be adequate to treat that button presented in the IDE context as the object that manifests on all connected browsers. So when I look for messages sent by the button, I tap into the logstream for those events that the system received from all browsers connected. But when I manipulate its appearance, it reflects on all connected browsers. I don't literally need to tap into each connected browser client.
That would needlessly tie front and back-end, imposing restrictions on both sides for a minimum common denominator.
This really shows its age. NPM is now the preferred choice for both front and backend JS development. I really haven't seen any FE tooling lately that use Bower.
I've been developing JS for years and I've been using NPM for frontend components for... 3 years minimum? Wow, such a quick pace, unbearable.
How is it bad that new tools and libraries are being developed? Nobody forces you to use the new shiny toys until they're established (and almost nobody does, unless you can afford the uncertainty). You call it churn, I call it advancing the trade and getting better tools made for free by passionate people. Some of those get established as de facto standards. Most don't. The churn rate is not high unless you count experimental technology.
> That something using Bower can be considered old really seems quite astonishing to me.
Bower was one of those shiny toys. It's not old: it's just that people used Bower on its infancy and it never got as much traction as NPM did. If someone bets on Bower and then blames churn rate when it gets less traction than competitors... maybe they should stop using the new shiny toys and wait until an established tool emerges?
> FUD is generally a strategy to influence perception by disseminating negative and dubious or false information and a manifestation of the appeal to fear.
In this case I suspect it's self-inflicted FUD and not intentionally trying to misinform other people, but FUD nonetheless.
What has ES5 to do with this? It didn't come out of nowhere - it was being planned for those many years.