Hacker News Reader

Comment by danielovichdk | Hacker News Reader

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.

View on HN

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

I agree.

Microsoft did a terrible job not having one framework for every path, like it did with the original .NET framework.

The naming could be better. I think .NET -> .NET Classic and .NET Core -> .NET would be better, and maybe .NET Standard -> .NET Specification.

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.

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.

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.

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.

Yeah sorry, I really don't buy it.

Strong typing is admittedly great and there are solutions to introduce that in JavaScript. However, this is hardly a dealbreaker in complex apps written in JavaScript.

OOP, interfaces: debatable and unnecessary fluff. There are plenty of productive languages without OOP. Example: Elixir. And there are plenty of productive languages without interfaces. Example: Go.

Reflection is unnecessary in JavaScript. You can access any property within an object dynamically and the language is interpreted, so there's no need to perform fancy reflection operations at runtime.

Dependency injection is an engineering pattern. You can apply this to almost any language. And ironically, plenty of JavaScript backend and frontend frameworks have attempted to use it successfully: Angular, Ember. Hell I even wrote my own DI layer once upon a time. https://github.com/divmgl/nwire

I'm sorry, I really disagree with you. I believe C# has the ability to be productive, but there is just no way you're going to convince me that it's superior to JavaScript and its ecosystem. There's a lot of disdain on Hacker News for JavaScript and it's honestly beyond me.

Correction: I recently learned that Go has interfaces. But my point still stands.

Tooling like vue cli makes life easier. But this like projects in .net.

Writing your own http server is difficult in both.

Vue cli new project run.

New asp.net project run.

It’s identicle.

Try to write both for scratch is hard.

So no node/npm/http server is no easier than .net/iis/owin.

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.

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

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.

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.

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.

Exactly.

For a while .NET Core also had a folder within the project for third-party NuGet modules, and for a simple web app they would go into the 200mb, and that's without the compiler itself. Now those files live in a hidden folder (or were absorbed by the stdlib), and nobody complains about it anymore.

Initiatives like Yarn's plug-and-play [1] would have the side effect of being great marketing for Node.js development.

[1] https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-pl...

It sounds like OP was trying to make a beginner-level sample app in Node.js - is your .NET app of the same nature? Judging by the mention of SQL Server, it's not.

It's a CRUD app.

Nothing special about it. It just happens to use this specific stack.

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.

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.

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.

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.

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.

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.

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.

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.

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

I've found that parcel-bundler "just works" for stuff like that without needing extra configuration, including the Babel part.

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

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.

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.

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.

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/

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.

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

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.

> Redux with a middleware that saves the whole state to localstorage automatically

I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.

> 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

Or I just write some javascript that creates a view of based on the data it has cached locally and updates that view when the user interacts with it.

This is what we're talking about. I have a relatively simple problem, I don't need to pull in additional dependencies in the form of a framework that's just going to make things more complicated and require me to learn its paradigms.

> I don't want to save the whole state automatically. The state isn't complicated. Even the data isn't complicated.

If you don't want to save the state, why mention localstorage in the first place? The point of using the Redux thing would be to automate that process, so that you don't have to manually save/retrieve anything to localstorage yourself.

I'm currently building an app that works nicely as a web app, but it needs to store gigabytes of data and work with only intermittent network access. I'm considering trying to bundle the server-side code into a simple Windows binary that just fires up an HTTP server and binds to 127.0.0.1. Would that work for you?

That's essentially Electron. I'd considered that, but if I'm writing a native application component anyway I may as well make the whole thing native instead of using wonky web tech. I'd like to do that, make it completely native, but right now there are factors beyond my control that I'd have to work around first.

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.

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.

Ludicrous! Ludacris is the rapper :P

Reply on news.ycombinator.com