7 ms·

I am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality. I really don't ge

I am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality. 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.

manigandham 7y ago
.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.
- nwah1 7y ago
  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.
  - thefounder 7y ago
    With 5g that won't be an issue anymore...
    - sdfsdfsdfsdf3 7y ago
      In 2026 maybe...
    - quantummkv 7y ago
      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.
  - davidhyde 7y ago
    > “30 kilobytes for React” This is just not even close to being true.
    - namelosw 7y ago
      There's 3kb Preact with almost identical API.
      - StavrosK 7y ago
        So what's the other 27KB+ for?
        dmitriid 7y ago
        Fiber, support fo async rendering, suspense, hooks. A different VDOM algorithm.
        tracker1 7y ago
        Better error handling and messaging...
    - nwah1 7y ago
      The compressed size is 31 kb, and other frameworks are smaller. https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
  - manigandham 7y ago
    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).
    - TimTheTinker 7y ago
      > 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.
    - nwah1 7y ago
      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.
- deleted 7y ago
  [deleted]
- moogly 7y ago
  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.
  - manigandham 7y ago
    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.
    - moogly 7y ago
      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.
      - manigandham 7y ago
        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.
shmerl 7y ago
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.
ksec 7y ago
>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.
- avian 7y ago
  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".
  - quantummkv 7y ago
    > 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.
    - khc 7y ago
      People who develop webassembly are not your average web developers
    - vraivroo 7y ago
      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.
Faark 7y ago
> 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.
- TheCoelacanth 7y ago
  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.
- manigandham 7y ago
  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.

manigandham 7y ago

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

nwah1 7y ago
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.
- thefounder 7y ago
  With 5g that won't be an issue anymore...
  - sdfsdfsdfsdf3 7y ago
    In 2026 maybe...
  - quantummkv 7y ago
    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.
- davidhyde 7y ago
  > “30 kilobytes for React” This is just not even close to being true.
  - namelosw 7y ago
    There's 3kb Preact with almost identical API.
    - StavrosK 7y ago
      So what's the other 27KB+ for?
      - dmitriid 7y ago
        Fiber, support fo async rendering, suspense, hooks. A different VDOM algorithm.
        tracker1 7y ago
        Better error handling and messaging...
  - nwah1 7y ago
    The compressed size is 31 kb, and other frameworks are smaller. https://gist.github.com/Restuta/cda69e50a853aa64912d https://gist.github.com/Restuta/cda69e50a853aa64912d
- manigandham 7y ago
  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).
  - TimTheTinker 7y ago
    > 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.
  - nwah1 7y ago
    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.
deleted 7y ago
[deleted]
moogly 7y ago
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.
- manigandham 7y ago
  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.
  - moogly 7y ago
    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.
    - manigandham 7y ago
      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.

shmerl 7y ago

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.

ksec 7y ago

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

avian 7y ago
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".
- quantummkv 7y ago
  > 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.
  - khc 7y ago
    People who develop webassembly are not your average web developers
  - vraivroo 7y ago
    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.

Faark 7y ago

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

TheCoelacanth 7y ago
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.
manigandham 7y ago
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.