>I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel. It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.

I think it might have to do with people considering 40 as very old in Silicon Valley and those in their late 20s and early 30s have barely learned this lesson.

It may surprise you that the people behind Web Assembly are largely senior compiler developers who have certainly been around the block. Dan Gohman has forgotten more about compilers and VMs than 99% of the commenters here will ever know.

Sorry that was just replying to my parents on Web Development. I assume anyone who is doing compiler and VM development would be very senior and on a whole different level of expertise.

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective?

I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old analog instrument and there's generally wonder and curiosity. Show a computer science class a slide with a 1 MB hard drive compared to an 1TB SD card and there's generally ridicule and laughter. "Look how stupid they've been", not "we've learned many valuable lessons since".

> Do computer science curricula not include enough historical perspective?

Anecdotally speaking, the average web developer does not have any formal computer science education. Most are self taught or attend a bootcamp or two at most. They have excellent vocational skills, but little knowledge of anything in computing outside of their narrow path of learning.

People who develop webassembly are not your average web developers

Oh man, this is so true. An acquaintance of mine who had recently graduated a bootcamp was crowing about how much he knows. I asked him for the big-O performance of adding an item to a linked list. He looked at me like I was speaking Martian.

And a lot of times, these are the people writing confidently on the internet about web development. Problem with programming is most of the people in the community are amateurs and they communicate via the internet. And on the internet, no one knows you are dumb.

I feel like the world of computer programming is caught in a very fast iteration of the old adage, "Those who cannot remember the past are condemned to repeat it." Which oddly, I was curious about that quote's origins, so I just went and looked it up. The full quote in context is:

"Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, infancy is perpetual. Those who cannot remember the past are condemned to repeat it." - George Santayana (1863 - 1952) [The Life of Reason (1905-1906) Vol. I, Reason in Common Sense]

This neatly dovetails with the thoughts that were floating in my head. This part, is the explanation I believe, for the current state of programming, "when experience is not retained, infancy is perpetual."

You realize that the people behind Web Assembly, for example Dan Gohman, are some of the foremost world experts in compilers who have worked for literally decades in the field?

I don't think that GP was talking about the people who actually made web assembly, but about those who hype it. I'd be surprised if the former were not full of awareness of and respect towards the technologies that came before.

Your appeal to authority notwithstanding, yes I do realize that. I was not referring to, nor condemning the authors of WebAssembly for their work. I was proposing an answer to the question above, about why it seems like a lot of software development is re-inventing the wheel.

I wonder the same thing. I suspect the age of the field plays a role. While theoretical computer science is about 200 years old practical computers only exist for 70 years and are widespread for about 40 years. Many professors teaching computer science today couldn't study computer science back in their days because it simply wasn't offered.

This has wide reaching effects, one of the more obvious ones being that 20 year old knowledge seems ancient to most.

In other fields of engineering no one would ever think of calling themselves engineer after a 6 months bootcamp training.

Sadly on several countries this is a thing, which also contributes to a low level of expectation, regarding the quality of delivered work.

My Informatics Engineering degree certainly did include historical perspective of previous languages, operating systems and hardware architectures.

.NET ecosystem is fantastic right now. .NET Core is fast and efficient, asp.net is better, faster and more full-featured than ever, and MS is ahead of everyone with Blazor Components that finally provide a real alternative to JS frontend frameworks and can run either server-side or as WASM modules.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

It won't be megabytes, that's only in the experimental phase. Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).

> Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

It's worth pointing out that .NET Core has an assembly/executable generator that can package only the .NET libraries that are actually used.

Rust-based WASM front-end libraries will likely be small and also high performance. Unfortunately, all of the existing ones are highly experimental right now.

> “30 kilobytes for React” This is just not even close to being true.

The compressed size is 31 kb, and other frameworks are smaller.

https://gist.github.com/Restuta/cda69e50a853aa64912d

There's 3kb Preact with almost identical API.

So what's the other 27KB+ for?

Fiber, support fo async rendering, suspense, hooks. A different VDOM algorithm.

Better error handling and messaging...

With 5g that won't be an issue anymore...

Until they decide that 5g is good enough to allow them to ship the browser with every website. Net speeds have been increasing every year and yet the websites take longer to load.

In 2026 maybe...

IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.

Why not? Works fine in our tests, and a large part of .NET apps are internal apps that work great with this kind of framework.

I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the server.

I mean, sure, if you have tens of internal users maybe (but then it could be argued that it could just as well be deployed as a desktop app -- I could buy the deployment method as an argument, mind you). But thousands? Call me sceptical. It just makes me think of `asp:UpdatePanel` all over again.

Are you referring to the session state and websockets connections? Both scale horizontally with minimal effort, I don't see the problem.

Asp:UpdatePanel was great for it's time, and no different than doing an XHR request now and replacing the contents of a div with the response. You can still get basically the same effect with libraries like Turbolinks which is what Github does.

> It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.

I hear that often in regard of programming languages. But I see a lot of value in remixing a lot of existing ideas in a new package. A wheel can only be so round and its interaction with the road is quite simple, but tech is different. Systems have widely different requirements. Old implementations have shortcomings and a hard time fixing those, especially due to backwards compatibility of complex systems. I cannot imagine how hard is to remove null from an existing programming language, as C# is currently trying. At some point it's just easier to start from a clean slate.

Is all the effort worth it? I don't know. But I wouldn't want to imply they are just doing it because their out of touch with reality.

Applying the "reinventing the wheel" meme to scenarios like this kind of misses that wheels actually have been reinvented numerous times resulting in major advancements in wheel technology.

Reinventing the wheel takes a lot of effort to be worth doing, because it takes a lot of effort to improve foundational technology, but it is sometimes worth doing if you are going to put an appropriate level of resources into it.

With proper versioning, I don't see why even major features like that would be a problem.

Null removal is completely compile-time anyway so it's complicated to compile but relatively simple to implement as a language upgrade at a certain version, and in this case it's also opt-in.

MS and Oracle claimed copyrightability of APIs. Think about that. It surely didn't help accepting .NET and Java as worthwhile universal tools. Too bad for them. Good thing WASM avoided this pitfall.