10 ms·

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET tool

I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. Good luck fixing that. I'd rather keep my code and tooling simple and clean.

s_y_n_t_a_x 8y ago
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
I pretty exclusively use .NET backends with VueJS frontends. You get all the power of the MS devtools for the backend, near total separation of backend and frontend logic, and then you get all the SPA benefits in the frontend. I absolutely love using SPA tools for frontend development (you just have to spend a year or so with them and really get comfortable, so maybe it's stockholm syndrome), but I can't imagine switching to a dynamic language for backend development. I may switch things up once WASM is further along. I would love to be using C# on both sides. I would still want very clear backend/frontend separation though.
cc81 8y ago
.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example. There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started. Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on their homepages.
- danielovichdk 8y ago
  I agree. Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.
  - quickthrower2 8y ago
    The naming could be better. I think .NET -> .NET Classic and .NET Core -> .NET would be better, and maybe .NET Standard -> .NET Specification.
latronic_notron 8y ago
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. This is cute. I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet. What is 60mb compared to that?
- kingcrais_420 8y ago
  60MB is a significantly lower amount compared to 40GB, but I don't think it is fair to compare the disk space of an operating system, IDE, and database server to a directory of javascript libraries.
  - qudat 8y ago
    If a developer cannot meaningfully work within .NET without an IDE, it absolutely counts. Just like someone on the frontend cannot work without babel or typescript. Those libraries add specialized tooling for the project in question. Instead of downloading a runtime that has a huge std, in JS everything is downloaded on a per-project basis. I cannot speak to .NET, but want to work with python? Bring in one library and it'll top 40MB (e.g. numpy). I don't get why so many people complain about `node_modules` filesize, it's not even an issue to think about.
    - scrollaway 8y ago
      They complain because they're under the impression that everything in node_modules will end up shipped to the browser. It's also more visible. Python libraries are hidden in the environment far from your shell or file manager. So you don't know that your virtualenv weighs 300mb. But node_modules is right there, you can't help but look. In other words it's a complete lack of experience, regardless of how adamant the OP is about their skills.
      - latronic_notron 8y ago
brogrammernot 8y ago
Node modules doesn’t get deployed out from your local machine, it’s pulled in during the build. Also, .NET and “easy to use” hasn’t happened in forever. Unless you’re counting the “Hello world” tutorials that are useless. The .sln file within a .NET project ends up being pretty damn large, so the whole 60mb node module thing seems a bit ridiculous.
AnIdiotOnTheNet 8y ago
I'm with you. I'm not employed as a developer, and am certainly not a web dev, but a few years ago I (perhaps foolishly) used some spare time at work to create a tool to help the people who do the non-sitting-in-an-office work in our company get more accurate and relevant documentation for their day-to-day workflow that they could access via a cheap tablet connected to our WiFi. It grew, as projects do, out of its original simple use case and now it needs to be usable in scenarios where network access won't be available for most of the work day, which means I need to rebuild it --in whatever time I can manage to devote to it, dev not being my primary or even secondary responsibility-- to deal with that and better handle the functionality we tacked on later. After a review of my options, which unfortunately doesn't seem to include writing a native application (for reasons I still may be able to work around), I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. Basically, just a client application written in JS. No special frameworks, no complicated toolchains. Even that is a pain in the ass because the web world hasn't quite worked out how to store local data in a non-stupid way.
- pault 8y ago
  > I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is supported by all browsers and all you need to do is de/serialize your data to JSON when your data changes.
  - crooked-v 8y ago
    My thoughts given that outline would be: - Redux with a middleware that saves the whole state to localstorage automatically - Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store - Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary Then stick some Progresssive Web App stuff in there so the whole bundle can work offline entirely from browser cache.
vinw 8y ago
Riot is a good solution for simple SPAs if you don't like huge toolchains. It gives you web components and DOM binding and all that, all in a 15 KB package that does all the compilation in a few milliseconds on the client. No configuration of babel or webpack or whatever to worry about, just host your app as static files that point at your API. https://riot.js.org/ https://riot.js.org/
titanomachy 8y ago
Ludicrous! Ludacris is the rapper :P
jazzdog 8y ago
I come from the .Net toolchain as well, no longer develop full-time, but write tools for my business as needed. I use Angular (6 or whatever). They talk to a .Net (core) server as little as possible. What I find is the iterative dev turnaround time, that cycle between find a bug - fix it - test it, is so much faster with angular than if server-side rendered. It's a joy. That same cycle on server side in .Net - change some .cs file and check that fix quickly - , slowly rather - a real pain. That alone drives the choice for me.
MarvelousWololo 8y ago
Last time I followed the official .NET tutorial I was also shocked when I had to download +1.5gb of dependencies. It was more than 4 years ago though and the landscape might be a lot better now but I don't think they managed to keep the whole thing under the 60mb mark. The tooling is just simple and clean when you've been working with it for a long time.
dimgl 8y ago
You mean ludicrous? `node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this". I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling is dead simple... much simpler than the NuGet/IIS/OWIN nightmare that is C# development. I think you're very close minded and you'll likely be stuck in .NET land forever. And that's okay if that's what you like or if it's what gets you a paycheck. But to completely dismiss this ecosystem as if it's not productive... it's just a sign of naiveté. Good luck.
- manigandham 8y ago
  It's really down to language and ecosystem. JS as a language and NPM as a ecosystem are not as productive as C# and the .NET standard library, framework and Nuget. With WebAssembly, C# Razor Components will soon be able to run either server or client side and still maintain the same highly productive development that's missing from JS.
  - dimgl 8y ago
    I’m sorry but I guess I’m still missing the point. How is it not productive? It takes me a few seconds to get a REST API going.
    - manigandham 8y ago
      It's not as productive. Anyone can create a REST API in any language in a few minutes, that's the easy part. Building a complex app is different though and much easier and faster in a proper environment that has strong typing, OOP, interfaces, reflection, dependency injection, a solid standard library, and more. Being able to use that same environment to create frontend views and code will greatly improve productivity compared to the current Javascript frameworks and limitations.
      - 8y ago

s_y_n_t_a_x 8y ago

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

I pretty exclusively use .NET backends with VueJS frontends. You get all the power of the MS devtools for the backend, near total separation of backend and frontend logic, and then you get all the SPA benefits in the frontend. I absolutely love using SPA tools for frontend development (you just have to spend a year or so with them and really get comfortable, so maybe it's stockholm syndrome), but I can't imagine switching to a dynamic language for backend development. I may switch things up once WASM is further along. I would love to be using C# on both sides. I would still want very clear backend/frontend separation though.

cc81 8y ago

.NET is not that simple either, you are just used to it. Beginners will think it is confusing with .NET, .NET Core, .NET standard for example. There are many options in the front end sure but when you just pick something and learn it then it is not very difficult to get started. Just start with for example just React or Vue and don't add any state management. Create the apps with their CLI and follow the tutorials on their homepages.

danielovichdk 8y ago
I agree. Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.
- quickthrower2 8y ago
  The naming could be better. I think .NET -> .NET Classic and .NET Core -> .NET would be better, and maybe .NET Standard -> .NET Specification.

latronic_notron 8y ago

> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. This is cute. I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet. What is 60mb compared to that?

kingcrais_420 8y ago
60MB is a significantly lower amount compared to 40GB, but I don't think it is fair to compare the disk space of an operating system, IDE, and database server to a directory of javascript libraries.
- qudat 8y ago
  If a developer cannot meaningfully work within .NET without an IDE, it absolutely counts. Just like someone on the frontend cannot work without babel or typescript. Those libraries add specialized tooling for the project in question. Instead of downloading a runtime that has a huge std, in JS everything is downloaded on a per-project basis. I cannot speak to .NET, but want to work with python? Bring in one library and it'll top 40MB (e.g. numpy). I don't get why so many people complain about `node_modules` filesize, it's not even an issue to think about.
  - scrollaway 8y ago
    They complain because they're under the impression that everything in node_modules will end up shipped to the browser. It's also more visible. Python libraries are hidden in the environment far from your shell or file manager. So you don't know that your virtualenv weighs 300mb. But node_modules is right there, you can't help but look. In other words it's a complete lack of experience, regardless of how adamant the OP is about their skills.
    - latronic_notron 8y ago

brogrammernot 8y ago

Node modules doesn’t get deployed out from your local machine, it’s pulled in during the build. Also, .NET and “easy to use” hasn’t happened in forever. Unless you’re counting the “Hello world” tutorials that are useless. The .sln file within a .NET project ends up being pretty damn large, so the whole 60mb node module thing seems a bit ridiculous.

AnIdiotOnTheNet 8y ago

I'm with you. I'm not employed as a developer, and am certainly not a web dev, but a few years ago I (perhaps foolishly) used some spare time at work to create a tool to help the people who do the non-sitting-in-an-office work in our company get more accurate and relevant documentation for their day-to-day workflow that they could access via a cheap tablet connected to our WiFi. It grew, as projects do, out of its original simple use case and now it needs to be usable in scenarios where network access won't be available for most of the work day, which means I need to rebuild it --in whatever time I can manage to devote to it, dev not being my primary or even secondary responsibility-- to deal with that and better handle the functionality we tacked on later. After a review of my options, which unfortunately doesn't seem to include writing a native application (for reasons I still may be able to work around), I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. Basically, just a client application written in JS. No special frameworks, no complicated toolchains. Even that is a pain in the ass because the web world hasn't quite worked out how to store local data in a non-stupid way.

pault 8y ago
> I'm thinking that my simplest option is to just write a single page of JS that writes HTML to the DOM directly and works with data entirely locally, synchronizing it with a server API (.NET) when available. I don't know what your requirements are, but you've just described an SPA framework. Do you think it will be easier to implement your own instead of using something like vue or react? Also, localStorage is supported by all browsers and all you need to do is de/serialize your data to JSON when your data changes.
- crooked-v 8y ago
  My thoughts given that outline would be: - Redux with a middleware that saves the whole state to localstorage automatically - Some simple background timer stuff that uses ononline and onoffline events to know when to poll for updates, then dumps the JSON contents from the polling into the Redux store - Some React components that act as one-way output of the stuff in the Redux store, optionally with a basic routing lib if some menus/navigation are necessary Then stick some Progresssive Web App stuff in there so the whole bundle can work offline entirely from browser cache.

vinw 8y ago

Riot is a good solution for simple SPAs if you don't like huge toolchains. It gives you web components and DOM binding and all that, all in a 15 KB package that does all the compilation in a few milliseconds on the client. No configuration of babel or webpack or whatever to worry about, just host your app as static files that point at your API. https://riot.js.org/ https://riot.js.org/

titanomachy 8y ago

Ludicrous! Ludacris is the rapper :P

jazzdog 8y ago

I come from the .Net toolchain as well, no longer develop full-time, but write tools for my business as needed. I use Angular (6 or whatever). They talk to a .Net (core) server as little as possible. What I find is the iterative dev turnaround time, that cycle between find a bug - fix it - test it, is so much faster with angular than if server-side rendered. It's a joy. That same cycle on server side in .Net - change some .cs file and check that fix quickly - , slowly rather - a real pain. That alone drives the choice for me.

MarvelousWololo 8y ago

Last time I followed the official .NET tutorial I was also shocked when I had to download +1.5gb of dependencies. It was more than 4 years ago though and the landscape might be a lot better now but I don't think they managed to keep the whole thing under the 60mb mark. The tooling is just simple and clean when you've been working with it for a long time.

dimgl 8y ago

You mean ludicrous? `node_modules` directory topping 60+ mb means nothing when the final product is an optimized bundle or a `node` process loaded in memory. A large majority of developers don't care about this because they're just looking to get actual work done... not sure why you're trying to "fix this". I'm also not sure what you're talking about when it comes to unclean code and complicated tooling. The tooling is dead simple... much simpler than the NuGet/IIS/OWIN nightmare that is C# development. I think you're very close minded and you'll likely be stuck in .NET land forever. And that's okay if that's what you like or if it's what gets you a paycheck. But to completely dismiss this ecosystem as if it's not productive... it's just a sign of naiveté. Good luck.

manigandham 8y ago
It's really down to language and ecosystem. JS as a language and NPM as a ecosystem are not as productive as C# and the .NET standard library, framework and Nuget. With WebAssembly, C# Razor Components will soon be able to run either server or client side and still maintain the same highly productive development that's missing from JS.
- dimgl 8y ago
  I’m sorry but I guess I’m still missing the point. How is it not productive? It takes me a few seconds to get a REST API going.
  - manigandham 8y ago
    It's not as productive. Anyone can create a REST API in any language in a few minutes, that's the easy part. Building a complex app is different though and much easier and faster in a proper environment that has strong typing, OOP, interfaces, reflection, dependency injection, a solid standard library, and more. Being able to use that same environment to create frontend views and code will greatly improve productivity compared to the current Javascript frameworks and limitations.
    - 8y ago