7 ms·

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 e

by sriku 10y ago

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.

fniephaus 10y ago
Here are two other approaches: https://lively-kernel.org/lively4/lively4-core/start.html https://lively-kernel.org/lively4/lively4-core/start.html https://squeak.js.org/demo/simple.html#fullscreen https://squeak.js.org/demo/simple.html#fullscreen
- warent 10y ago
  "lively-kernel wants to permanently store large data on your device. Continue?" Pardon?
- sriku 10y ago
  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?
  - throwanem 10y ago
    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.
    - sriku 10y ago
      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.
      - throwanem 10y ago
        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.
spraak 10y ago
> 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.
- mathw 10y ago
  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.
  - warent 10y ago
    Wtf is npm? Everyone uses Yarn these days. Get with the times
    - wiz21c 10y ago
      Still using an open source package manager ? C'm'on...
  - spraak 10y ago
    The benefit is that hopefully from rapid cycling we can settle on tooling that is really good
    - regularfry 10y ago
      The risk is that people won't settle on the best for long enough to allow network effects to show its true strengths.
    - zepto 10y ago
      It's been decades now - when do you imagine it will settle?
rbanffy 10y ago
> The dev environment needs to seamlessly cover backend and frontend and be live editable That would needlessly tie front and back-end, imposing restrictions on both sides for a minimum common denominator.
- kaoD 10y ago
  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.
muraiki 10y ago
Have you looked at http://seaside.st/ 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 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.

by sriku 10y ago

fniephaus 10y ago

Here are two other approaches: https://lively-kernel.org/lively4/lively4-core/start.html https://lively-kernel.org/lively4/lively4-core/start.html https://squeak.js.org/demo/simple.html#fullscreen https://squeak.js.org/demo/simple.html#fullscreen

warent 10y ago
"lively-kernel wants to permanently store large data on your device. Continue?" Pardon?
sriku 10y ago
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?
- throwanem 10y ago
  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.
  - sriku 10y ago
    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.
    - throwanem 10y ago
      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.

spraak 10y ago

> 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.

mathw 10y ago
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.
- warent 10y ago
  Wtf is npm? Everyone uses Yarn these days. Get with the times
  - wiz21c 10y ago
    Still using an open source package manager ? C'm'on...
- spraak 10y ago
  The benefit is that hopefully from rapid cycling we can settle on tooling that is really good
  - regularfry 10y ago
    The risk is that people won't settle on the best for long enough to allow network effects to show its true strengths.
  - zepto 10y ago
    It's been decades now - when do you imagine it will settle?

rbanffy 10y ago

> The dev environment needs to seamlessly cover backend and frontend and be live editable That would needlessly tie front and back-end, imposing restrictions on both sides for a minimum common denominator.

kaoD 10y ago
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.

muraiki 10y ago

Have you looked at http://seaside.st/ 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 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.