6 ms·

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

79 points by PretzelFisch 4y ago

jeffrallen 4y ago
Bury it in the desert. Wear gloves.
tomohawk 4y ago
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/ 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.
- deleted 4y ago
  [deleted]
somewhereoutth 4y ago
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.
- aaaaaaaaata 4y ago
  Typescript is the way.
  - lelandfe 4y ago
    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.
    - isleyaardvark 4y ago
      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.
  - tomohawk 4y ago
    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.
    - tadfisher 4y ago
      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.
      - tomohawk 4y ago
        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.
    - bluefirebrand 4y ago
      > 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.
    - infinitebit 4y ago
      this has been solved by several packages, runtypes https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes being my favorite
      - tomohawk 4y ago
        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.
- dmux 4y ago
  >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?
  - hither_shores 4y ago
    The main issue is that LISP supports dynamic scoping, whereas lambdas act like lexically scoped functions.
    - lispm 4y ago
      Supports, but it's no longer the default for local variables. since 70s in Scheme and 80s in LISP.
skinnymuch 4y ago
I would love a [forked] Ruby to replace Javascript. Have it embedded in browsers too.
- deleted 4y ago
  [deleted]
- batmanturkey 4y ago
  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)
  - devoutsalsa 4y ago
    The top framework needs to be called Sapio.
mathgladiator 4y ago
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.
- marssaxman 4y ago
  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!
  - pjmlp 4y ago
    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.
combatentropy 4y ago
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/ 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."
- melony 4y ago
  https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic
  - sreekotay 4y ago
    The project you linked to is erlang, not elang as referenced above.
ramblerman 4y ago
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
- batmanturkey 4y ago
  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.
5350-uiop-1130 4y ago
> 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.
laerus 4y ago
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/ https://wasmcloud.com/) for the backend.
DrFell 4y ago
Millions of JavaScript monoglot voices suddenly cried out in terror. Unfortunately, they won't be suddenly silenced.
janef0421 4y ago
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.

79 points by PretzelFisch 4y ago

Bury it in the desert. Wear gloves.

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/ 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.

deleted 4y ago
[deleted]

somewhereoutth 4y ago

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.

aaaaaaaaata 4y ago
Typescript is the way.
- lelandfe 4y ago
  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.
  - isleyaardvark 4y ago
    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.
- tomohawk 4y ago
  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.
  - tadfisher 4y ago
    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.
    - tomohawk 4y ago
      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.
  - bluefirebrand 4y ago
    > 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.
  - infinitebit 4y ago
    this has been solved by several packages, runtypes https://github.com/pelotom/runtypes https://github.com/pelotom/runtypes being my favorite
    - tomohawk 4y ago
      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.
dmux 4y ago
>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?
- hither_shores 4y ago
  The main issue is that LISP supports dynamic scoping, whereas lambdas act like lexically scoped functions.
  - lispm 4y ago
    Supports, but it's no longer the default for local variables. since 70s in Scheme and 80s in LISP.

skinnymuch 4y ago

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

deleted 4y ago
[deleted]
batmanturkey 4y ago
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)
- devoutsalsa 4y ago
  The top framework needs to be called Sapio.

mathgladiator 4y ago

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.

marssaxman 4y ago
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!
- pjmlp 4y ago
  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.

combatentropy 4y ago

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/ 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."

melony 4y ago
https://github.com/lunatic-solutions/lunatic https://github.com/lunatic-solutions/lunatic
- sreekotay 4y ago
  The project you linked to is erlang, not elang as referenced above.

ramblerman 4y ago

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

batmanturkey 4y ago
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.

5350-uiop-1130 4y ago

> 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.

laerus 4y ago

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/ https://wasmcloud.com/) for the backend.

DrFell 4y ago

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

janef0421 4y ago

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.