The Mickeysoft-crowd has and always had their intensions - after all M$ donates
TS plus all the tooling as a present ? yes i assume there is a strategy behind
it. But focussing on what you get with it - there are all these desperate
sometimes even demanding cries for 'typlings'. I wonder how could the WWW exist
without such 'typlings' before ? Jokes aside, my first impression of TS was the
LSP-code, which i needed to understand. And after i translated this disturbing
65-LOC 'interface-description' i found 5-lines that finally did something - the
rest was just bloat. And then i wanted my time back ;) Some people who worked
with TS describe their experience as "the compiler is not helpful when you
encounter a sophisticated/involved problem and the trivial ones, well these are
easy to spot anyway.". I'm pro static typing, but the browser/JS environment is
a dynamic one. Interactive programming, short-lived apps, no code-reuse,
zillions of hot-fixes for browser A not supporting feature B etc. So some
jumped on the TS-train and others who tried and left - like Rich Harris,
express it like "well, its too much a burden too maintain the TS code-base.".
And thats fits my first impression of TS - java-ish declarations all over the
place - a paradise for chatty over-the-top engineering folks. What can TS
really 'enforce' or 'guarantee' in such a dynamic env - not too much - thats
why i call it a 'simulation of type-safety' for the lines you wrote the
TS-compiler may give you some proper feedback, but once your code interacts
inside a JS-engine - you are on your own. The simulation is over and real live
begins. Compared to the JVM or NET which delivers reliable compiletime and
runtime-guarantees, TS seems to sort-of "fake it", make it look-alike. But back
to `ferus` \- thats the name of the ambitious HTML/CSS rendering-package in Nim
- i'm attracted by the idea of a JS-engine without browser-restrictions. Being
small, modular, open, portable and without restrictions - thats not what Bun is
going for. They want to present a alternative to nodeJS for devs thats leaner
and feels a tad more liberated 'cos it handrolled. To me Nim and QuickJS are a
perfect combination. Where Nim says, well OOP inheritance - not so
super-important - if you really want it - we have Objects and Methods for you.
On the other hand - lean, fast and battle tested data-structures, algorithms,
network-protocols and a rich std-lib covering the big-three - there you have
it. A interactive console work-flow can prbly not be Nims strong-part - being a
compiled language - but thats what one wants when working with the DOM or any
OOP GUI-environment. I felt a interesting synergy having solid nim-foundations
and a JS-env that was designed for exchange with a outer world. That easily
allows me to incorporate e.g. parts from nims-std/lib and other packages. And
QJS is well 70-K - its huge, but even for me it was possible to adjust parts in
the C-code if necessary. SpiderMonkey has a reputation for highly optimized and
therefore hard to read code. So imagining a jupiter-alike-notebook-env for
education/learning/testing with QJS on-top and Nim at its core - just a thought
experiment. Portable, well documented, open in all directions - ah one wants to
try Arraymancer interactively and maybe generate some dynamic graph outputs,
ok.. And its compact - one can have it on the laptop on a train without a
internet-connection, cos its just Nim and QuickJS - compact - works even
without a cloud-connection. Persist your workflow, sure Sqlite or
nim-persistence can do that - its all on-board already. You want to play with
NimUI as output engine, ok doable. Wanna do experiments with multithreading and
JS - interesting options here, too. Shared-memory stuff, that evbd. hates :)
Since the minimal QJS-engine clocks in with ~230kb one can have several working
in parallel and exchange data using JS-workers or nim-channels.. So my solid
and apparent misstrust is not at all against static-typing per-se, i very well
remember my first steps with Scala where i felt the compiler "replied with
guiding hints" about my code, instead of the typical "! hey idiot - in line 57
there is a semicolon missing !". - i very much enjoyed such analysis and while
working with nims concepts - sometimes i wish nims compiler could do that ,too
- maybe in the future. BTW regarding nims concepts i found that `Option[int] is
a functor` [
<https://nim-lang.org/docs/manual_experimental.html#concepts-concept-derived-values>
] , but not anymore, at least the playground-instance said "false". Over and
out..
