Relatively little work on it in a long time. I think to bring smalltalk into the web world takes a different kind of think than a straight port to Js. The dev environment needs to seamlessly cover backend and frontend and be live editable. That would also need protections. Few of this has been accomplished to date. Good project for an undergraduate Cs degree student I guess.
Have you looked at http://seaside.st/ ? Seaside has been around for a while; it offers a component based approach to building web applications from objects, including an in-browser way to inspect and modify the code of displayed components. It also offers a DSL for writing HTML, along with some support for jquery. There is also a free book to teach how to use Seaside to develop webapps, including dynamic frontends (but not a full SPA, I think): http://book.seaside.st/book
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.
Neither of these do justice to the paradigm introduced by smalltalk. Both cases are lifting the least significant aspect of smalltalk - the single self-contained VM - and making it available within a browser. This is far from acceptable from the perspective of developing systems today. It is an SPA in the extreme and you got to take care of the backend in some other way.
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?
Designing a reliable system which combines widely distributed computing and Smalltalk-style integration appears to be a significant CS research problem.
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.
The REPL way of thinking may not be the right level for this kind of a system.
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.
I probably wouldn't want to use a REPL like that much in its own right, but it might make a good foundation on which to build something Smalltalk-esque.
Not in my experience with JavaScript. You have a large common denominator (including libraries), and only a few specific things that don't work in browser (like filesystem) that still work serverside anyways.
> Bower is a package manager for the web. It makes it easy to manage dependencies in your application including Amber. Unlike npm, Bower components are meant to be used inside the web browser.
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.
The endless joys of the ever-shifting sands of the frontend world. I'm pleased there's movement in trying to make it better, but part of me really, really hopes it all settles down soon. That something using Bower can be considered old really seems quite astonishing to me.
I'm sick of this lie, mostly parroted by people that haven't touched frontend in their life, or who do frontend but betted too early on technlogy that never got traction. It feels like it's just an excuse to pick on frontend. If nothing new was developed everyone would point out how stagnant JS ecosystem has become.
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.
It's not rapid cycling until it's rapid, before that it's just a cycle. I thought you were referring to ES5, otherwise I have no idea what you mean - JS tooling wasn't going anywhere very quickly before ~2010
