I think that was more a function of being the only browser language.
The target of JS wasn't pro developers in those days anyway, so familiarity wasn't really a consideration.
Most importantly, all the "new" features of JS would have existed for 25 years now. JS would have been fast in 1995 instead of waiting until 2008 to be usable. We've take years to add simple things like integers or arrays to JS that would have just been there. We're still debating things like threads which should also have been a solved problem by now. If you didn't like scheme, compiling to the language from another would be trivial too.
Back in 2003-04, around the time of Gmail's launch and the inflection point of the massive explosion of DHTML evolving into Web 2.0, about 95% of internet traffic was using a browser that did support a certain second <script> language other than JS. It really could have gone differently.
>I think that was more a function of being the only browser language.
Sure, that doesn't hurt.
>The target of JS wasn't pro developers in those days anyway, so familiarity wasn't really a consideration
Lisp like syntax is very peculiar. It puts off novices and pros alike.
I didn't really understand you last paragraph other than agreeing that integers should have been there from day one. Array-like objects are not so bad.
`_.reduce(list, function (acc, num) { return max(acc, num); })` vs `(reduce list (fn (acc, num) (max acc num)))`
Very few devs who code in lisp for 2-3 months come away hating the syntax. Hating something strictly because it is different is not a great life perspective IMO.
> I didn't really understand you last paragraph other than agreeing that integers should have been there from day one. Array-like objects are not so bad.
Scheme has a lot more than integers.
* Rational numbers, Complex numbers, integers
* vectors (real arrays)
* Linked Lists
* Proper Tail Calls
* Lazy evaluation (the basis of things like generators, iterators, and the event loop)
* No duck typing
* No weird evaluation rules
* Fast implementations. The fastest like Chez Scheme JIT are very fast compared to v8.
* Macros for new features
Then there are all the common SRFIs standards that pretty much every big-name scheme implements.
* Typed vectors (specify primitive array type)
* Multi-dimensional arrays
* Hash Tables/Maps/Sets
* Multiple value returns
* Records (structs)
* Objects
* Extensive String functions (way more than JS currently offers)
* Multi-threading
* Streams
* And at least 200 more features
Think about ES6+. The features fit into two categories. The first is primitives (TypedArray, Set/Map, const, etc). The second is syntax (class syntax, destructuring, generators, arrow functions, exponent operator, etc).
Those "new" JS primitives have existed in Scheme since the 70s and would have existed in the browser for 25 years now instead of a handful of years. The second class range from unnecessary to already present in macros to easily implemented in macros. There would be no need for transpilers; we could have grown the language without needing all those backward-incompatible language releases.
CSS would be different. The DSSSL proposal (literally scheme) would have replaced the current nasty C-like one.
Likewise, we wouldn't have suffered through XML waiting for JSON to arrive. JSON's syntax is just another expression of lisp lists. `{foo: [1 2 3], bar: "abc"}` would have been immediately obvious as `((foo . (1 2 3)) (bar . "abc"))`. There wouldn't be an extra JSON parser because this is built into the language. XSLT is just very bad lisp macros, so even that excuse would not exist.
Given time, we might have even seen lisp-style lists replace HTML with `<div class="foo">123</div>` becoming `(:div ((class . "foo")) "123")`. If you think about it, this is just `React.createElement("div", {class: "foo"}, "123)`. As this is also dead-obvious, we would have had much better JS frameworks decades earlier and without nearly as much framework churn.
Wasm also wouldn't really be a thing either as Scheme would likely be fast enough and a very reasonable compile target. Type hints like what Common Lisp uses are already very fast (around Java performance and that's with just a couple (amazing) hobbyists rather than a huge, paid dev team). I would note though that wasm uses s-expressions in non-binary form.
This isn't just theoretical. When Paul Graham said Common Lisp was their secret weapon in the 90s, this is what he was talking about. Today, using Common Lisp, you use CL-WHO to turn those s-expressions into HTML. You use parenscript to turn S-expressions into JS. You also use something not too unlike DSSSL to turn s-expressions into CSS. It's lisp all the way down to SBCL which compiles s-expr assembly into binary for the computer to execute.
There are even more results. Initially, Steve Jobs only wanted web apps on the iPhone. It turned out that JS just wasn't fast enough at the time. If Scheme had been the language, the web would have most likely been fast enough for almost everything. The current stagnating Mobile Safari and app store lockdowns would probably have never happened.
Scheme instead of JS would have dramatically altered computing as we know it and I think it would have been for the better.
I agree that Lisp’s “no syntax” is an acquired taste, but asking someone to keep an open mind and use something that peculiar for ≈3 months is a very tall order.
Most people look at the curtain of parentheses and reject it at the spot.
I’d love to have had Scheme on the browser, but I’m not sure it would have succeeded.
