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
I'm not a big fan of the Smalltalk language, but I think Smalltalk's greatest contribution to development was putting forward the idea that development environments are important for productivity.
Actually, Lisp did that first (as did Emacs). But yes, ST popularized the idea (which is somewhat paradoxical, as, like Lisp, ST never actually caught on).
You're not wrong, but I read that as 'thank': had it not been for Sun & Java, then maybe — just maybe — the development industry would have advanced beyond the 1960s/early 1970s.
Can you imagine if the standard language of enterprise development today were Smalltalk? Can you imagine if the standard language of the Web were Lisp (or Scheme)? Can you imagine if we'd sunk all the work into making Lisp & Smalltalk great that we instead sunk into making Java & JavaScript not so terrible that they cause spontaneous seppuku?
If I'm not mistaken, Brendan Eich wanted Scheme to be the language of the browser. We ended up with JavaScript because Netscape pushed the whole "make it look like Java" agenda. We still got first-class functions out of it. But we also inherited a direct port of Java's Date class.
Can you imagine if the standard language of enterprise development today were Smalltalk?
That would've meant that TDD would've had to have been de rigeur. So likely, this would've been an alternative universe where Extreme Programming got created earlier to overcome some of the weaknesses of Smalltalk as an enterprise language. It would also have helped if some of the internecine fighting between Smalltalk companies (and parts of merged Smalltalk companies) didn't happen. Also, this would have required an ANSI standard for Smalltalk that wasn't manipulated by big companies into something toothless and hazy. This would've helped to create a more cohesive greater language community outside of individual implementations. Because of the toothless standard, combined with the ease of rolling your own, the Smalltalk community balkanized itself into different incompatible dialects.
Can you imagine if the standard language of the Web were Lisp (or Scheme)?
There would have been, possibly, a true "write once run everywhere" environment. Squeak demonstrates the feasibility of this. The thing runs with a bit identical virtual machine model on something like a hundred different platforms. However, there would have been a serious rash of network security problems. Because it's hard to prove things in Smalltalk, the preferred model for web app security was signed code, which is far from a panacea. There were some people thinking about sandbox schemes, including myself, but Smalltalk VMs are also generally prone to the same kinds of security holes as other VMs, like Dalvik.
Can you imagine if we'd sunk all the work into making Lisp & Smalltalk great that we instead sunk into making Java & JavaScript not so terrible that they cause spontaneous seppuku?
Actually, Sun approached ParcPlace -- or whichever was the "original" Smalltalk company at the time -- and asked to use their VM for their set top box project. The Smalltalkers rebuffed them, so they went on to create their own VM. This Java was born. Smalltalk was almost Java, and missed its chance many times over, mainly because of culture. Smalltalk could've been LightTable decades earlier, if we'd only had faster hardware, the internet with something like YouTube, and a better community attitude towards outreach.
JS doesn't cause spontaneous seppuku. For all it got wrong, there's a surprising amount it got right. Like lexical closures, lambdas, and OO (mostly). You know, the big stuff.
OTOH, Java makes me want to stab myself repeatedly. It's literally less pleasant than assembler. It's object-oriented COBOL with a pretty face.
Terminals are effectively guaranteed to be there when all else fails: whether that be due to a misconfigured computer, or to a slow connection that means that you're using SSH only, or because you're stuck using a rubbish chromebook linked to your Real Computer back home via SSH (which happens to me a lot).
So while I admire things like acme and smalltalk, my personal philosophy, partly for flexability, and partly out of necessity, is that if you can't run within a terminal window, I can't depend on you, or integrate you too heavily into my workflow. Because when I need you most, you'll let me down.
This is the second reason I hate most IDEs, by the way. The first reason is that most IDEs believe that if your language is verbose, the solution is more automated code generation. I believe that if most of your code is being generated automatically, you need a new programming language.
Naturally, the Smalltalk IDE gets a pass, because it's not an IDE in the common sense. It's more like a real-time introspective debugging environment which you happen to write all your code in. It's not even technically required for the language, as GST aptly demonstrates.
But the first time you use the smalltalk debugger, you'll be sold on it. You'll want it thr smalltalk IDE in every language. Sadly, this isn't possible, unless you're a lisp programmer with either A) a lot of money or B) a lot of spare time on your hands, you can't have it.
Once upon a time, for a time, I had no computer at all. WYSE-50 amber CRT terminal (public library discard), hooked up to a 14.4kbps modem and a land line for contract work.
Basically the whole workspace concept or how Netbeans used to mount directory into projects feels like it was a mechanism to replicate the image concept using files.
