← Back to context

Comment by criddell

5 hours ago

> makes supporting client side applications so much easier

I was thinking that supporting a Smalltalk application must be a nightmare because it is so malleable. Users can inspect and modify the entire system, no?

I used to think so, then watched as javascript in the browser rose to be the premium application platform - where the user has access to a console/repl, developer tools etc...

  • I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though.

    The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug.

    The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.

    • Yes, but maintaining a webapp isn't a nightmare due to the user being able to inspect css, edit html or access the javascript console?

End users? Yes if you - want them to - let them; No if you - don't want them to - stop them.

> Users can inspect and modify the entire system, no?

That should make the Smalltalk family popular with free software proponents. That makes me curious why that is not the case in history. The efforts of FSF on Smalltalk pale in comparison with those on C, Lisp and other languages.