5 ms·

You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge. It's a bit silly to say you quit when you toppe

You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge. It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain. There are hundreds of directions you could go in, and I consider that a good thing. There are choices, but there are recommended paths for beginners as well. It sounds to me like you're hating on a toolchain that you don't have any experience in.

caseymarquis 8y ago
While I'm excited about WASM and .NET on the frontend, I don't think Blazor is quite the solution I want. (Getting there though!) If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for. Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET. I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.
danielovichdk 8y ago
I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath. I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place. Back in the day, we had much less choice, and that made working with the web a lot more joyful.
- s_y_n_t_a_x 8y ago
  Seems like you're just looking through the nostalgia filter. We're in a lot better place than we were a decade, let alone 2, decades ago.
  - hombre_fatal 8y ago
    Also, seems like they're complaining that client development is hard. And then comparing it to their familiar back-end stack. .NET is far from simple.
- stickfigure 8y ago
  chrome is the new IE6 I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work. I did web development in the IE6 era (and before). This is nothing like that.
  - danielovichdk 8y ago
    I do believe the live standards from whatwg is a good example of some vendors making it possible to implement features before other vendors do. It creates a gap, it creates a constant drive forward which again seems, IMO, to sometimes be about vendor competition instead of the greater good of the web.
- pault 8y ago
  I don't doubt your experience, but when people say "toolchain" in the context of front end development, it's usually a reference to the dev environment and build toolchain, not the HTML/CSS/JS technologies themselves. I've been focusing primarily on front end development since 1999, and while I also hate the current complexity in setting up a complex JS client, it allows us to scale far beyond what was possible back in the jQuery days, and it has made my life much easier. It becomes a problem when people suggest that you set up babel, webpack and hot module reloading for a site with a couple of forms.
mycall 8y ago
Microsoft said they are optimizing the huge payload with tree shaking and other techniques.
- s_y_n_t_a_x 8y ago
  So they're trying to get where Webpack already is. But I hope they do, it's nice to have as many development options for the web as possible.
manigandham 8y ago
FYI: Blazor is using the Mono runtime and is still in experimental stage. It's 2MB raw, can be compressed over HTTP as any other file, and can get much smaller after linking and optimizing the build. Early tests have made the whole package as small as 200kb which rivals many JS builds but with far more capabilities.

caseymarquis 8y ago

While I'm excited about WASM and .NET on the frontend, I don't think Blazor is quite the solution I want. (Getting there though!) If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for. Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET. I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.

danielovichdk 8y ago

I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath. I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place. Back in the day, we had much less choice, and that made working with the web a lot more joyful.

s_y_n_t_a_x 8y ago
Seems like you're just looking through the nostalgia filter. We're in a lot better place than we were a decade, let alone 2, decades ago.
- hombre_fatal 8y ago
  Also, seems like they're complaining that client development is hard. And then comparing it to their familiar back-end stack. .NET is far from simple.
stickfigure 8y ago
chrome is the new IE6 I've heard this repeated a few times, and it's utter nonsense. Unless you're deliberately going off into the weeds, a full featured SPA works the same on Chrome, Safari, Firefox, and Edge. I don't even bother testing on multiple platforms anymore; they just work. I did web development in the IE6 era (and before). This is nothing like that.
- danielovichdk 8y ago
  I do believe the live standards from whatwg is a good example of some vendors making it possible to implement features before other vendors do. It creates a gap, it creates a constant drive forward which again seems, IMO, to sometimes be about vendor competition instead of the greater good of the web.
pault 8y ago
I don't doubt your experience, but when people say "toolchain" in the context of front end development, it's usually a reference to the dev environment and build toolchain, not the HTML/CSS/JS technologies themselves. I've been focusing primarily on front end development since 1999, and while I also hate the current complexity in setting up a complex JS client, it allows us to scale far beyond what was possible back in the jQuery days, and it has made my life much easier. It becomes a problem when people suggest that you set up babel, webpack and hot module reloading for a site with a couple of forms.

mycall 8y ago

Microsoft said they are optimizing the huge payload with tree shaking and other techniques.

s_y_n_t_a_x 8y ago
So they're trying to get where Webpack already is. But I hope they do, it's nice to have as many development options for the web as possible.

manigandham 8y ago

FYI: Blazor is using the Mono runtime and is still in experimental stage. It's 2MB raw, can be compressed over HTTP as any other file, and can get much smaller after linking and optimizing the build. Early tests have made the whole package as small as 200kb which rivals many JS builds but with far more capabilities.