i love smalltalk, but i mainly do web development, and i was curious to do frontend development in smalltalk, so amber looked interesting. but i could not see how to do frontend only development. i am not interested in fullstack solutions because they only work for greenfield projects. i mostly build frontends for existing backends with a REST API or similar.
existing smalltalk webframeworks are either backend or fullstack, and made no sense for me to use inside amber.
an amber frontend framework would essentially be a GUI toolkit that uses html/css templates to design the UI, then smalltalk to fill in the logic with fetch calls to exchange data with arbitrary backends.
> i am not interested in fullstack solutions because they only work for greenfield projects. i mostly build frontends for existing backends with a REST API or similar.
There are probably other reasons to avoid a full stack framework, but this isn't one—there's nothing to stop you from making the backend just a proxy to the existing API.
Aside from that, Amber is entirely client-side from what I can see. The Amber server is the equivalent of the Webpack or Vite dev servers, just used during the development process. It looks like Amber compiles to plain JS that runs directly in the browser.
yes, amber is entirely clientside. that is what makes it interesting. but the smalltalk web frameworks are mostly backend frameworks designed to run in pharo or squeak, which means they feel way to bulky and not suited for an SPA web frontend were i want to dynamically update the DOM when data changes instead of generating a whole new page to send to the browser like traditional web frameworks.
there's nothing to stop you from making the backend just a proxy to the existing API
what is stopping me is that this forces me to run two backends and an additional layer of indirection.
i have actually looked into this at the time, but i could not figure out how to make it work with the frontend framework i was using. and i didn't find any more extensive tutorials either. it probably takes more familiarity with amber than i was able to get to make it work.
a tutorial to use amber with react or svelte for example would be great. (i don't work with either, but given that they are a,mong the most popular frameworks for the time being, it has the most likelihood at capturing some interest.)
I totally loved the idea at first. In practice it became kind of what CoffeeScript is to JavaScript, which is not a lot more than a syntactic preference that doesn't help you when you need to debug. Actually hurts you a little bit because that indirection forces you to become the cognitive mapping of their differences. You eventually can become a comfortable "Smalltalk" author in LitleSmallscript and a decently productive JavaScript debugger but at the end of the day it just became easier to be polyglot and not have it as barrier to share code with other devs when needed. So I didn't ended up using it for any project.
that makes sense. i have been using coffeescript, and i know what you mean. the main draw for a different syntax for me was readability as coffeescript had some advanced constructs that javascript didn't have, but since then javascript has caught up and so coffeescript no longer offers that much of a benefit that it once did.
in difference to coffeescript smalltalk at least offers the benefit of a syntax that is also usable elsewhere.
I think it was in 2016 that I've used CoffeeScript for one project for some months. With daily usage I ended up acquiring taste and ended up enjoying it.
For LittleSmallScript I knew the syntax taste will go to the roof. And you're making a great point, indeed parts of a program written with Smalltalk syntax would have a lot degree of reuse.
this doesn't solve the problem. i am not looking for a smalltalk desktop that can run in a browser, but for a smalltalk based web gui toolkit that uses html/css for its interface.
to bring it to a point, i'd like to use smalltalk with a web framework the way i use typescript or coffeescript with angular or react
existing smalltalk webframeworks are either backend or fullstack, and made no sense for me to use inside amber.
an amber frontend framework would essentially be a GUI toolkit that uses html/css templates to design the UI, then smalltalk to fill in the logic with fetch calls to exchange data with arbitrary backends.