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.
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 aPromiseOr to put it in another way: JavaScript makes the uncommon case easy and the common case hard(er).
Sure, though if this is something you're doing a lot of it's not hard to abstract out.
However, let me put on the other side of the balance the sheer staggering quantity of code there is out there that just "await"s everything in line as if they were writing some version of Go that required you to specify every function that could potentially be async, because Promise.all and friends are quite uncommon.
Before you jump up to protest to the contrary, go run a grep over your code base and count the "await"s that are simply awaiting the next thing in sequence versus doing something less trivial. Even those of you who write this code fluently will probably discover you have a lot of things just getting directly awaited. The exceptions, being rare, are cognitively available; the number of times you almost unthinkingly type "await" don't register because they are so common. Only a few of you doing something fairly unusual will be able to say with a straight face that you are using Promise.whatever abstractions all the time. Even fewer of you will be able to say you use all different kinds and construct your own and couldn't solve the lack of some particular abstraction in Go in just a few minutes of writing some function.
Promises begin to resolve as soon as they are created. Therefore, assuming that the three executions of `promise()` in that code take 3 seconds, 10 seconds and 2 seconds respectively, we should expect `aPromise` to be resolved during `Promise.all([promise(), promise()])` immediately prior to `b` and `c`. The only thing is that we do not unwrap `aPromise` with `await` and point `a` towards it until 10 seconds after `await Promise.all([promise(), promise()])` was called.
Therefore, it's quite possible that the first call to `promise()` might resolve after 3 seconds, while the next two calls could take 7 seconds and 10 seconds respectively. In this case, the `Promise.all` would produce a result after 10 seconds, and then the next line `const a = await aPromise` would unwrap the value within `aPromise` immediately as it would already have been fulfilled 3 seconds into execution of the `await Promise.all([promise(), promise()])` line.
Therefore, it's quite possible that the first call to `promise()` might resolve after 3 seconds, while the next two calls could take 7 seconds and 10 seconds respectively. In this case, the `Promise.all` would produce a result after 10 seconds, and then the next line `const a = await aPromise` would unwrap the value within `aPromise` immediately as it would already have been fulfilled 3 seconds into the `await Promise.all([promise(), promise()])`.
Therefore, it's quite possible that the first call to `promise()` might resolve after 3 seconds, while the next two calls could take 7 seconds and 10 seconds respectively. In this case, the `Promise.all` would produce a result after 10 seconds, and then the next line `const a = await aPromise` would unwrap the value within `aPromise` immediately, since it would already have been fulfilled.
See: how much JS is rightly and justifiably littered with "await" on seemingly almost every line, now that that's an option. It's downright comical to look at, and as clear a sign of mis-design in a language/runtime as you can get. Nine times out of ten (maybe more...) you just need to treat all that async stuff as synchronous, from the perspective of the current block of code. "Await" or something like it should have been the default behavior of async calls. A great deal of the mess in Javascript over the last couple decades has been due to going the other direction with that default.
But that's fine; JS is fine for what it's used for, i.e. browsers / webpages and at a stretch rich desktop UIs. I think the main issue that the author has is that for a lot of people it's become a golden hammer.
A few years ago I started applying for jobs again; what I found (but this might have been the recruiter) is that multiple companies were in the process of replacing their PHP backends with Javascript / NodeJS backends. I couldn't fathom why people were starting a new project - building the future of their company - on Node.
I mean it makes sense from a hiring point of view because JS developers are everywhere, but it doesn't make sense from a business point of view, or right-tool-for-the-job.
But maybe that's me being judgmental. I mean PHP is fine for back-end too, if that's what they were replacing.
TypeScript and WASM have both been developed in the last decade.
The former is amazingly successfully, and the later is seeing increasing adoption.
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.
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.
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...
I think he meant more in the sense of projects that weren't adapted to modern coding standards
I think this issue is probably intractable unless PHP wants to go the Python route and have a hard fork.
There is some nuance, of course. But, at large, those are your options.
Similarly, if you are writing a game, whatever dev kit your target of choice supports. With a heavy bias to the asset pipeline.
So called "backend" programming is, perhaps, different. That said, you are almost certainly best to pick whatever is close to "native" where you are deploying.
This seems like the key thing. We've gone through something similar with operating systems where there hasn't been a ton of change for a very long time now. It seems like we've just hit the same part of the lifecycle with programming languages where change happens much more slowly.
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.
> Crockford wrote his book "The good parts" that tried to write java in javascript.
This is particularly untrue. At that time (look up his talks), he was always vocal about JS prototypal design being bad BECAUSE it tried to be like Java. He pushed for things like `Object.create()` in ES5 (and opposed the ES6 Java-style class syntax) because it is much closer to how JS prototypes actually work.
He also pushed for closures and higher-order functions as the right way to code JS -- something Java wasn't even capable of. He was very much in favor of things like map/filter/reduce which are functional rather than class-oriented.
There's a LOT of stuff you can criticize about Crockford, but "The Good Parts" certainly isn't one of those things.
This the same man who wrote this?
> JavaScript has a syntactic similarity to Java, much as Java has to C. But it is no more a subset of Java than Java is a subset of C. It is better than Java in the applications that Java (fka Oak) was originally intended for. ...
> This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java.
https://www.crockford.com/javascript/javascript.html
> We would be making a tragic mistake if we didn’t retain the language’s simplicity. Most of the modifications I would like to make in the language would be to make it even simpler. There’s some cruft on it, and there are some attractive nuisances in it, which we don’t need but which people become dependent on. We’d be better off without that. https://www.sitepoint.com/interview-doug-crockford/
> A lot of JavaScript’s critics want to go back in the other direction, and make it more Java-like, but I think that would be a bad thing because it would alienate most web developers. So, I’d rather go in the other direction and train our web developers how to be programmers, how to be computer scientists, because you can in this language.
This the one? Writes Java in Javascript you say.
This is a weird statement because Crockford is known for actively recommending against writing JavaScript like Java, and goes as far as saying JS is best used when you avoid classes and `this`.
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
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.
Oh wow, five different people have already responded to challenge and correct this misapprehension.
What made you write this particular point? Crockford has consistently criticized Java for its boilerplate as well as criticizing the Java-isms in Javascript like the Math namespace/object.
I'd say JSON is pretty successful as a protocol, even beyond JavaScript.
Also The Good Parts is probably as important now as it was when it was published. The language hasn't improved — it's just grown.
That said, JSON is still an interesting study. Basically, "take the object literal syntax of javascript, get rid of functions, require double quotes, don't recognize comments." It is good to get folks to stop using 'eval' to pull some data into the browser, though it is a shame that couldn't have been preserved a bit more safely.
And, of course, json-lines and then the steady expanse of json-schema is looking to be hilarious. How long until we add in namespaces to the idea? :D
But YUI 3 was ahead of its time. The dependency management and lazy loading in YUI 3 would not make it to the mainstream for another 10 years.
1. He educated people about JavaScript the language and made it accessible to a large body of programmers as "a real language". Before him a lot of JS knowledge was obscure, and people were doing all JS programming by sharing random snippets here and there. Crockford showed how to build modular systems in JavaScript, how to avoid common pitfalls, how to reason about JS object model, DOM APIs and build larger systems.
John Resig was doing lord's work with jQuery, but his JavaScript book came out way too late to make a big difference. "Good Parts" on the other hand helped growing a whole generation of JS engineers. There were other books, too, that helped immensely, including John's book and especially Marijn Haverbeke's book, which eventually became a somewhat spiritual successor, and was "The Book" for JavaScript for about a decade.
2. He created the first linter for JavaScript and popularized the notion of using static analysis as part of JavaScript development process. For many years JSLint was the only game in town. And, on a larger level, JSLint introduced the whole notion of having a build / release process to JavaScript world. People joke about node_modules a lot, but before JSLint most teams simply FTP-ed sources to servers or were editing them live over SSH. Web programming was not a "real" programming, and Crockford helped change this perception.
3. Same goes to minification - he was the first one to talk about JavaScript execution as part of browser performance story, and created JSMin - the first minifier.
4. JSON format was largely responsible for ending XML dominance and let adopting new languages for server side development easier. I still remember times when I've been forced to only use Java because "the project required XML".
5. There's an argument that his "sticking to good parts" idea was harmful. He almost single-handedly killed ES4 proposal that would have add classes, modules, and other cool additions to JavaScript in around 2006-2009. But here's a thing: ES4 was a hot mess of seemingly unrelated proposals and features that played poorly together. Instead we spent extra years making the foundation of the language better, and then we still got all these and many other features through ES6 and further standards. Like many, I was pissed about ES4 at the time, but seeing where we are now with the language I believe he and Chris Wilson of IE did the right thing with "Harmony".
He was at the right place at the right time. Yahoo circa 2005-2010 did ground breaking job at making frontend development a separate proper discipline. They _invented_ the term "Frontend Development", they build tools for analyzing JS performance, they talked about coordinating work in larger teams and structuring large projects. Before them there were individual groups at a few large companies that were building large web applications (Gmail and Google Maps were the primary examples at the time), but the knowledge of how to do that remained hidden, tribal, and fragmented. YUI group aggregated it, published it and promoted it, making it available to a larger developer community.
They had a messy transition from YUI2 to 3 but the later was way ahead of its time. Crockford was not the primary author of the library, btw. The team was led by Eric Miraglia with significant contributions from Nate Koechley, Dad Glass, Ryan Grove, Nicholas C. Zakas etc. For many years it was one of the most popular libraries for building web applications in larger teams. It was eventually superseded by the arrival of frameworks like Backbone, Angular, React, etc. but for a period between 2006 and 2010 YUI along with Dojo were essentially acting as frameworks for us.
I agree, Crockford tends to sound like a naysayer, partially because his other ideas about compartmentalizing code, building more robust security into the language didn't pan out as he wanted, and things like Content Security Policy largely remain underutilized. But his work was important, his accomplishments are undeniable, his contributions were beneficial for JavaScript community at large.
Okay, you can draw „pretty“ UML diagrams for your code. But that makes it even more effort to maintain.
JS was designed in a week. He's completely right, it's just poorly designed. Javascript will always be around because of technical debt and habit. But that doesn't change the fact that Douglas is right.
Also nobody really uses javascript anymore. It's completely insane. We compile Typescript into javascript then run javascript. That should tell you something about javascript.
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.
This is the problem.
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.
Nope, most of these have made the language better. Optional chaining is better than a litany of `&&`, `...` is generally better than `Object.assign` or `concat`, `async/await` are generally better than callbacks... The list goes on. Rejecting these new features wouldn't have magically improved the foundation.
It is extremely performant for a scripting language, it is easy to debug, and it works in many scenarios.
People try too hard to be contrarian. Same thing happened with PHP and many other languages.
That's indeed the gist of Douglas' remark.
But if you have not much experience beyond JS, that is very hard to recognize.
Douglas is grey and old. Most JS devs are on the younger side of the IT work force.
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.
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.
You can write an extremely clean and awesome HTML/CSS document. But you very rarely find that kind on the web.
I think we neglected being more careful here because browsers became more and more forgiving. So they often render as intended, but not really like it is stated in the often invalid document. That made browser insanely complex as well. No new browser will ever be successful if it would be parsing strictly. More than half of all websites would probably stop working correctly.
I believe you could replace both HTML/CSS with something much more clear and as capable. But on the other hand we should be glad that we have standards like this and perhaps we shouldn't let perfect be the enemy of good.
Perhaps JS doesn't qualify as good, but on the other hand I think its success speaks for itself. It even grew beyond the browser and some electron apps are extremely well received (apart perhaps by your system memory). Despite that, it is a scripting language and it should mostly be used as that. Since every browser comes with a parser, it is a quite mighty tool to have.
Python is a similar contender. It is the ultimate choice for certain domains and I don't see that changing any time soon, even if python isn't perfect itself.
Talk to Google.
They are the ones aggressively increasing the API surface of the Web (driven largely by commercial reasons e.g. ChromeOS) often without much thought to the security, privacy and performance implications.
JS has the weight of the largest corporations in the world behind it that don't want to lose their investments
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.
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.
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.
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?
0: https://github.com/WebAssembly/gc/blob/main/proposals/gc/Ove...
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.
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.
I guess WASM is already taking this place?
what do you mean by this?
https://github.com/niklas-heer/speed-comparison
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
a tiny tiny ten-line snippet of code
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
And its poor concurrency story compared to other languages e.g. Scala means that it's hard to push the runtime in real-world situations.
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
(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.
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.
I'm interested!
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.
Criticising the web platform as not confirming to a set of self defined rules is lazy and pointless.
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!
Pretty much sums up everything :(
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.
#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-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.
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
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.
> 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.
As smart as he is - he obviously doesn’t give a single f* about real life problems and challenges of real life programmers.