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