32 ms·

Douglas Crockford on JavaScript

165 points by lrsjng 3y ago

raxxorraxor 3y ago
> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more closed Platforms like Discord. I use it too, the product is completely fine, but it sucks in information that isn't availble on the open net if you don't go through the platform. Some communities exclusively use it and they get little discoverability through web searches. Sure, this isn't really related to Javascript/Webassembly, just a development I fear will increase and which could be accelerated with different approaches to languages. A front-end scripting language available in every browser is very, very useful. I think few new languages could replace it here, I don't know of any at least. And I think a lot of flexibility is lost if you begin to transpile anthing into Javascript. Granted, for large projects it is pretty much a requirement to do so at some point.
- smole 3y ago
  Worse than trying to replace it entirely is that you just end up with two implementations that need to be maintained.
- chii 3y ago
  > [closed platforms] will increase and which could be accelerated with different approaches to languages. the business incentive is towards such closed platforms - data and platform ownership has value after all. It makes zero sense for a business to keep a platform open and potentially help a competitor.
  - raxxorraxor 3y ago
    I disagree, it would be in their interest to somehow gap that border in the long run, although I wouldn't know an easy way to achieve this. Its users often tend to not understand the repercussions in my opinion and that is true even for software developers. Sure, an exchange on Discord is easy and personal, you get ample support from your supporters and that can really propel projects to the next level. But as I said, all the knowledge from these exchanges is lost for the net. The user that comes 2 years later won't see these exchanges and not even you product in some cases. I would always suggest to also use some kind of forum or knowledge base. Discord has APIs to make such content discoverable as well in theory. I use the platform too, it shouldn't be seen as an indictment for the Discord developers at all. On the contrary they offer an extremely useful service and in most cases completely for free and it shows that they care for the platform. But just as things are, we have it as something separate to the usual web and I believe that some communities suffer if they do not provide alternative venues.
- diego_sandoval 3y ago
  > The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don't know how good CSS is in comparison. And what could we replace HTML with? My general appreciation, from my ignorance, is that they are not that bad.
  - Latty 3y ago
    Seriously, every time people complain about CSS and HTML I think about how much work it is to support all the localisation and layout stuff they do. Managing massively different sized screens as elegantly as them is hard and yeah, it's still not that elegant or easy, but I haven't used anything better that didn't sacrifice something for it.
    - geektips 3y ago
      Absolutely, I totally agree. Layout development has gotten a lot better with Flexbox, Grid, and the new Container Queries.
    - SenHeng 3y ago
      Every time I have to build a UI in canvas, I yearn for all the conveniences CSS and the DOM provide. Do people even realise how much trouble it is to make text wrap within a given space?
      - Solvency 3y ago
        It is, but yet thousands of videogames have been doing this for decades...
        SenHeng 3y ago
        And most games will use an engine like Unity or Unreal so they don't have to re-invent the wheel. HTML and CSS may not be perfect, but they've been battle tested for a good 30 years and have had improvements added. No need to re-invent that wheel.
- stavros 3y ago
  Discoverability for communities is a really good point. I wonder if any chat software exists that allows easy/good indexing by search engines.
- yxre 3y ago
  Nobody will ever agree on an alternative. And, none of the attempted alternatives have ever taken off because the velocity of javascript's incrementalism is far greater than the velocity of any new shiny thing. JS has the weight of the largest corporations in the world behind it that don't want to lose their investments
revskill 3y ago
Most of boilerplate code i wrote is mapping data structures between API standards. None of the is related to javascript. So i won't stop using javascript.
andix 3y ago
First we need a good alternative. JavaScript may not be the best, but it works well.
- yxre 3y ago
  He has been saying this for a decade. I had to double check the dates to see if it was even relevant. A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. Performance with V8. Object lifecycle management has had improvements from ES6 WeakMap and WeakRef although JS will never have RAII. ES6 also added more data structures. No new alternative will be able to keep up with javascript's incrementalism
  - svieira 3y ago
    I'm not _entirely_ sure which RAII you mean, but if you mean something like C#'s `using` or Java's `try-with-resources` or Python's `with`, then https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... and https://github.com/tc39/proposal-async-explicit-resource-management https://github.com/tc39/proposal-async-explicit-resource-man... are in stage 3 (of 4 stages) in ECMAScript's language proposal lifecycle and will be coming to a JS engine near you behind a flag soon-ish.
  - paulgb 3y ago
    > A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. (author here) - I disagree. If V8 solved performance, we wouldn't see so much of the JS tooling stack being rewritten in Rust. Modern JS runtimes are fast because they are tuned for the types of workloads that are common on the web. This is great for the performance of a virtual DOM, but if you go off the beaten path of workloads that the browser is used to, you're still limited by the performance of the runtime. JS has improved for sure but it’s always going to be slower than a language with a BDFL because it has so much legacy baggage and political consensus-building required. IMHO WebAssembly is the right approach: standardize a minimal bytecode and let languages compete on innovation.
glutamate 3y ago
Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.
- quaintdev 3y ago
  How about Dart/Flutter?
  - glutamate 3y ago
    I forgot to add "not controlled by a single corporation" to my list of requirements. Also not gradually typed, I think? But I would consider it if it weren't all tied into Google and had a larger ecosystem.
    - planede 3y ago
      Isn't Typescript "controlled" by Microsoft?
      - glutamate 3y ago
        This is a good point, yes you are right about that.
      - WorldMaker 3y ago
        Typescript is completely open source (Apache 2.0 licensed) and all of its roadmap, planning, issue tracking, peer reviewing, is also out in the open (in GitHub Issues). It's about as "controlled" by Microsoft as Linux is "controlled" by Red Hat at this point.
        planede 3y ago
        OK, but the point of comparison was Dart/Flutter, which I suppose is similarly open. Open source does not mean that it's not controlled by a single person or organization. It's not meant as a critique though, as the alternative I guess is a language designed by committee, which has its own problems.
Dudester230602 3y ago
[flagged]
- tpmx 3y ago
  Crockford is not Eich.
  - Dudester230602 3y ago
    I stand corrected! Still, good to see he realized the error of his ways and the damage caused.
- krisoft 3y ago
  > The new COBOL is here to stay. Very much. :) We have a javascript interpreter parked at the L2 Lagrange point.[1] As far as the preservation of human made artefacts go that is basically one of the safest places it can be. When us and all of our earthly possessions have long crumbled to dust that thing is still going to be out there. (Albeit very likely drifting without power around the sun.) 1: Event-driven James Webb Space Telescope Operations - https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747 https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747
  - Dudester230602 3y ago
    Yeah, the disaster is borderline interplanetory. It will spread to Mars and Moon soon enough.
calrain 3y ago
What is one of those 'really clean' languages that we should be using then? I'm interested!
- thunderbong 3y ago
  Compared to other languages, IMHO Ruby (Not Rails), checks the boxes.
- Brometheus 3y ago
  Smalltalk
- yakshaving_jgt 3y ago
  Elm is an excellent choice.
- consilient 3y ago
  Purescript. By far the best type system of any frontend language, good interop, type-directed emit (so that you can, for instance, automatically generate parsers from type definitions), and unlike Elm actually treats users like adults.
nixpulvis 3y ago
Strip down the browser APIs and make the web more user friendly and deterministic again while your at it. The History API, for example, should never have been implemented.
CodeCompost 3y ago
While we're at it, we should stop using VHS.
nerdypirate 3y ago
> "Notably, none of these are walls you’ll hit if you’re writing a blog or e-commerce site, which is why JavaScript isn’t going away." Pretty much sums up everything :(
throwawaylala1 3y ago
Any time something is adopted as broadly as JavaScript it's going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin' mess. Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place! Or would it? We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!
cunningfatalist 3y ago
He's got a point. TypeScript alleviates some pain, but I still feel like JS is not a great language. I have some nostalgic love for it because I used to be "the JavaScript guy" at the beginning of my career. But ever since I started using TS and Go, using Vanilla JS feels like fighting code smells and complexity all the time. At the same time, I acknowledge and appreciate how much JS has improved.
conceptme 3y ago
> But as increasingly complex software targets the browser, developers are wrangling codebases where UI is not the dominant source of complexity, like CAD tools and scientific data visualization. I guess WASM is already taking this place?
applesan 3y ago
I get his point, but it may be too late for it as some applications even have backends in js.. However I agree that it is somewhat problematic that instead of creating new languages, we create frameworks (sometimes frameworks based on other frameworks like nextjs). Especially considering how messy js can be.
tmikaeld 3y ago
Is he talking about the old < ES5 javascript or the new ES6+ with WebAPI standards? Because to me, it's quite remarkable how JavaScript has evolved since < ES5. ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. It's way more developer friendly when writing new stuff than it used to be. Not to mention, the integration with Web APIs has been a game changer. Fetch API, WebSockets, Web Storage, WebRTC and Service Workers, WebAssembly really enables a lot of functionality that's all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb for avoiding unexpected mutations and a lot easier re-factoring. Also, what do he suggest would be the replacement? Because it's not enough to replace the scripting language, it would need to fit into the DOM, HTML and CSS too.
- yakshaving_jgt 3y ago
  > ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.
  - horsawlarway 3y ago
    > All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded context) It has the same warts that literally every production language accumulates: some operators are overloaded in ways that make for wacky edge-cases, some features were introduced by not great, and so they still exist but mostly gather dust. JS also has some really incredible work put into it - --- > ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. --- Frankly - I understand that increasing language complexity is sometimes not the right call - but I think the vast majority of the features you just poo-pooed are pretty damn nice. I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up (otherwise - I sort of mind the classes, at least when not using TS). What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime - that's not something all that many enterprise languages can attest to, and it's that same flexibility and simple extensivity that has allowed JS to continue to grow. Following on: JS (and browsers in general) are actually one of the absolute wins for software freedom (free as in freedom, not as in beer) because absolutely everything is shipped to you in inspectable and modifiable payloads. I can and have edited JS/html/css to make broken sites work. My single biggest complaint about WASM is that we lose this property for websites, and I think that's a pretty huge fucking loss.
extheat 3y ago
I am skeptical about the performance part (object lifecycle management being a subset of that), whether this is a serious issue causing bottlenecks in modern (not over engineered) production software. It seems to me that subset of software that needs the performance (like hashing, large binary data processing, geometric processing, etc) are things that should be offloaded to GPU for real performance or if it has to be done on the CPU, be run under optimized WebAssembly with no dynamic memory allocations. Since JavaScript has a very good packaging ecosystem compared to other languages, often you don't even have to go out of your way to do that. Someone else has probably done it, and it may just be a require("xxhash") away. I think it's quite backward thinking actually to bend the language making it more complex for the human for the benefit of the compiler. Especially with the shift to LLMs, programming languages should be closer to natural language and expression, not vice versa. The good JS packaging ecosystem takes care of the small standard library issue, but I definitely agree there's room for expansion there. This seems like a surmountable problem. And by standard lib I'm not talking about things that can be trivially be implemented with Array/Object/Map (like queues or ordered maps), I mean things like RNG, math functions, or things like the recently added `fetch` method for HTTP calls.
weinzierl 3y ago
As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly. A bit related: I still do not really understand why WASM has no direct DOM access. Answers to this question seem to fall into two categories: - We don't need it, because you can do everything via a Javascript detour easily - We don't want it for reason X To me both feel a bit like excuses. I've yet to see a hard technical reason why it is not done. So, why not make WASM a first class citizen and do away with Javascript for good?
- K0nserv 3y ago
  My understanding is that the main limitation is technical. WASM doens't do GC or the host system calling conventions and cannot interact directly with object from Javascript because of this. However, this is being worked[0] on and will be solved eventually. Even without this, the performance overhead of bridging to JS is low enough that WASM frameworks can beat out React. 0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
  - davexunit 3y ago
    In addition to GC, the stringref extension is another crucial one for enabling easy interop with JS. Fingers crossed that both make it past the finish line. GC seems pretty much certain, but not sure about stringref.
- echeese 3y ago
  Because DOM access would have bloated the MVP, and you _can_ access the DOM through JS.
- bartimus 3y ago
  I would imagine it a security risk to allow attackers accessing the DOM through WASM. Adding complexity to the sandbox environment.
sspiff 3y ago
> It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares. I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend / system software development. It's just that noone has been able to replicate that kind of success in the web-based frontend space. This happened in the case of Rust and Go after LOTS of searching for better alternatives to C/C++ and later Java. There are a lot of failed attempts along the way, and some which find their niche but fail to displace the older generation languages in any meaningful way. There has been TypeScript and Dart and transpilers that have tried to shield us from the horrors of JavaScript development, but in the end they still are too closely related to JavaScript and its runtime to truly displace it. I feel like we have an opportunity now, with WebAssembly, to move beyond these limitations. If browsers and web standards move to a point where we can use WebAssembly as a first class citizen, without the need for JavaScript scaffolding, we could see the rise of a new crop of languages for the frontend. Perhaps even making it possible to remove JavaScript entirely and move it into a WebAssembly module eventually, to remove it as the default choice and put it on equal footing with new alternatives. We could take the lessons we have learned from other modern languages, and apply them more natively to frontend problems and practices, with language-native tooling and a higher level of integration in those tools than we have been able to achieve with JavaScript.
- hombre_fatal 3y ago
  > It's just that noone has been able to replicate that kind of success [of Rust's and Go's achievements] in the web-based frontend space. While it's easy to dog on Javascript, it's also necessary to consider what Javascript does right. The main thing that comes to mind is JS' async-everything, async-by-default, and first class async abstractions (like the Promise). Not necessarily something you want all the time, but certainly a powerful feature when it comes to IO-bound tasks and UI development. We don't give enough credit to JS for this imo since we take it for granted. But consider something like this (JS) using WaitGroups in Go: const aPromise = promise() const [b, c] = await Promise.all([promise(), promise()]) const a = await aPromise
ramblerman 3y ago
Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now. While people like John Resig were innovating (jquery) working with the language and around all kinds of language quirks 15 years ago, Crockford wrote his book "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else. Then he made the mess that was YUI at yahoo with the same enterprise patterns. When that failed he went right back to these types of doomsday messages in the media every few years calling for the end of Javascript. Meanwhile we have seen ES6/typescript/react and countless other innovation take place. He might be right on some fronts, but at some point its a case of put up or shut up imo. There are far better experts to talk to about the state of JS and its future.
- politelemon 3y ago
  > Meanwhile we have seen ES6/typescript/react and countless other innovation take place. I don't see these as innovations but workarounds to, or built upon, the poor foundations that the author mentions. They wouldn't need to exist if the foundations were solid, or at least not in the states they are in today
  - deleted 3y ago
    [deleted]
  - hombre_fatal 3y ago
    On the other hand, all the tools built on top of Javascript could just as easily be explained by solid foundations that are easily to target with higher levels of abstraction rather than symptoms of the foundation being rotten. It makes more sense to ask "compared to what?" and look at what's going on in the lateral client application platform space. On iOS, it's very hard to target the foundation with higher level competing abstractions not because the foundation nails it but because the foundation isn't built on simple primitives that area easy to target. You have one blessed way of building iOS apps (UIKit) that's then, over the period of a decade+, slowly replaced by the next blessed way to build iOS apps (SwiftUI). And you generally have to wait for Apple to build APIs that you need because you're not given solid building blocks to do things yourself. Most discussion around web client development takes place in a vacuum where we look at it and go "well it could be better" (or "it's a dumpster fire"). But that's either a trivial or meaningless statement in isolation. It's more interesting to at least compare the state of web clients with what is the cutting edge state of the art across all client development. When you do that, I don't see how most HN claims about the dire state of JS actually hold up.
debacle 3y ago
JavaScript is fine, the real problem is HTML/CSS and the DOM. We were so, so close to a semantic, reader-based web ~20 years ago. The ad supported Internet killed it. Now that the ad supported Internet is dying, maybe we can get back to it.
- cies 3y ago
  > JavaScript is fine What languages to you have experience with? The article mentions some alternatives, like Elm, and I'd be hard pressed that people who used those (say Elm) effectively still believe JS is fine.
  - debacle 3y ago
    You're too old to be a language elitist.
  - leetharris 3y ago
    Not the OP you replied to, but I've worked in about a dozen languages in 15+ years and I also think Javascript is fine. It will never be #1, but it does a good job for the things it is good at. The fact that you mentioned Elm is funny to me as it is so low ranked in terms of usage or desire that it doesn't even show on StackOverflow's survey results.
    - ttfkam 3y ago
      Exactly! Perfect is the enemy of good.
    - cies 3y ago
      Truth is not measured in mass appeal --- Immortal Technique
- samwillis 3y ago
  No it's not, and we do have semantic web accessible to screen readers. It is just also this incredible universal platform for building and distributing applications. It's a universal layer accessible to all, no mater your socioeconomic background, politics or location. Criticising the web platform as not confirming to a set of self defined rules is lazy and pointless.
koriolan 3y ago
The problem is not just a language problem. The problem is the repurpose of the web as an "operating system". HTML and CSS are OK for document layout and styling, and JS is OK for simple interactions. BUT none of these were designed to handle highly complex and dynamic applications. We are just building on the wrong foundation, hacking to extremes to twist the the framework to the current trend. We are using the wrong tools for the job.
ajani 3y ago
I wish! I wish!! I so wish this would happen. And the ‘type’ attribute to the script tag would finally mean something! But nope. It won’t be. Just as var remains to support old webpages. Use strict to support newer features without affecting old ones. Imports. Etc. But the post is factually off. In fact there is now an ordered map in JS. I think whoever is responsible for the spec and the implementations need to be complimented. Its actually shocking that it works so well. I have written painting software (much more computationally expensive than CAD software) using Canvas and WebGL apis and it’s pretty darn performant. Never native. But still very very good. Although I don’t know about the vitriol in the comments toward old crocky. And his good parts book was good and useful to me in parts.
nologic01 3y ago
He is obviously right about the stagnation but he does not seem to be connecting the dots (at least in this video) about why this is so - which in turn might inform us as to when to except some change. Languages and their tooling ecosystems express how computing is concretely embedded and used by society. People adopt the tools to get jobs and to get the job done, whatever the "job" is. In turn the available remunerative jobs fit certain business models and markets. The ecological landscape that prevails today is largely monocultures centered around the distortion fields of a few oligopoly entities. But not exlcusively so. You still have all sort of remnants of previous era landscape, the enterprise world stuck in its java coffin, the quirky projects of the Web 1.0 era still trusting php etc. Massive adoption of a fresh and "clean" new thing will only happen with the emergence of a new economic reality, expressed for example through new actors. New tools that make desirable new things possible may enable such an evolution and eventually may be synomymous with it but these things don't happen made to order.
- user3939382 3y ago
  > quirky projects of the Web 1.0 era still trusting php Disagree with the dig at PHP. PhpStorm+Psalm doesn't give you perfection, but a perfectly respectable development environment. Using PHP isn't anachronistic, these shallow dismissals are. If anyone out there hasn't seen PHP 8 and Psalm yet, it's worth a look. All languages and ecosystems have trade offs, PHP is no exception, it is a good fit for many scenarios.
  - nologic01 3y ago
    Sorry, I didn't mean to sound dismissive (much less shallow!) about php. In fact I have great admiration for projects from wikipedia, to wordpress, moodle, matomo, you name it, before even talking about the modern php landscape you mention. In my book what you achieve is far more important than how you achieve it. Crockford is arguing about "clean starts" and that is fine but the thrust of my comment that this will be driven by business models, not so much by tools. Sometimes tools are enablers of new things, so there is a chicken-and-egg aspect to it. So we have all these ecosystems that were once flourishing but are now in a stationary state because the business models are in stationary state. There is a variety of tools that are good enough to get the current "job" done, but its not clear what will bring us to the next phase...
labrador 3y ago
We had this argument in 2012-13 when Google Dart came out. I advocated for a Dart VM in the browser but the Blink team killed that idea. Brenden Eich explained here on HN what the problems were and made good sense. Now there would seem to be even less reason by using JS as a target language and by using WASM. JS devs have other options, but they still choose JS or TypeScript. Crockford sounds like an old man yelling at clouds (I'm older than him, so not ageism)
sergiotapia 3y ago
As a culture, we are stuck. This article illustrates this well: https://lindynewsletter.beehiiv.com/p/culture-stuck https://lindynewsletter.beehiiv.com/p/culture-stuck This language refusing to fade away like other ancient languages is just a symptom of the root cause. Myself, I use Elixir as my primary language.
deleted 3y ago
[deleted]
Devasta 3y ago
Software quality has never mattered in web development. When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors. JS is installed on every machine, you don't need to deal with IT bureaucracy getting apps installed or heaven forbid ports opened, and it'll never ever have anything less than the full backing of the browser developers. Even Brainfuck would be the dominant language with that feature set. So long as that remains the case, as it will in my lifetime, nothing will change.
- perilunar 3y ago
  > When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors At the time a lot of the people generating content for the web were not web developers, so HTML had to be forgiving. Most CMSes allow people to add arbitrary markup — it is far preferable for the browsers to be forgiving than to refuse to show pages if there is a syntax error.
wturner 3y ago
He is promoting an "actor language" to replace JavaScript. https://www.crockford.com/misty/ https://www.crockford.com/misty/
- ttfkam 3y ago
  And it's not clear it would be worth the retooling/training on the UI-side of things. The actor model is great for massive concurrency, which simply isn't a primary or even a secondary concern for 99.9% of client-side code. There's a reason why Go has such a huge following in the server space but a deafening silence of folks wanted it available in browser UI code.
baerrie 3y ago
Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.
- deleted 3y ago
  [deleted]
- preordained 3y ago
  By this logic, the Imperial System is the best measurement system for the US (pick whatever entrenched system you want). Whether you agree or disagree with it, it's the most widely used in US so its superiority there is self-evident.
  - jononomo 3y ago
    I agree that the Imperial System is superior to the Metric System just from the point of view of human usability.
  - baerrie 3y ago
    You are free to pick up the better system in your opinion but if you want interoperability and consistency with other US measurers then you may have issues.
jononomo 3y ago
He says that a new language used to pop up every generation -- and that seems to me like it's been the case -- Elixir, Rust, and Go all seem to have arisen during the last 15 years.
commandlinefan 3y ago
> we’d get new computer languages about every generation. > accumulated complexity we’ve piled on top of bad foundations OTOH when we get new computer languages, they usually start really simple as a sort of protest against the "old" complexity and then spend the next few decades shoehorning back in all the things they left out to keep it simple but that it turns out we actually needed.
omgomgomgomg 3y ago
Can someone summarize crockfords opinion on the current state of the browser js api? And his opinion on reactjs
dolmen 3y ago
Listen also to Crockford's interview on the Corecursive podcast: https://corecursive.com/json-vs-xml-douglas-crockford/ https://corecursive.com/json-vs-xml-douglas-crockford/
aristofun 3y ago
How can you take seriously a guy who didn’t allow comments in JSON? As smart as he is - he obviously doesn’t give a single f* about real life problems and challenges of real life programmers.
culebron21 3y ago
I remember Crockford's lectures at Yahoo in 2009, and they were inspiring, but in the hindsight, most his bold points turned out incorrect. #1: The promise of high speed with event loop & JIT compiler. Crockford's idea was that if you make small functions that return quickly, JIT will boost their speed drammatically. Plus, fast yielding would make programs seem faster for the client. By then, Google Chrome wrote impressively fast JS engine, but later the speed of JS didn't improve much. JIT-based languages and engines didn't match performance -- I myself tried Pypy, and it wasn't fast like C. I must give him credit that his lectures made me finally get how the event loop works. #2: That Promises and async would make async programming much easier. Promises do make code better than callback hell, but still are tedious. The side costs of async are well summarized in this post & presentation: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... #3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either. #4: Decentralized web evangelism in mid-'10s. This is a bittorrent concept extrapolated to web hosting, later it got traction branded as Web3. It's clear by torrents that they work only when everyone cooperates, and carries some serious load, otherwise torrents die out. The decentralized web requires every user to host a good bit of data, and any document published puts this load on everyone in the system. As with Ted Nelson's concept, it makes sense only in small environment of cooperating users. That being said, Crockford's lectures were interesting for history part, and he made a good point that one should looki into history and see what is logical and progressive, what we got just accidentally and it stays as legacy.
- DanielHB 3y ago
  > #3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either. yeah I have been struggling with this for a while, at my project we use typescript and non stateful objects we just use plain objects, no classes. However we started using classes for stateful code, I was opposed to the idea and thought that using closure-based state would be better but I ended up losing that battle A lot of those classes are single-instance in the application, which feels even more of an anti-pattern to be classes To be clear I am not advocating for closure-based state, but classes also feel awkward. It feels we should just have bit the bullet and used some kind of state-management library

165 points by lrsjng 3y ago

> "[...] we are crushing ourselves with the accumulated complexity we’ve piled on top of bad foundations [...]" The same could be said about plain HTML/CSS though. I think the author is correct overall and I don't really see improvement on the horizon. WebAssembly, while great that it exists, can morph browsers into some poor mans virtual operating system and this can lead to a less open web. We already see more closed Platforms like Discord. I use it too, the product is completely fine, but it sucks in information that isn't availble on the open net if you don't go through the platform. Some communities exclusively use it and they get little discoverability through web searches. Sure, this isn't really related to Javascript/Webassembly, just a development I fear will increase and which could be accelerated with different approaches to languages. A front-end scripting language available in every browser is very, very useful. I think few new languages could replace it here, I don't know of any at least. And I think a lot of flexibility is lost if you begin to transpile anthing into Javascript. Granted, for large projects it is pretty much a requirement to do so at some point.

smole 3y ago
Worse than trying to replace it entirely is that you just end up with two implementations that need to be maintained.
chii 3y ago
> [closed platforms] will increase and which could be accelerated with different approaches to languages. the business incentive is towards such closed platforms - data and platform ownership has value after all. It makes zero sense for a business to keep a platform open and potentially help a competitor.
- raxxorraxor 3y ago
  I disagree, it would be in their interest to somehow gap that border in the long run, although I wouldn't know an easy way to achieve this. Its users often tend to not understand the repercussions in my opinion and that is true even for software developers. Sure, an exchange on Discord is easy and personal, you get ample support from your supporters and that can really propel projects to the next level. But as I said, all the knowledge from these exchanges is lost for the net. The user that comes 2 years later won't see these exchanges and not even you product in some cases. I would always suggest to also use some kind of forum or knowledge base. Discord has APIs to make such content discoverable as well in theory. I use the platform too, it shouldn't be seen as an indictment for the Discord developers at all. On the contrary they offer an extremely useful service and in most cases completely for free and it shows that they care for the platform. But just as things are, we have it as something separate to the usual web and I believe that some communities suffer if they do not provide alternative venues.
diego_sandoval 3y ago
> The same could be said about plain HTML/CSS though. Genuine question: How much of the complexity of working with HTML/CSS is unnecessary and how much is inherent to the problem they solve? Is it as bad as with Javascript? I would say that we, for the most part, have a very clear idea of how we could (theoretically) replace Javascript with something much better. I don't know of alternative layout languages, so I don't know how good CSS is in comparison. And what could we replace HTML with? My general appreciation, from my ignorance, is that they are not that bad.
- Latty 3y ago
  Seriously, every time people complain about CSS and HTML I think about how much work it is to support all the localisation and layout stuff they do. Managing massively different sized screens as elegantly as them is hard and yeah, it's still not that elegant or easy, but I haven't used anything better that didn't sacrifice something for it.
  - geektips 3y ago
    Absolutely, I totally agree. Layout development has gotten a lot better with Flexbox, Grid, and the new Container Queries.
  - SenHeng 3y ago
    Every time I have to build a UI in canvas, I yearn for all the conveniences CSS and the DOM provide. Do people even realise how much trouble it is to make text wrap within a given space?
    - Solvency 3y ago
      It is, but yet thousands of videogames have been doing this for decades...
      - SenHeng 3y ago
        And most games will use an engine like Unity or Unreal so they don't have to re-invent the wheel. HTML and CSS may not be perfect, but they've been battle tested for a good 30 years and have had improvements added. No need to re-invent that wheel.
stavros 3y ago
Discoverability for communities is a really good point. I wonder if any chat software exists that allows easy/good indexing by search engines.
yxre 3y ago
Nobody will ever agree on an alternative. And, none of the attempted alternatives have ever taken off because the velocity of javascript's incrementalism is far greater than the velocity of any new shiny thing. JS has the weight of the largest corporations in the world behind it that don't want to lose their investments

revskill 3y ago

Most of boilerplate code i wrote is mapping data structures between API standards. None of the is related to javascript. So i won't stop using javascript.

andix 3y ago

First we need a good alternative. JavaScript may not be the best, but it works well.

yxre 3y ago
He has been saying this for a decade. I had to double check the dates to see if it was even relevant. A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. Performance with V8. Object lifecycle management has had improvements from ES6 WeakMap and WeakRef although JS will never have RAII. ES6 also added more data structures. No new alternative will be able to keep up with javascript's incrementalism
- svieira 3y ago
  I'm not _entirely_ sure which RAII you mean, but if you mean something like C#'s `using` or Java's `try-with-resources` or Python's `with`, then https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen... and https://github.com/tc39/proposal-async-explicit-resource-management https://github.com/tc39/proposal-async-explicit-resource-man... are in stage 3 (of 4 stages) in ECMAScript's language proposal lifecycle and will be coming to a JS engine near you behind a flag soon-ish.
- paulgb 3y ago
  > A problem is that the 3 problems that the articles highlights have been fixed with incremental fixes. (author here) - I disagree. If V8 solved performance, we wouldn't see so much of the JS tooling stack being rewritten in Rust. Modern JS runtimes are fast because they are tuned for the types of workloads that are common on the web. This is great for the performance of a virtual DOM, but if you go off the beaten path of workloads that the browser is used to, you're still limited by the performance of the runtime. JS has improved for sure but it’s always going to be slower than a language with a BDFL because it has so much legacy baggage and political consensus-building required. IMHO WebAssembly is the right approach: standardize a minimal bytecode and let languages compete on innovation.

glutamate 3y ago

Ok show me another language which has near native performance, gradual typing (thinking TypeScript here), and lets me do lightweight functional and lightweight OO programming.

quaintdev 3y ago
How about Dart/Flutter?
- glutamate 3y ago
  I forgot to add "not controlled by a single corporation" to my list of requirements. Also not gradually typed, I think? But I would consider it if it weren't all tied into Google and had a larger ecosystem.
  - planede 3y ago
    Isn't Typescript "controlled" by Microsoft?
    - glutamate 3y ago
      This is a good point, yes you are right about that.
    - WorldMaker 3y ago
      Typescript is completely open source (Apache 2.0 licensed) and all of its roadmap, planning, issue tracking, peer reviewing, is also out in the open (in GitHub Issues). It's about as "controlled" by Microsoft as Linux is "controlled" by Red Hat at this point.
      - planede 3y ago
        OK, but the point of comparison was Dart/Flutter, which I suppose is similarly open. Open source does not mean that it's not controlled by a single person or organization. It's not meant as a critique though, as the alternative I guess is a language designed by committee, which has its own problems.

Dudester230602 3y ago

[flagged]

tpmx 3y ago
Crockford is not Eich.
- Dudester230602 3y ago
  I stand corrected! Still, good to see he realized the error of his ways and the damage caused.
krisoft 3y ago
> The new COBOL is here to stay. Very much. :) We have a javascript interpreter parked at the L2 Lagrange point.[1] As far as the preservation of human made artefacts go that is basically one of the safest places it can be. When us and all of our earthly possessions have long crumbled to dust that thing is still going to be out there. (Albeit very likely drifting without power around the sun.) 1: Event-driven James Webb Space Telescope Operations - https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747 https://arc.aiaa.org/doi/pdf/10.2514/6.2006-5747
- Dudester230602 3y ago
  Yeah, the disaster is borderline interplanetory. It will spread to Mars and Moon soon enough.

calrain 3y ago

What is one of those 'really clean' languages that we should be using then? I'm interested!

thunderbong 3y ago
Compared to other languages, IMHO Ruby (Not Rails), checks the boxes.
Brometheus 3y ago
Smalltalk
yakshaving_jgt 3y ago
Elm is an excellent choice.
consilient 3y ago
Purescript. By far the best type system of any frontend language, good interop, type-directed emit (so that you can, for instance, automatically generate parsers from type definitions), and unlike Elm actually treats users like adults.

nixpulvis 3y ago

Strip down the browser APIs and make the web more user friendly and deterministic again while your at it. The History API, for example, should never have been implemented.

CodeCompost 3y ago

While we're at it, we should stop using VHS.

nerdypirate 3y ago

> "Notably, none of these are walls you’ll hit if you’re writing a blog or e-commerce site, which is why JavaScript isn’t going away." Pretty much sums up everything :(

throwawaylala1 3y ago

Any time something is adopted as broadly as JavaScript it's going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin' mess. Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place! Or would it? We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!

cunningfatalist 3y ago

He's got a point. TypeScript alleviates some pain, but I still feel like JS is not a great language. I have some nostalgic love for it because I used to be "the JavaScript guy" at the beginning of my career. But ever since I started using TS and Go, using Vanilla JS feels like fighting code smells and complexity all the time. At the same time, I acknowledge and appreciate how much JS has improved.

conceptme 3y ago

> But as increasingly complex software targets the browser, developers are wrangling codebases where UI is not the dominant source of complexity, like CAD tools and scientific data visualization. I guess WASM is already taking this place?

applesan 3y ago

I get his point, but it may be too late for it as some applications even have backends in js.. However I agree that it is somewhat problematic that instead of creating new languages, we create frameworks (sometimes frameworks based on other frameworks like nextjs). Especially considering how messy js can be.

tmikaeld 3y ago

Is he talking about the old < ES5 javascript or the new ES6+ with WebAPI standards? Because to me, it's quite remarkable how JavaScript has evolved since < ES5. ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. It's way more developer friendly when writing new stuff than it used to be. Not to mention, the integration with Web APIs has been a game changer. Fetch API, WebSockets, Web Storage, WebRTC and Service Workers, WebAssembly really enables a lot of functionality that's all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb for avoiding unexpected mutations and a lot easier re-factoring. Also, what do he suggest would be the replacement? Because it's not enough to replace the scripting language, it would need to fit into the DOM, HTML and CSS too.

yakshaving_jgt 3y ago
> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.
- horsawlarway 3y ago
  > All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded context) It has the same warts that literally every production language accumulates: some operators are overloaded in ways that make for wacky edge-cases, some features were introduced by not great, and so they still exist but mostly gather dust. JS also has some really incredible work put into it - --- > ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. --- Frankly - I understand that increasing language complexity is sometimes not the right call - but I think the vast majority of the features you just poo-pooed are pretty damn nice. I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up (otherwise - I sort of mind the classes, at least when not using TS). What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime - that's not something all that many enterprise languages can attest to, and it's that same flexibility and simple extensivity that has allowed JS to continue to grow. Following on: JS (and browsers in general) are actually one of the absolute wins for software freedom (free as in freedom, not as in beer) because absolutely everything is shipped to you in inspectable and modifiable payloads. I can and have edited JS/html/css to make broken sites work. My single biggest complaint about WASM is that we lose this property for websites, and I think that's a pretty huge fucking loss.

extheat 3y ago

I am skeptical about the performance part (object lifecycle management being a subset of that), whether this is a serious issue causing bottlenecks in modern (not over engineered) production software. It seems to me that subset of software that needs the performance (like hashing, large binary data processing, geometric processing, etc) are things that should be offloaded to GPU for real performance or if it has to be done on the CPU, be run under optimized WebAssembly with no dynamic memory allocations. Since JavaScript has a very good packaging ecosystem compared to other languages, often you don't even have to go out of your way to do that. Someone else has probably done it, and it may just be a require("xxhash") away. I think it's quite backward thinking actually to bend the language making it more complex for the human for the benefit of the compiler. Especially with the shift to LLMs, programming languages should be closer to natural language and expression, not vice versa. The good JS packaging ecosystem takes care of the small standard library issue, but I definitely agree there's room for expansion there. This seems like a surmountable problem. And by standard lib I'm not talking about things that can be trivially be implemented with Array/Object/Map (like queues or ordered maps), I mean things like RNG, math functions, or things like the recently added `fetch` method for HTTP calls.

weinzierl 3y ago

As we nowadays compile TS to JS anyways, it would be a small step to go full WASM and have language agnosticism mostly. A bit related: I still do not really understand why WASM has no direct DOM access. Answers to this question seem to fall into two categories: - We don't need it, because you can do everything via a Javascript detour easily - We don't want it for reason X To me both feel a bit like excuses. I've yet to see a hard technical reason why it is not done. So, why not make WASM a first class citizen and do away with Javascript for good?

K0nserv 3y ago
My understanding is that the main limitation is technical. WASM doens't do GC or the host system calling conventions and cannot interact directly with object from Javascript because of this. However, this is being worked[0] on and will be solved eventually. Even without this, the performance overhead of bridging to JS is low enough that WASM frameworks can beat out React. 0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
- davexunit 3y ago
  In addition to GC, the stringref extension is another crucial one for enabling easy interop with JS. Fingers crossed that both make it past the finish line. GC seems pretty much certain, but not sure about stringref.
echeese 3y ago
Because DOM access would have bloated the MVP, and you _can_ access the DOM through JS.
bartimus 3y ago
I would imagine it a security risk to allow attackers accessing the DOM through WASM. Adding complexity to the sandbox environment.

sspiff 3y ago

> It used to be that we’d get new computer languages about every generation. […] And then it kind of stopped. There are still people developing languages, but nobody cares. I think this is false. We can see great interest in new languages, and I feel like languages like Rust and Go have achieved to move the ball forward significantly for backend / system software development. It's just that noone has been able to replicate that kind of success in the web-based frontend space. This happened in the case of Rust and Go after LOTS of searching for better alternatives to C/C++ and later Java. There are a lot of failed attempts along the way, and some which find their niche but fail to displace the older generation languages in any meaningful way. There has been TypeScript and Dart and transpilers that have tried to shield us from the horrors of JavaScript development, but in the end they still are too closely related to JavaScript and its runtime to truly displace it. I feel like we have an opportunity now, with WebAssembly, to move beyond these limitations. If browsers and web standards move to a point where we can use WebAssembly as a first class citizen, without the need for JavaScript scaffolding, we could see the rise of a new crop of languages for the frontend. Perhaps even making it possible to remove JavaScript entirely and move it into a WebAssembly module eventually, to remove it as the default choice and put it on equal footing with new alternatives. We could take the lessons we have learned from other modern languages, and apply them more natively to frontend problems and practices, with language-native tooling and a higher level of integration in those tools than we have been able to achieve with JavaScript.

hombre_fatal 3y ago
> It's just that noone has been able to replicate that kind of success [of Rust's and Go's achievements] in the web-based frontend space. While it's easy to dog on Javascript, it's also necessary to consider what Javascript does right. The main thing that comes to mind is JS' async-everything, async-by-default, and first class async abstractions (like the Promise). Not necessarily something you want all the time, but certainly a powerful feature when it comes to IO-bound tasks and UI development. We don't give enough credit to JS for this imo since we take it for granted. But consider something like this (JS) using WaitGroups in Go: const aPromise = promise() const [b, c] = await Promise.all([promise(), promise()]) const a = await aPromise

ramblerman 3y ago

Trying not to make this an ad-hominim attack, but Crockford has been a net negative to JS for 20 years now. While people like John Resig were innovating (jquery) working with the language and around all kinds of language quirks 15 years ago, Crockford wrote his book "The good parts" that tried to write java in javascript. And probably did more to make people write bad JS code than anything else. Then he made the mess that was YUI at yahoo with the same enterprise patterns. When that failed he went right back to these types of doomsday messages in the media every few years calling for the end of Javascript. Meanwhile we have seen ES6/typescript/react and countless other innovation take place. He might be right on some fronts, but at some point its a case of put up or shut up imo. There are far better experts to talk to about the state of JS and its future.

politelemon 3y ago
> Meanwhile we have seen ES6/typescript/react and countless other innovation take place. I don't see these as innovations but workarounds to, or built upon, the poor foundations that the author mentions. They wouldn't need to exist if the foundations were solid, or at least not in the states they are in today
- deleted 3y ago
  [deleted]
- hombre_fatal 3y ago
  On the other hand, all the tools built on top of Javascript could just as easily be explained by solid foundations that are easily to target with higher levels of abstraction rather than symptoms of the foundation being rotten. It makes more sense to ask "compared to what?" and look at what's going on in the lateral client application platform space. On iOS, it's very hard to target the foundation with higher level competing abstractions not because the foundation nails it but because the foundation isn't built on simple primitives that area easy to target. You have one blessed way of building iOS apps (UIKit) that's then, over the period of a decade+, slowly replaced by the next blessed way to build iOS apps (SwiftUI). And you generally have to wait for Apple to build APIs that you need because you're not given solid building blocks to do things yourself. Most discussion around web client development takes place in a vacuum where we look at it and go "well it could be better" (or "it's a dumpster fire"). But that's either a trivial or meaningless statement in isolation. It's more interesting to at least compare the state of web clients with what is the cutting edge state of the art across all client development. When you do that, I don't see how most HN claims about the dire state of JS actually hold up.

debacle 3y ago

JavaScript is fine, the real problem is HTML/CSS and the DOM. We were so, so close to a semantic, reader-based web ~20 years ago. The ad supported Internet killed it. Now that the ad supported Internet is dying, maybe we can get back to it.

cies 3y ago
> JavaScript is fine What languages to you have experience with? The article mentions some alternatives, like Elm, and I'd be hard pressed that people who used those (say Elm) effectively still believe JS is fine.
- debacle 3y ago
  You're too old to be a language elitist.
- leetharris 3y ago
  Not the OP you replied to, but I've worked in about a dozen languages in 15+ years and I also think Javascript is fine. It will never be #1, but it does a good job for the things it is good at. The fact that you mentioned Elm is funny to me as it is so low ranked in terms of usage or desire that it doesn't even show on StackOverflow's survey results.
  - ttfkam 3y ago
    Exactly! Perfect is the enemy of good.
  - cies 3y ago
    Truth is not measured in mass appeal --- Immortal Technique
samwillis 3y ago
No it's not, and we do have semantic web accessible to screen readers. It is just also this incredible universal platform for building and distributing applications. It's a universal layer accessible to all, no mater your socioeconomic background, politics or location. Criticising the web platform as not confirming to a set of self defined rules is lazy and pointless.

koriolan 3y ago

The problem is not just a language problem. The problem is the repurpose of the web as an "operating system". HTML and CSS are OK for document layout and styling, and JS is OK for simple interactions. BUT none of these were designed to handle highly complex and dynamic applications. We are just building on the wrong foundation, hacking to extremes to twist the the framework to the current trend. We are using the wrong tools for the job.

ajani 3y ago

I wish! I wish!! I so wish this would happen. And the ‘type’ attribute to the script tag would finally mean something! But nope. It won’t be. Just as var remains to support old webpages. Use strict to support newer features without affecting old ones. Imports. Etc. But the post is factually off. In fact there is now an ordered map in JS. I think whoever is responsible for the spec and the implementations need to be complimented. Its actually shocking that it works so well. I have written painting software (much more computationally expensive than CAD software) using Canvas and WebGL apis and it’s pretty darn performant. Never native. But still very very good. Although I don’t know about the vitriol in the comments toward old crocky. And his good parts book was good and useful to me in parts.

nologic01 3y ago

He is obviously right about the stagnation but he does not seem to be connecting the dots (at least in this video) about why this is so - which in turn might inform us as to when to except some change. Languages and their tooling ecosystems express how computing is concretely embedded and used by society. People adopt the tools to get jobs and to get the job done, whatever the "job" is. In turn the available remunerative jobs fit certain business models and markets. The ecological landscape that prevails today is largely monocultures centered around the distortion fields of a few oligopoly entities. But not exlcusively so. You still have all sort of remnants of previous era landscape, the enterprise world stuck in its java coffin, the quirky projects of the Web 1.0 era still trusting php etc. Massive adoption of a fresh and "clean" new thing will only happen with the emergence of a new economic reality, expressed for example through new actors. New tools that make desirable new things possible may enable such an evolution and eventually may be synomymous with it but these things don't happen made to order.

user3939382 3y ago
> quirky projects of the Web 1.0 era still trusting php Disagree with the dig at PHP. PhpStorm+Psalm doesn't give you perfection, but a perfectly respectable development environment. Using PHP isn't anachronistic, these shallow dismissals are. If anyone out there hasn't seen PHP 8 and Psalm yet, it's worth a look. All languages and ecosystems have trade offs, PHP is no exception, it is a good fit for many scenarios.
- nologic01 3y ago
  Sorry, I didn't mean to sound dismissive (much less shallow!) about php. In fact I have great admiration for projects from wikipedia, to wordpress, moodle, matomo, you name it, before even talking about the modern php landscape you mention. In my book what you achieve is far more important than how you achieve it. Crockford is arguing about "clean starts" and that is fine but the thrust of my comment that this will be driven by business models, not so much by tools. Sometimes tools are enablers of new things, so there is a chicken-and-egg aspect to it. So we have all these ecosystems that were once flourishing but are now in a stationary state because the business models are in stationary state. There is a variety of tools that are good enough to get the current "job" done, but its not clear what will bring us to the next phase...

labrador 3y ago

We had this argument in 2012-13 when Google Dart came out. I advocated for a Dart VM in the browser but the Blink team killed that idea. Brenden Eich explained here on HN what the problems were and made good sense. Now there would seem to be even less reason by using JS as a target language and by using WASM. JS devs have other options, but they still choose JS or TypeScript. Crockford sounds like an old man yelling at clouds (I'm older than him, so not ageism)

sergiotapia 3y ago

As a culture, we are stuck. This article illustrates this well: https://lindynewsletter.beehiiv.com/p/culture-stuck https://lindynewsletter.beehiiv.com/p/culture-stuck This language refusing to fade away like other ancient languages is just a symptom of the root cause. Myself, I use Elixir as my primary language.

deleted 3y ago

[deleted]

Devasta 3y ago

Software quality has never mattered in web development. When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors. JS is installed on every machine, you don't need to deal with IT bureaucracy getting apps installed or heaven forbid ports opened, and it'll never ever have anything less than the full backing of the browser developers. Even Brainfuck would be the dominant language with that feature set. So long as that remains the case, as it will in my lifetime, nothing will change.

perilunar 3y ago
> When the W3C tried to push XHTML web devs balked at the idea that they should understand markup languages and not have syntax errors At the time a lot of the people generating content for the web were not web developers, so HTML had to be forgiving. Most CMSes allow people to add arbitrary markup — it is far preferable for the browsers to be forgiving than to refuse to show pages if there is a syntax error.

wturner 3y ago

He is promoting an "actor language" to replace JavaScript. https://www.crockford.com/misty/ https://www.crockford.com/misty/

ttfkam 3y ago
And it's not clear it would be worth the retooling/training on the UI-side of things. The actor model is great for massive concurrency, which simply isn't a primary or even a secondary concern for 99.9% of client-side code. There's a reason why Go has such a huge following in the server space but a deafening silence of folks wanted it available in browser UI code.

baerrie 3y ago

Languages are validated by their use. All other interpretations of their value are abstractions from the only real metric, that people use it and it is alive in that way. We don’t speak dead languages and we don’t adopt them either.

deleted 3y ago
[deleted]
preordained 3y ago
By this logic, the Imperial System is the best measurement system for the US (pick whatever entrenched system you want). Whether you agree or disagree with it, it's the most widely used in US so its superiority there is self-evident.
- jononomo 3y ago
  I agree that the Imperial System is superior to the Metric System just from the point of view of human usability.
- baerrie 3y ago
  You are free to pick up the better system in your opinion but if you want interoperability and consistency with other US measurers then you may have issues.

jononomo 3y ago

He says that a new language used to pop up every generation -- and that seems to me like it's been the case -- Elixir, Rust, and Go all seem to have arisen during the last 15 years.

commandlinefan 3y ago

> we’d get new computer languages about every generation. > accumulated complexity we’ve piled on top of bad foundations OTOH when we get new computer languages, they usually start really simple as a sort of protest against the "old" complexity and then spend the next few decades shoehorning back in all the things they left out to keep it simple but that it turns out we actually needed.

omgomgomgomg 3y ago

Can someone summarize crockfords opinion on the current state of the browser js api? And his opinion on reactjs

dolmen 3y ago

Listen also to Crockford's interview on the Corecursive podcast: https://corecursive.com/json-vs-xml-douglas-crockford/ https://corecursive.com/json-vs-xml-douglas-crockford/

aristofun 3y ago

How can you take seriously a guy who didn’t allow comments in JSON? As smart as he is - he obviously doesn’t give a single f* about real life problems and challenges of real life programmers.

culebron21 3y ago

I remember Crockford's lectures at Yahoo in 2009, and they were inspiring, but in the hindsight, most his bold points turned out incorrect. #1: The promise of high speed with event loop & JIT compiler. Crockford's idea was that if you make small functions that return quickly, JIT will boost their speed drammatically. Plus, fast yielding would make programs seem faster for the client. By then, Google Chrome wrote impressively fast JS engine, but later the speed of JS didn't improve much. JIT-based languages and engines didn't match performance -- I myself tried Pypy, and it wasn't fast like C. I must give him credit that his lectures made me finally get how the event loop works. #2: That Promises and async would make async programming much easier. Promises do make code better than callback hell, but still are tedious. The side costs of async are well summarized in this post & presentation: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... #3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either. #4: Decentralized web evangelism in mid-'10s. This is a bittorrent concept extrapolated to web hosting, later it got traction branded as Web3. It's clear by torrents that they work only when everyone cooperates, and carries some serious load, otherwise torrents die out. The decentralized web requires every user to host a good bit of data, and any document published puts this load on everyone in the system. As with Ted Nelson's concept, it makes sense only in small environment of cooperating users. That being said, Crockford's lectures were interesting for history part, and he made a good point that one should looki into history and see what is logical and progressive, what we got just accidentally and it stays as legacy.

DanielHB 3y ago
> #3: Object construction with closure function. We tried that wholeheartedly at contemporary project, and it was awkward. I haven't seen any popular framework do this approach either. yeah I have been struggling with this for a while, at my project we use typescript and non stateful objects we just use plain objects, no classes. However we started using classes for stateful code, I was opposed to the idea and thought that using closure-based state would be better but I ended up losing that battle A lot of those classes are single-instance in the application, which feels even more of an anti-pattern to be classes To be clear I am not advocating for closure-based state, but classes also feel awkward. It feels we should just have bit the bullet and used some kind of state-management library