'The best thing we can do today to JavaScript is to retire it’ Douglas Crockford | Hacker News Reader

'The best thing we can do today to JavaScript is to retire it’ Douglas Crockford

devclass.com

79 pointsPretzelFisch32 comments

I'm intrigued by his replacement, the language E. Even though it arose in 1997, I was unfamiliar with it. I like what I have seen so far, http://erights.org/elang/

I'm relieved that Crockford suggests a substantial alternative, and wasn't just bashing JavaScript. In fact I was surprised by the headline, given his history of defending the language. Instead of just suggesting another popular language like Python or Ruby, he is more specific: "It needs to be a minimal capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered."

https://github.com/lunatic-solutions/lunatic

The project you linked to is erlang, not elang as referenced above.

However, there could be a really nice language emerging from the swamp.

Arrow notation, destructuring, functions as first class with underlying lambda calculus semantics (as opposed to lisp), async/await, back tick templating - strong features. Just need to get rid of the old cruft. Typescript and friends seem a good first step towards an implicit type system.

Typescript is the way.

As a JS veteran who’s a newcomer to TS, it’s frequently mind blowing (so many user errors caught), but it is quite unwelcoming. The ‘tsserver’ errors are often useless, and the syntax feels arcane and terse.

I think I’ll probably get used to it, though.

I felt the same way at the start but I got used to it reasonably quickly. I already really appreciate its value even though right now I'm still basically a beginner.

Typescript only has compile time checking. There are so many sharp blades that allow that to be bypassed. For example, deserialize something into a variable you've declared to be a certain type, and viola. The typing is incredibly weak.

Most static languages only have compile-time type checking, because storing and checking runtime type information is usually not worth the cost. The problem with your example is the deserializer, which in a static language would be generated and include those runtime checks. I'm sure something like this exists for Typescript, it's too common a problem not to have been solved.

In Go, can I declare a Foo, and deserialize into it, but instead of a Foo, it is a Bar? No.

Typescript also doesn't catch cases where metaprograming is used when calling a function. You can put anything you want in there.

> For example, deserialize something into a variable you've declared to be a certain type, and viola.

I'm pretty sure your linter will catch this.

If you don't have a linter, get a linter.

this has been solved by several packages, runtypes https://github.com/pelotom/runtypes being my favorite

Thanks for the pointer to this, but this also makes Crockford's point about the need for a language that does this sort of thing and my point that in order to achieve safety, you need to know about such a package and manually employ the package. The compiler will not help you if you make a mistake in manually employing the package, or if you forget to use it, or if you don't know about it.

Have you seen the runtypes library? It lets you specify your type using a syntax very similar to normal TS type syntax. It then provides parsers for that type that throws errors if the input doesn’t conform to the type. It’s very useful. If anything, the library will impress you with how well it handles arbitrary types as well as how strong the TS type system is.

Please don't blame Viola for your careless deserializations.

>functions as first class with underlying lambda calculus semantics (as opposed to lisp)

Do you mind elaborating on this? How does lambda calculus underlie JS/TS functions but not functions in LISP?

The main issue is that LISP supports dynamic scoping, whereas lambdas act like lexically scoped functions.

Supports, but it's no longer the default for local variables. since 70s in Scheme and 80s in LISP.

Trying to get an average new developer up to speed in a modern JS environment is ridiculously hard. There are so many things that only exist due to historical accident. It's basically a big ball of mud, where being a swamp guide is more important than being an engineer.

http://laputan.org/mud/

As a big ball of mud, it will be really hard to replace. There's too much value in being a swamp guide, so the swamp guides will resist anything that will take away from their status.

Webassembly is the way forward. Why create a new language when you can use any language though WASM. It is already built around capabilities and you can implement an actor system easily, something that has already been done (https://wasmcloud.com/) for the backend.

I would love a [forked] Ruby to replace Javascript. Have it embedded in browsers too.

Let’s go all the way: brainfuck interpreter as the only browser scripting engine. Then we will know that frontend devs are real programmers. (/s)

The top framework needs to be called Sapio.

In my opinion, the web in general should be retired. It's ultimately a technology originally designed for rich documents that has been feature-creeped to be a general-purpose application platform, and that results in a variety of issues. I think we should move towards using domain-specific open standards.

> But since then, there has been strong interest in further bloating the language instead of making it better.

Totally agree. JS the Good Parts is what got me into JS around 2007. It used to be so accessible, this neat subset of features, coupled with the DOM.

The web in general has the problem of a million ways to do the same thing, and none of them works quite right.

I actually think we need to teach a different way of using and embrace client minimalism with streams.

Even though I suspect stadia is going to get shutdown, I believe in using the network as the computer with edge computing to turn the browser into a dumb terminal. This is the basis for the web framework that I am making.

I'm having lots of fun.

Give it 5-10 years and it'll be all about fat clients again.

Another 5-10 years after that, there will be a hot new idea: thin clients!

Fat clients are mobile phones and tablets.

On the desktop all OS vendors are messing the fat client development story and more 10 years won't help fix management, sadly.

Bury it in the desert. Wear gloves.

Millions of JavaScript monoglot voices suddenly cried out in terror. Unfortunately, they won't be suddenly silenced.

The JS community has done some awesome things to bring the language to a more mature and interesting place, in spite of Crockford.

His awful book that tried to teach JS like Java, and his framework at yahoo called YUI stood more in the way of progress than anything else.

Criticism is certainly warranted but I don’t see him having a track record of creative and interesting thought in this space to offer it

There’s a JS community? I thought it was more that none of us had any choice in frontend languages.

I can’t say that any long running production process like a webserver ever benefitted from leaking memory like a sieve and being a single threaded event loop designed for a UI event loop, but hey, someone has to keep cloud providers awash in cash.

Gotta love the need for tools like forever and such…

In the browser? There’s a deliberate 10 year period where certain browsers made a point to not support or rather distort standards, and another decade before that where a certain vendor that rhymes with bicrosoft featured embrace-extend-extinguish tactics that didn’t achieve much but annoy devs, but I digress. It’s a bit like CSS, aka a mess. You memorize a caniuse table and always polyfill promises

I vote for just hijacking flash and action script and force FOSSing it and just call it a day.

Reply on news.ycombinator.com