Typescript - now most popular language on github

[paulca]

The ranks have been overrun by script kiddies folks.

I am absolutely dumb founded by this.  Flabbergasted maybe.  I simply cannot understand "Javascript", ie.  THE single WORST language to become even remotely popular, has now put on a dress (Typescript) and is running for president.  What kind of twisted parallel reality have I found myself in?

People try and sell it to me.  I cut them into bits in seconds.  They retreat.  Typescript is still the no. 1 language.

Even looking at the anatomy of the thing.

Typescript - trans-piles into Javascript - via "Type erasure"
Javascript is then compiled and run via a C++ runtime in the V8 backend and executed live on the CPU.

No sandboxes.  No Types.  No type safety.  A language which struggles to tell you if 2 is a number or not.

Seriously.  WTAF?

Its Javascript with annotations and comments used by a parser to write Javascript without any!

[Siwastaja]

What language would you prefer for dynamic websites?

[Kalvin]

Take any programming language, and run the source code through the compiler, you will get assembly code or vm code. Practically no type information will be preserved. So, your rant applies not only to Typescript but every other language too.

Typescript, and other statically typed languages, perform type checking at compile/transpile time, so there is no need to do it again at run time.

[paulca]

Take any programming language, and run the source code through the compiler, you will get assembly code or vm code. Practically no type information will be preserved. So, your rant applies not only to Typescript but every other language too.

Typescript, and other statically typed languages, perform type checking at compile/transpile time, so there is no need to do it again at run time.

This dichotomy fails with Javascript specifically because the intermediary layer strips types and executes as a very, very confused type inference system at runtime.  It's not that the javascript is written to validate types, its not.  The typing is literally stripped.  In it's place is Javascripts own "inference" at runtime.  The two do not obey the same rules.

All strongly typed languages aim to enforce types down to the ASM.  Javascript does the opposite.  It has not really "compile time binding" at all.  Only runtime type binding.

So for example.

"2" - 2 = 0
"2" + 2 = "22"

[paulca]

What language would you prefer for dynamic websites?

Oh boy.  You think it's just script kiddies doing websites in react?

That era ended with a few Javascript "innovations".  The C++ runtime which permitted Javascript to run as a "First class process".  ie.  Not in an interpreted sandbox, but live on CPU.  Javascript->C++ runtime->ASM direct.

Then there was "Node.js".  Wrapping the JS engine to create an actual server process running in.... Javascript.

This is now used to run everything from the front-ends you talk about to the REST APIs and on into the actual emperical backends in all ranges of business applications.

Javascript is well established in the backend and on server these days.  Not just "React" and "Angular" Web2.0 stuff.

And it still can't tell you what "2" is.

https://medium.com/dailyjs/the-why-behind-the-wat-an-explanation-of-javascripts-weird-type-system-83b92879a8db

[paulca]

The real reason, i you accept my argument here.

The industry wants cookie cutter, "Fungable" developers.  They want the maximum "talent" pool size to negotiate rates down.  The want to dearm specialists.

If you do a survey of CVs you will find that more than 90% of developers will list Javascript on the CV.

In MOST of those cases it is not stated as a "preference" or a "skill they choose", but as "Nobody can avoid it.  It's everywhere.  You will end up touching JS somewhere these days."

But the industry looked at this and thought... "If the front-ends, web apps, mobile apps and backends, even core components can be written in Javascript and 90% of developers list Javascript we can just hire "One size fits all" developer and negotiate the salary down on competition basis.

Javascript without the Typescript dress is as dangerous as you would expect.  "Linters" and "Static analysis" tools basically just morphed into Typescript, making the "linter hints" into "Annotations and decorators" in the language.  The same guy who did C# for Microsoft is responsible for Typecript.

Now the industry is embracing Javascript in a Typscript dress everywhere and no... it not increasing quality, quite the opposite.

Its "Lowest common denominator" is what Javascript is for the developer pool.  Its just that the industry read this as something to follow as a positive thing to do.

[paulca]

Speaking of that talk that page refers to .. if you watch it today (link below).  Notice how the "WAT?" photos cannot be AI generated due to the era.  They could have been photoshopped and might have been, but that era is also gone now.  Anytime you see something "Bizarre and out there" you will assume it was AI generated.

[Siwastaja]

What language would you prefer for dynamic websites?

Oh boy.  You think it's just script kiddies doing websites in react?

No, my question was honest. What language / libraries / frameworks would you use for dynamic web? I'm interested in your opinion. Familiarity (thus, availability of people who have used the language before, or volume of AI training material) has real value, but not infinite; if something is crap enough, some less known alternative could beat it.

Our service is typescript / react. Most of the pain points have been related to state storage design (state mutation logic, storage itself, race conditions), I don't remember much problems with the typing system. I guess most of the problems we have dealt with would have happened in any language.

[artag]

Don't forget github is no longer representative of a wide sector of users.
It's now just people who can stomach microsoft's abuse.

[paulca]

What language would you prefer for dynamic websites?

Oh boy.  You think it's just script kiddies doing websites in react?

No, my question was honest. What language / libraries / frameworks would you use for dynamic web? I'm interested in your opinion. Familiarity (thus, availability of people who have used the language before, or volume of AI training material) has real value, but not infinite; if something is crap enough, some less known alternative could beat it.

In fairness Typescript is probably the right language for that.  With React.  Why?  It's the most common, the most used, has the ecosystem mass.

It does not make it "good" though.  You will no doubt have witnessed the cesspool which is "NPM".  Its just one bug security vul nested inside itself.  Literally filthy with trojans.  CVEs a dozen a day or more.  Wide open to exploit and .... nobody has a choice but to keep playing.

I recommend a few things. Lock your npm versions in your package.json.  Specify the exact version you ran tests against.  Do not use "latest", "stable" or any logical tag.  For even higher security focused needs, specify the git commit hash or tag hash of the code version you want, this prevents people simply pushing an exploite to an old version branch and your NPM auto pulling it.

You see as a backend dev, I don't care if your web UI gets hacked, corrupted or writes junk crap code with can't tell if something is a number, an ojbect, an array or a string....  I will validate it at the back end and tell the UI to go away.  When they ask me to write that back end in Typescript is when my heckles come up.

Our service is typescript / react. Most of the pain points have been related to state storage design (state mutation logic, storage itself, race conditions), I don't remember much problems with the typing system. I guess most of the problems we have dealt with would have happened in any language.

By "state storage" what do you mean?  Can you expand on it.  Do you mean "persistence of record" or do  you mean "inflight state"?

Storage is always a funnel for race conditions because it is usually where you cross a "clock domain" from sub nano-second timings to milisecond timings.  Trains that run down the line in memory don't reveal there are no signals on the track.  Those same trains finding themselves entering a slow down for an SSD write make it obvious a red signal was a good idea at least somewhere.

Typescript's other little convention "async/await" is NOT what you think it is.  Thus it will tend to hide the problem above right up until it doesn't.

The Typescript runtime is single execution limited.  It's a single process.  However those keywords amount to "almost threads".  Single process execution + threads appears to be "thread safe" until it isn't anymore and then it hurts.

What "await" does is say, "You can skip this, this time, it's not ready to execute".  The actual execution thread then moves onto the next thing in the waiting list.  Round robin.

So each train is advanced down the line one at a time.  Nothing colides.  But it does not stop on of trains simply stopping at a station and even though each one is advanced independantly, there are not checks for running in the train in front.  It will just produce an error if you are lucky or silently corrupt state in the worst.

[paulca]

I updated the post prior, might be worth a re-read.

On ways to manage it... thats a book... broadly the industry trend has been towards "immutability in concurrency".  Basically you define your state and transitions which occur to it to "Create NEW states".  Never ever updating existing state.

State mutates as copies.

The downside, Im sure you can see.  Memory costs and churn.

You will see this pattern ignorantly repeated/parroted.

async aThing( param: string ) {
const deTaintedParam = detaint( param )
const serdesObject = serdes(deTaintedParam)
const validatedObject = validate(serdesObject)

and so on.  Everything declared, allocated and then left there to be collected on descope.

[Siwastaja]

By "state storage" what do you mean?  Can you expand on it.  Do you mean "persistence of record" or do  you mean "inflight state"?

In our case - collecting the "pending configuration" json from the UI element clicks to local storage, and when SAVE button is pressed, sending the user's configuration - what options they clicked - correctly to the server. This proved to be more difficult than it sounds. I think originally the react version we used killed the elements inside accordion when the accordion was closed, so local storage "pending configuration" workaround was added. Later version supposedly fixed this, but the workaround remains. Some configuration fields are initialized when a menu is entered. Some "enabled" field is hard-coded to 'true' when an appliance configuration exists (so always when its configuration page is entered). You would think hard-coding "true" on a variable is one of the easiest programming problems known to human kind - and yet, one time out of 10, that "enabled" field is false, and no one knows why. The solution is to hard-code it to 'true' again just when the SAVE button is being clicked.

Browser translation tools that manipulate the DOM objects and make the perfectly valid page crash are the nastiest thing we have had to deal with, because it's impossible to fix something which isn't broken - if Google Chrome takes a perfectly valid piece of code and breaks it and then shits its own pants, what can we do? Report a bug to Google? Tell the customer Google is broken? Neither is realistic - so we need to just try to do random things until it doesn't crash anymore in Google Chrome, and hope that the next day Google Chrome isn't broken in some other way. This is quite similar to how web has always been, "test your site on every possible browser and iterate randomly until it works".

[paulca]

By "state storage" what do you mean?  Can you expand on it.  Do you mean "persistence of record" or do  you mean "inflight state"?

In our case - collecting the "pending configuration" json from the UI element clicks to local storage, and when SAVE button is pressed, sending the user's configuration - what options they clicked - correctly to the server. This proved to be more difficult than it sounds. I think originally the react version we used killed the elements inside accordion when the accordion was closed, so local storage "pending configuration" workaround was added. Later version supposedly fixed this, but the workaround remains. Some configuration fields are initialized when a menu is entered. Some "enabled" field is hard-coded to 'true' when an appliance configuration exists (so always when its configuration page is entered). You would think hard-coding "true" on a variable is one of the easiest programming problems known to human kind - and yet, one time out of 10, that "enabled" field is false, and no one knows why. The solution is to hard-code it to 'true' again just when the SAVE button is being clicked.

This sounds like a react state issue.  I haven't really used react in anger, but it sounds familar to an Angular scope issue.  Those frameworks typically use a "scope" isntance.  A context if you will.  When it updates it is meant to notify any promises or waits on such an update, so they update the view.  That whole mechanism is complex and it's easy to get into issues because the updates are async and in effectively random order.

So what you can have is ... one thing gets triggered and sets a field to the default.  Then another fires to set the field to "enabled".  The process works.  WooHoo.  Except on a certain Tuesday of the month they arrive in the other order.  Now your field is set to false.

Browser translation tools that manipulate the DOM objects and make the perfectly valid page crash are the nastiest thing we have had to deal with, because it's impossible to fix something which isn't broken - if Google Chrome takes a perfectly valid piece of code and breaks it and then shits its own pants, what can we do? Report a bug to Google? Tell the customer Google is broken? Neither is realistic - so we need to just try to do random things until it doesn't crash anymore in Google Chrome, and hope that the next day Google Chrome isn't broken in some other way. This is quite similar to how web has always been, "test your site on every possible browser and iterate randomly until it works".

Yes.  Welcome to Javascript.  Your first question is always, "Which one?"  Same for DOM.  There are just no standards... or rather there are many standards.  Google in particular where those who de-sandboxed it and gave it a C++ engine "V8 Engine".  However, chrome itself is updated weekly.  It' s behaviour changes and it's JS and DOM APIs change too.  The only solution is to keep updating everything and supporting "latest" browsers only.  That familiar carrot and stick.

A claude funny for you in passing.  Had trouble flashing to a new FPGA dev board.  Ask claude.  It found the /dev/sde for the mass storage.  Discovered that users are not allowed to mount filesystems, so ... undefeated and beig able to access the device file itself... it just hex dumped the whole device!  I had to LOL outloud.  I would hate for this thing to hack me.

[Kalvin]

TypeScript-to-Native Compiler: Ordinary TypeScript becomes a small, fast native binary — no Node, no V8, no JavaScript engine required.

https://scriptc.dev/

[SiliconWizard]

I find Typescript uninteresting, but for the record, VSCode, which is pretty popular, is written in Typescript AFAIK. Just to put things in perspective...

As to "most popular languages" stuff, you know how much these rankings mean. Especially when github is MS-owned and Typescript a language owned by MS (although it is technically open-source MS still has a copyright over it, manages the project and promotes it.)

[brucehoult]

I find Typescript uninteresting, but for the record, VSCode, which is pretty popular, is written in Typescript AFAIK. Just to put things in perspective...

A lot of money has been put into making Javascript fast. It JITs in practice about as well as Java or C# and an order of magnitude faster than Python. Running it with nodejs is a very practical way to do scripting-style programming that runs a lot closer to C speed than bash or Python or Perl. It has a huge library of 3rd party modules too.