HN Theater @HNTheaterMonth

⬐ caleblloyd

Also https://www.youtube.com/watch?v=61qmX5eAPwI which is a newer video and highlights some of the most recent Blazor 0.6 features.

I am very excited about the possibilities this brings. Current frontend/backend solutions all seem to involve duplicating contracts in JavaScript. WebAssembly frameworks like Blazor will let us get back to programming in one language but keep the SPA-style experience for the UI.

⬐ dang

Some recentish posts:

https://news.ycombinator.com/item?id=16651709

https://news.ycombinator.com/item?id=16318076

https://news.ycombinator.com/item?id=14697520

⬐ paxys

I am desperately waiting for Blazor to graduate from the "experimental" label so I can justify investing more time into it, but whatever little I have seen so far seems amazing. For someone who used to live and breathe C#, ASP.NET and Razor, this feels like a godsend.

⬐ aogaili

GWT all over again..they tried to kill JS with Java and failed..good luck with C#...

⬐ Kyro38

WebAssembly has different objectives than Java and is backed by the 4 major Browsers.

⬐ aogaili

I'm not criticizing WebAssembly but the selling points behind the framework which is a use case for WebAssembly.

GWT users cared less about how it was compiling, and at the end of the day, they were building webapps using Java and Eclipse IDE along with the rest of the ecosystem. Which is exactly the selling points being presented here.

For me this is history repeating itself.

⬐ k__

Yes, lets see how big the runtime is and how "much" server is needed for interaction in the end...

⬐ iso-8859-1

They failed because compiles took forever and you couldn't debug very well. With Graal and WebAssembly, performance might be better.

⬐ tudelo

As someone still dealing with this, I really hope it isn't GWT all over again. Ever wait 30 minutes to see a simple change to a web page? sigh

⬐ wokwokwok

There's a problem with Blazor, and that is that its not ready.

Which is why they're shipping server side Blazor [0], which is all the stupid parts of Blazor with none of the benefits.

Don't get me wrong, the idea of running .Net in WASM is very appealing to me... but server side Blazor is a daft idea, and it's a mistake.

Here's the model:

- Your component view state is rendered on the server.

- A delta is sent to the front-end.

- The frontend updates the DOM in the browser.

- Any DOM event is sent to the server.

- repeat.

Seems ok?

However, the problems here to understand are:

1) Every UI interaction, from mouse focus, to mouse drag, to click to button down, is sent down the wire to the server to be processed. For high latency situations, this will feel terrible.

2) Every client shares the same server cluster. As such, it scales badly; your application may perform well with 10 users, but for 100 users, you have 10x as much server work happening. Not business logic... UI logic. Will it scale? No one knows, but the money is on 'no'. The server scale-out demands will scale with people viewing the website; effectively this means the UI will lag out under load when the server is busy, the exact opposite of modern SPA applications and apps that remain superficially responsive under server load, and compounding issues generated from (1).

3) As many of the examples show, server side Blazor shows how you can execute arbitrary code on the server as part of your components (eg. fetch DB records). However, no vague consideration has been given to the authentication model for this. In fact, the stated high level goal is that razor components will 'with one click' work seamlessly on both WASM-mono and razor-components; ie. They are are naive of user roles and permission groups on the server, and expect to interact with an arbitrary backend 'service' with its own permission roles. (But that isnt what the examples show).

These are not trivial problems, they are, unfortunately, insurmountable architectural issues with server-side Blazor.

...and the work around is a compromise. ie. You use javascript.

Which... kind of makes it rather pointless.

This is being shipped early for business reasons, not technical reasons.

They should just wait for the WASM target to be ready; this will be a disaster, in my opinion.

[0] - https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...

⬐ martijn_himself

This is quite enlightening in that I'm very excited by the prospect of using C# in the browser without the downsides that came with Silverlight, but especially 1) seems to be a big negative! (I'm not sure I completely understand 2) and 3), does 2) only apply to server-side Blazor? Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?).

As someone who is trying to wrap his head around all this, did they go with server side Blazor because browsers do not support all required WASM features yet? What is even the point of server side rendering?

⬐ shadowmint

> Is 3) not inherent to all web development in that authentication on the client is 'disconnected' from users/ permissions on the server anyway?

Server side components directly call server code, unlike client components, which use an HttpService.

Compare for example https://dzone.com/articles/understanding-server-side-blazor, where:

> The Blazor app is hosted by an ASP.NET Core app, which also sets up the SignalR endpoint. Since the Blazor app is running on the server, the event handling logic can directly access the server resources and services.

Vs. the actual official samples, where an HttpService is used to access data from a controller: https://github.com/aspnet/samples/blob/master/samples/aspnet...

ie. Blazor server side components are indeed disconnected from users/permissions, by design... it just happens that they can also call arbitrary server side code, which is obviously a) not portable, and b) hugely unsafe.

There's an issue in the issue tracker for this, but basically, the tldr; is, no, you shouldn't call arbitrary server side code... but, you can, and so people are doing it.

... shakes head ...

(edit: Oh look, another great one, https://social.technet.microsoft.com/wiki/contents/articles/...

> We will invoke the methods of EmployeeDataAccessLayer class from our service. The service will be injected into our components and the components will call the service methods to access the database.

...)

⬐ judah

Yes, 2 only applies to server-side Blazor.

"Server-side Blazor" itself will be renamed[0] to Razor Components so as to disambiguate it with WASM-in-the-browser, which will still be called Blazor.

Razor Components seems to be a blend of different kinds of web programming models, as described by the parent poster:

- Traditional: POST + Redirect + GET

- Single Page App: Thick client in JS

- Razor Components: Traditional, but instead of POST+Redirect, it uses Web Sockets to asynchronously update state.

Razor Components are being shipped because it's building off well-known, mature technologies. OTOH, Blazor (WASM in browser) is still baking. For example, there is no tree-shaking to minimize the minimize the size of components needed to run your Blazor app. (IIRC, the average size of a basic nav app is ~2MB.)

[0]: https://blogs.msdn.microsoft.com/webdev/2018/10/02/blazor-0-...

⬐ caleblloyd

Server Side Blazor performance should be similar to Server Side generated web pages, except the framework allows for SPA-style interactions instead of full page reloads.

There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection.

With the rise of serverless and edge computing (think cloudflare workers), I wouldn't be surprised if patterns emerge to running this at the edge.

I agree I wouldn't put any high traffic apps on Server Side Blazor from the get-go. But for Enterprise apps with high complexity and a small user base, I think it would greatly streamline development.

⬐ shadowmint

> There is added resource utilization from tracking session state on the server, but if done properly it could be as little as 1MB or so per active client connection.

Just curious, where did you pull this number out of? I've never seen a SignalR connection use that little memory for anything.

⬐ caleblloyd

Server Side Blazor will have to store the current Virtual DOM Representation in memory for each client, so that it can do diffing on it if a request comes in for that client and return the diffs.

1MB is my estimate for the Virtual DOM and associated independent state for each client. I was not factoring in the SignalR per-connection memory footprint, I imagine that would already be pretty optimized?

⬐ sebringj

This is a theme in that all major compiled languages will have an ability to publish to wasm as WebAssembly is a standard that allows this and we'll see more frameworks like this coming up for various ones. It will be nice for all the specific language camps and allow interoperability as well between them. Big win in general whatever you think of .NET but that's not the big picture.

⬐ jarcane

I look forward to me getting very excited to try this with F#, only to find it requires a pile of hand-spun hacks only comprehensible to the most dyed-in-the-wool Visual Studio user, half-documented scraps of git repos that will only to get working, and will inevitably break completely upon the slightest update or change to your .NET installation.

⬐ GiorgioG

I've given up on F# because MS only half-heartedly backs it. In the meantime C# continues to pick up more and more F# features.

⬐ s369610

I suggest you check out fable if you haven't already, v2 just dropped the experience was pretty smooth (http://fable.io/)

⬐ saary

Would like to see a wrapper generator around C# libraries so they could be easily be loaded into node.js

That would make all sort of integrations between legacy systems with existing C# support libraries and newer lighter node.js projects work without jumping through crazy marshaling hoops.

Seems like a very interesting direction, embedding managed languages into JS.

⬐ jbigelow76

Do you mean something like edge.js?

https://github.com/tjanczuk/edge

⬐ kodablah

Didn't watch the video, but since the project doesn't make it clear, this is the Mono .Net interpreter compiled to WASM that is interpreting IL at runtime. The AOT .Net-to-WASM compiler is not a thing yet but is actively being worked on.

⬐ euroclydon

I'm not a big Blazor fan, but mono-wasm is cool, and if the Blazor folks would isolate their DOM/JS interop, that would be a good, lightweight starting point for folks to play around with .NET in the browser.

⬐ myl

Very, very exciting! Expecially after the download size is reduced (as planned).

⬐ None

None

⬐ plasma

I worry this is close to Web Forms again.

⬐ pknopf

I agree.

WebForms/UpdatePanel was a half-baked solution to pick-up and drop-in .NET developers from WinForms to the web, while Blazor seems to do the same thing for server-side and client-side developers.

⬐ m_fayer

This is inspired by Vue/Angular. If you're familiar with those and dig into the docs you'll see that it's conceptually very similar. Nothing like Web Forms.

⬐ aikah

.

⬐ cm2187

No a server is not mandatory to run blazor. You can run blazor server side, where the client is routing all events to a server. But that's not the way it is designed to work by default. By default everything runs client side, you could run it from a static website.

⬐ thomasz

The Problem with Web Forms was that it shoehorned statefull patterns that worked in desktop programming into http and thereby introduced very leaky abstractions. I see absolutely no reason why this should be a problem for frameworks like blazor.

⬐ maccio92

This is really great! Excited to give it a try

⬐ nosjwshere

why not compile private methods for the server and public for the client.

⬐ jimmy1

I really don't see how C# is decent anymore, can someone change my mind? I was all about it in the 2010-2013 days, but over time it just became more bloated and bloated. It's the new C++, where it tries to be everything for everyone.

Every time a new version comes out theres a 500 page tome of all the new features added. Did we really need all those features? I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!

It still has all the annoyances of java (the first thing you see in any C# file is a laundry list of imports), I am not convinced the profiling tooling is better. I will preface this with I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework.

⬐ wvenable

> Every time a new version comes out theres a 500 page tome of all the new features added.

That's not really true, the list of features in each version is pretty tight and focused:

https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csh...

⬐ cm2187

Agree. I have some beefs with the fragmentation of the framework though. I kind of hope that in the end we will end up with only two frameworks: mono on wasm for clients, and .net core for server/high performance clients.

But what is true is that there starts to be a lot of overlap and inconsistencies between multiple generations of the framework. You have object methods vs generics. You have async/callback methods vs async/await. You have ref/out returning methods vs valuetuple returning functions. etc. The language is starting to show its age even though the .net team has been adding to the syntax sparingly.

⬐ jve

I just realized maybe op was thinking about .NET release notes? They are lengthier. https://docs.microsoft.com/en-us/dotnet/framework/whats-new

But .NET is a framework that is written in C# and extensively used by C# and not a language.

⬐ None

None

⬐ fbarred

"I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!"

"I am still bitter about the initial .NET core rollout which was a crapshoot and had no parity whatsoever with .NET Framework."

Those two statements seem to be in direct contradiction with each other. Would you like iron-clad parity, or would you like to break compatibility in an effort to shed bloat?

⬐ manigandham

C# release notes are very focused and definitely not 500 pages. You can look at the major features per version in a single page and there are now point releases for smaller and faster iterations.

Many changes have also made C# much more productive and expressive by letting you do more with less. Every language has imports but the strong typing and amazing tooling makes it a non-issue. Use VS or Rider and you can type out entire programs in a few minutes without ever worrying about imports.

⬐ jve

> I really don't see how C# is decent anymore

How come it was decent once but not anymore? As others said, you are probably exaggerating by saying new version comes with 500 page tome.

However it is a joy for me to program in C#. Super-consistent language. And my favorite feature "LINQ" really gets rid of loops and loops and maybe more nested loops. Interfaces, generics - all great features, decently implemented under the hood.

⬐ eropple

Calling LINQ a "feature" still feels very off to me. It's a set of library functions with some very strange and, at least in my neck of the woods strongly discouraged, SQL-ish syntax that you can use if you like making it harder to understand what your code is actually doing. The library functions are...fine, to be clear, aside from the inconsistent-for-the-sake-of-inconsistent naming (and I know they want to ape SQL, but 'Select' is a map function, sorry). But...they're library functions. You should expect that stuff to exist in a programming language worth a fart.

C#'s feature changes over the last few years have been marginal. They nibble at the edges while stuff like record classes--an actually and materially valuable thing that significantly improves the writing of immutable and functional code--have been punted for multiple versions now.

C# is Java now, in a way it wasn't when it was younger. It's afraid of change and in being afraid of change has slowed to a crawl. Such is probably the way of most programming languages and ecosystems. But it is a little sad for me to see.

⬐ fbarred

You can call it a library, but for LINQ to work at least four major features had to be added to the language or runtime:

-anonymous types -implicitly typed variables -object initializers -lambda expressions

It's interesting that all of these features are very widely used (except maybe for anonymous types) outside of LINQ, but LINQ was the driving force for adding them to the language.

Anonymous types were needed to do the equivalent of "select field1, field2" that are familiar to SQL programmers, or to have intermediate values in a chain of Select/Where/Select operators. Implicitly typed variables (var) were needed to refer to the above types. Object initializers are needed so you could create the anonymous types, and non-anynymous ones too without breaking the LINQ chain. Lambda expressions of course were needed. All of the above are used outside of LINQ.

This was done in 2007. Java got streams and lambda expressions in 2014. JavaScript got it in 2015.

The SQL like syntax - well it exists. I think many people don't realize it's there. Everyone uses the method/lambda syntax.

⬐ wvenable

It's not lambda expressions necessary for LINQ but the ability to access the expression tree and translate C# code into other languages (like SQL). There are not many languages with that feature.

⬐ felixfbecker

I agree with everything you said, except "JavaScript got it in 2015". JavaScript had first-class functions since its inception in 1995 before any of Java or C#, and methods like `array.map()`/`filter()` etc since ES5.1 in 2011, which were already widely used long before the `=>` syntactic sugar was added in 2015.

⬐ recursive

But those functions only worked on arrays or maybe "array-likes" if you're lucky. Notably, they do not work on lazy enumerables, like LINQ does. And then linq goes farther, and allows them to used on queryable data sources that aren't even enumerable.

⬐ felixfbecker

JavaScripts stdlib is smaller, C# has a huge stdlib. map/filter on Iterables is just an npm install away, e.g. https://www.npmjs.com/package/iterare

⬐ eropple

All true! But, as you note, they're prerequisites for LINQ, not LINQ. Thing is, though? These days, I would say that all four of the features you describe are barely table stakes. Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today.

As is probably obvious from my reference to them, I believe that record types would be a contender for "most important new feature"--even moreso than async/await--after spending a lot of time with Kotlin and data classes, it is nearly impossible to go back. C# provides you with the choice of manually-updated boilerplate or mutable objects through your whole stack. That's what has generally kept me away from C# since exposure to first Scala, later Kotlin, and most recently TypeScript. And, while I now work at a C#-first company (not on the C# backend), I don't see a real reason to change that for me personally until they make writing correct code easier.

In many ways, TypeScript seems to me to be a wiser future than what C# is presenting, but that's a whole other kettle of fish.

⬐ balfirevic

> Having lambdas made C# cool in 2007, but it's not 2007 anymore and that the four features you listed are probably the important new features I can think of since 2007 is why I like C# a lot less today.

It's not lambdas but expression trees that are the key feature that made LINQ possible. That is pretty unique feature among programming languages. So you might want to reevaluate your opinion about "table stakes features".

⬐ eropple

Seeing as how every use of expression trees I've ever seen in C# is something like "try in vain to make it so people don't have to understand SQL", perhaps you will forgive me for not being particularly impressed by it.

I view C#'s expression tree stuff as a neat experiment. It's cool. But it doesn't and shouldn't change one's programming life.

⬐ balfirevic

Nice moving the goalpost there (table stakes -> changing one's programming life).

⬐ eropple

I uh. I don't think any goalposts have moved? When introduced, stuff like lambdas and the libraries that could build on them did do exactly that. But they're table stakes today, in 2018. Where's the movement?

⬐ balfirevic

Expression trees, as they are in C#, have never become table stakes and remain pretty unique and advanced language feature. When I and several other commenters pointed that out, you sad something like "yeah, but they don't exactly change programmers life". That's called moving the goalpost.

⬐ eropple

I mean, if you choose to ungenerously parse it as "table stakes" being the important part of the comment instead of, yanno, that these things that are table stakes are the thing that people actually care about in that whole ball of features, sure?

Hermes Conrad is not aspirational, my guy.

⬐ manigandham

Perhaps that's just what you've seen then and not really representative? For example the Roslyn compiler service written in C# uses expression trees to do what it does, and it opens up an entire field of possibilities for meta programming in C#.

> But it doesn't and shouldn't change one's programming life.

What's an example of something that would?

⬐ jve

When I mean LINQ, i don't necessarily mean querying SQL. Working, filtering, grouping, selecting from collections in memory works very well. And i don't necessariliy also mean LINQ query syntax, but it can also be method syntax: .Where().Select()...

And the power of ExpressionTrees that allows you to interpret code your own way. For example, substituting SharePoint CSOM library

  .IsPropertyAvailable(string)

with

  IsPropertyAvailable<T>(this T clientObject, Expression<Func<T, object>> propertySelector) [0]

is neat. Instead of magic strings you now have compile-time checking. Now you write

  .IsPropertyAvailable(s => s.ServerRelativeUrl)

instead of

  .IsPropertyAvailable("ServerRelativeUrl")

As for SQL, it may sometimes be a blocker, yes. But EF Core, for example, provides a FromSql method to use for complex queries.

[0]: https://github.com/SharePoint/PnP-Sites-Core/blob/206ee97d4b...

⬐ manigandham

LINQ is not just library functions. It stands for "language integrated query" and is a full data modeling and querying system designed around lambdas and expression trees.

It can be easily translated to other query languages (like SQL) or functional paradigms, and is much more advanced than some map/iterate operators on generic types (which languages like Go dont even have).

The LINQ query syntax (from x in list select x.a) is syntactic just sugar to easily write complex expressions that the compiler turns into the same standard list.Select(x => x.a) method calls.

⬐ eropple

I promise you that I understand the idea; I have run in .NET circles, particularly Mono, for a long time. It is an interesting goal, but I prefer to stay somewhat in the land of what is--and so I am talking about what is actually done with it in the wild, not what architects blog about. It's map-reduce-fold in the majority case, and when it's not (getting into the IQueryable minefield) I often have found myself going "oh, no."

⬐ thrower123

The weird special-case LINQ syntax appears to have receded and I don't recall seeing it in the wild for some time. Hopefully we can just all agree that was a bad idea and it can get officially deprecated and go away in future versions.

⬐ jve

Umm, the special-case LINQ syntax actually it is nothing special on itself, it just calls those methods anyway. You can actually extend LINQ by providing your own Extension methods for IEnumerable or IQueryable

⬐ thrower123

Right. Which is why it's jarring seeing these blocks of non-idiomatic almost-SQL DSL embedded in otherwise consistent C#. Particularly when you have to materialize a query by calling ToList() or similar - you end up with an extra unsightly mix of query and method syntax with the query wrapped in parentheses. Or else cluttered up with defining intermediate variables that need to be named.

Much better in my opinion to just stick with the fluent method chaining style of using LINQ methods.

⬐ recursive

You'll never get me to agree. I still use it when I need a `let`.

⬐ wvenable

Yeah, I mostly use the methods to do LINQ and rarely use the linq syntax -- but -- it's actually quite powerful and if you have to do a reasonably complex query it's much easier to compose and read in that syntax than the alternative mess of method calls and lambdas.

⬐ MarkSweep

LINQ is pretty basic if you are just using the IEnumerable overloads. It get's more interesting when you use the IQueryable versions of things. LINQ to SQL and Entry Framework provide IQueryable implementations that turn C# code in to SQL. This code snippet demonstrates the C# feature these frameworks relies on:

    using System;
    using System.Linq.Expressions;
    class Program
    {
        static void Main(string[] args)
        {
            Expression<Func<int, int, int>> expr = (a, b) => a + b;
            Console.WriteLine(expr);
            Func<int, int, int> fun = expr.Compile();
            Console.WriteLine(fun(1, 2));
        }
    }

When run, this outputs:

    (a, b) => (a + b)
    3

When a Expression<T> variable is assigned to or a method taking an Expression<T> parameter, the C# code is not translated into MSIL (normal C# is compiled to MSIL). Rather it is translated into an AST. In my example I just compiled it to MSIL, however LINQ-to-SQL and Entity Framework translate the AST to SQL. This macro-like capability is the true power of LINQ. The rest is syntactic sugar (though very delicious sugar).

If I were to try to critique LINQ, it would the normal ORM complaints. Sometimes you have to care about what is going on underneath in the C#-to-SQL translation. Your code may compile, but at runtime the generated SQL might have terrible performance.

⬐ eksemplar

It’s not, not really, but it runs a lot of enterprise and reschooling developers is really expensive. I know, because we’re in the process of going from almost exclusively c# to mostly node.js and powershell scripts with orchestra and SSIS.

The fact that Microsoft keeps doing things like core 1, the 2, xamarin and now this web assembly stuff made the business case for changing better though. Because staying up to date on c# has also become expensive.

Still, stuff like AD and ADFS, msSQL and windows servers are the backbone in a lot of enterprise, and C# integrates really easily in that environment. I still think node.js, powershell and SSIS does it better, but I can certainly see why c# is still a thing.

⬐ manigandham

Javascript still doesn't have 64-bit numbers or real multithreading or serious async or proper namespaces and modules.

C# the language is also not the same as the .NET runtime and framework, but Microsoft is the best organization in the world when it comes to backwards compatibility and the C# code you wrote a decade ago will still work flawlessly today.

I don't understand how you're switching to Node.js and shell scripts(?!) to take over all that functionality.

⬐ eksemplar

Node.js is better at web apps, and for us it’s been much faster to get stuff out too. The ability to quickly prototype is instrumental when you’re doing service design, and node excels at that.

SSIS is better at moving data.

Powershell has come really far, it’s certainly not C#, but where it really excels is when it’s integrated into our Azure orchestra giving us faster error reporting and making us capable of addressing those errors quicker. It’s also a language that’s shared between developing and operations. So while C# is better technically, powershell is better organizational and that means it’s better.

Simply put C# has become an unnecessary burden, in our setup. I’m not sure I’d use node for huge projects, but our backends are mostly simple frameworks for manipulating relatively small amounts of data.

We’re not leaving .Net or Microsoft, our node server runs behind an IIS with IIS node. SSIS, powershell and Azure are obviously Microsoft. Our entire security model is based around AD and ADFS.

⬐ Rapzid

I mean.. I really like TypeScript and nodejs as an every language that I can use and promote without too much push back but "Does it better" isn't a qualifier that comes to mind. Sure I can come up with specific areas that I enjoy more about nodejs/TypeScript, but I can also come up with just as many for C#/.Net:

* Async/Await implementation is pretty much superior

* Real threading; great for task pools as well

* Task local storage; something the nodejs community is very interested in but thus far only lives in hacks on obscure run-time features

* Speed?

* Integers?; come on man

* Linq/Entity Framework(though these should mostly be possible to implement in TypeScript now)

If I had my druthers I'd be using F# though, TBH.

⬐ eksemplar

I don’t think C# has superior async functionality, it used to, and certainly had for a long time, but not today.

Threading and tasks add unnecessary complexity.

Speed? What speed, this web assembly example is more than 5mb of .net libraries. We make apps for people on less than 3g.

Entity is one of the worst, least productive and most error prone frameworks we’ve ever had in our stack. Especially code first.

Linq almost made us stick with C# forever.

⬐ cm2187

They have some projects to reduce the binary size (it is still an alpha project), like doing tree shaking.

JavaScript isn’t light either, if you look at the amount of stuff a major website loads.

⬐ eksemplar

I don’t, I look at what we load.

⬐ codenesium

I'm curious what issues you had with entity framework?

⬐ manigandham

Webassembly is a brand new runtime, it has nothing to do with C#. Blazor is alpha stage and hasn't even finished designing functionality yet.

C# on the server running on .NET Core is one of the fastest web stacks, and the async and threading help greatly with that. You can keep everything synchronous if you want, but it's good to have the flexibility when needed.

How is EF unproductive? What options are better?

⬐ eksemplar

.Net core isn’t faster in a way that’s relevant to us. You have to keep in mind that being productive is what’s important when your primary focus is supporting the business.

Whether we gain a little efficiency or not from core is relatively irrelevant if it takes longer to produce the solutions.

We’re not Netflix, our max load is 60.000 concurrent users, and that’s relatively rare.

What isn’t rare, is someone loading an app in a remote area, where the mobile coverage is terrible, and if it had to load .net libraries in that setting, they’d frankly never be able to do their jobs.

So the speed of .net core is irrelevant to us, and to most people really, I mean, Netflix runs on node.

If you don’t know why EF is terrible, I’d wager you’d never used it. We use LinqToSql in our C# apps. Why? Because it’s productive, and again, it may be slower than entity, but it’s slower in a way that really doesn’t matter to us.

I mean, the video highlights it so perfectly when the guy goes “look how fast it compiles”, as if that’s ever useful when your application takes much longer to load for the user.

⬐ Rapzid

Parts of Netflix run on node, lots of major back-end infrastructure does not. This isn't even really a nit IMHO, I just feel that's a gross miss-characterization of their system: http://nebula-plugins.github.io/ .

⬐ manigandham

Sure, use whatever is more productive on the server-side, although in my experience the strong-typing and full classes and namespacing make it much easier than JS.

I don't get the comparison on the client-side with webassembly though. This is an entire UI framework, and hasn't been fully designed and optimized yet, as stated. It's no different than using React and neither would be good options if optimizing for low-bandwidth remote areas.

I've used EF since it was first released, and we haven't encountered any major issues. We migrated from nhibernate a long time ago and fallback to Dapper occasionally for complex SQL and performance. What do use instead? Or is the argument to not use ORMs at all?

⬐ eksemplar

GraphQL is strongly typed though, and you can always use typescript, I wouldn’t personally advice it unless it works for you.

We’ve not really seen any real trouble moving to dynamic types, possibly because we utilize stuff like SOLID. When you’re not really using object oriented to its fullest, because it’s fullest adds complexity and complexity costs a lot of money and you’re already pretty fascist in your approach to how responsibility and changes are handled in your systems, dynamic types aren’t really a problem.

If I was building a huge system with a lot of complexity, I wouldn’t pick JavaScript, but I probably wouldn’t chose C# instead of JAVA either. And that’s not the way I would’ve viewed the world 5 years ago.

Anyway, I think people should use what works, I just think C# has lost its usefulness compared to other technologies and I really think web assembly is s terrible move for Microsoft.

But I’d love to be proven wrong.

⬐ tluyben2

> Entity is one of the worst, least productive

I think that hits the nail on the head; I never got why anyone used that. We never did and we have been using c# for a long time (all over to Core now) and all the horror stories never applied to our work, I think, because we never touched entity.

⬐ Rapzid

That's... Odd. I have used a LOT of different ORMs and nothing else came even close to the experience of Entity Framework with its fantastic type inference and Linq integration. Bring your contexts into linqpad and you have one of the most transparent and streamlined ORM development sessions I could possible imagine. This was all with 6 though(IIRC) and code first; not with Entity Framework Core.

There were certainly a couple gotcha's and quirks to get used to, particularly around initial modeling, but the unit of work pattern made possible with task local storage was spot on.

⬐ quickthrower2

In the newer C# features there is a lot of syntax sugar, and you don't really have to use them. I don't think it is any more bloated than in 2013, and most C# code bases wont look much different to back then.

⬐ felixfbecker

> I would love it if I saw a new version of a language come out and it removes language features, wouldn't that be a change!

That is exactly .NET Core

⬐ neilsimp1

That didn't really remove language features though. That removed framework features.

⬐ felixfbecker

What language features would you like to see removed?

⬐ sctb

We detached this subthread from https://news.ycombinator.com/item?id=18136654.

⬐ plaguuuuuu

C# has a super solid feature set, built up over years of development. When you know C# well you can really lean on it - today I was applying list operators to iterators over the results of database queries that hadn't even been evaluated yet, so that I could apply them just to a specific page of the result set. That's pretty cool - LINQ is a beast combined with the ienumerable/iqueryable interfaces.

C# might have minor drawbacks (ok single inheritance is a pain) but it works better than most languages in its class. The only thing that makes me feel inadequate is seeing some really advanced level Haskell code :o

⬐ alkonaut

C# is still very much a decent language, but it's not as shiny as it used to be. I have worked professionally with .NET and C# since the 1.0beta and I have to agree: it's not that good any more. Not because it's gained so much bloat or because it has gotten worse, but because its ecosystem has been fractured so many times I stopped counting. The core ordeal is just the last in a series of disruptions and the previous one was Roslyn. These aren't bad initiatives, it's just that they aren't ready. Roslyn is barely working in VS together with the project system (which is odd given it was shipped first in VS2015)! I applaud ms for developing more in the open, but the constant renaming and churn of everything is tiring.

But all that aside, C# is still decent, the only thing making it less shiny now is that we realized that OO is a promise that didn't deliver. I don't want to program another line without proper algebraic types for example - yet here we are.

⬐ eksemplar

I’m not sure who’s downvoting you, but it sure isn’t managers who’s paid for people getting re-educated in asp, then mvc and razor, then web-api, then xamarin, then core 1, then core 2 and that’s just to name a few.

Hell, it’s still not easy for people to deploy a .net core web api and run it in an IIS installed with basic settings. You can laugh at it, but that’s 80% of the damn workforce who doesn’t know how to do that.

I mean, the JS environment changes, but I haven’t had to pay for anyone getting reschooled since we swapped to JS.

⬐ alelefant

You are obviously free to dislike C#, but it seems silly to say they should stop adding features or should remove features.

> Did we really need all those features?

If you don't need them, don't use them. I've found the new features to be great. nameof, string interpolation, property initializers, exception filters, static imports, null propagator. And if you haven't used the language in awhile going back to 5.0 the async await features are fantastic. 7.1 introduced async Main which we've started using in console apps. I use all of these features every day.

> I would love it if I saw a new version of a language come out and it removes language features

Why, exactly?

⬐ Faark

My simple go-to example is tuples. They are on the third attempt to introduce that feature. First was generic Tuple.Create. Did not support naming individual fields. Then came anonymous classes. Those could only be used where type is inferred. The latest are using braces... most powerful, but also syntactically quite different from what came before.

I like C# adding new features, and understand some try-and-see-what-sticks is unavoidable. But I don't understand them not deprecating the old versions. And still wonder if improving an earlier version would have been possible/better.

⬐ bryanrasmussen

1. Some people dislike languages with a large instruction set

2. I will propose that programming languages are like anything else created by humans - some parts great, some parts not that great. Furthermore some parts of a language are used more than other parts, it should be hoped that the parts least used in any particular language are parts of that language that are not that great. Given these things it might be reasonable that some time you saw a new version of a language in which they said Feature X really sort of didn't make sense and anyway hardly anyone ever used it so we are removing Feature X. Adjust code accordingly. (probably there should be deprecation stage of a year or so with warnings)

⬐ pjmlp

Even human languages aren't not fully used.

There are multiple levels of understanding, regionalisms and specialized technical terms that few get to use.

⬐ jimmy1

And that works in language -- its terrible when you are trying to make computers do very specific things in specific scenarios. It leads to hiring nightmares as well. "Oh I write language X in this style, not familiar with your style"

⬐ userbinator

Yay, now all the bloat of .NET can spread into the browser too! </s>

Seriously, I'm saddened to see all this overwhelming hype and "excitement" --- I am a developer myself, and just don't get it: I have used .NET apps before, and I could immediately tell it was such just from the speed (or lack thereof) and memory consumption --- the difference is obvious. It's the same with Java, which is not at all surprising. The absurd amount of object-oriented obfuscation I encountered in the few times I had to debug someone else's code in C# probably contributes to that too.

Taking over a second just to load an extremely simple app from localhost in the demo says all I need to know about this --- "no thanks". Please consider your users' experience...

⬐ GiorgioG

You have used .NET apps that were slow/mem consuming - have you ever considered that it’s the app developer’s fault? I can write a slow memory hogging app in C++ too.

1 second to load the whole app compared to the shitshow that is most SPA apps these days is a dream.

⬐ pknopf

Having two garbage-collected languages in the browser likely won't work out well.

⬐ GiorgioG

What does having N-number of GC'd languages have any relevance? Your OS is an "app browser" with a variety GC language-based apps running happily alongside one another (Go, Java, C#, Elixir, etc)

⬐ pknopf

Your OS is multithreaded, JavaScript isn't.

Scrolling in your browser is bad enough when JS/dom has to many allocations.

⬐ GiorgioG

What does WebAssembly have to do with JS?

WebAssembly support for multithreading is in progress https://github.com/WebAssembly/design/issues/1073

Look, you want to poo-poo on WebAssembly, that's fine, but the folks who build these browsers don't seem to be concerned enough about having GC'd langs running on their platform. Who has more at stake - you or them?

⬐ pknopf

Also, even when WebAssembly gets proper threading, .NET/Mono still uses a "suspend the world" GC mode which will still halt your execution.

Nobody is poo-poo'ing anything. It is what it is. .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical.

I expect Rust to lead the way here.

⬐ GiorgioG

> .NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical.

I guess I don't understand what kind of 'high-scale applications where performance is critical' wouldn't be suitable for .NET but instead better suited to a systems programming language like Rust. If the bottleneck becomes the single-threaded JS interop, then what difference does it make which WASM language/runtime you choose as long as it's at least as fast as JS?

⬐ pknopf

Rust has no GC, .NET has a GC.

Rust will be delivered with no runtime (minimal deployed size), Blazor will need the entire mono runtime and BCL.

⬐ GiorgioG

It won't require everything to be downloaded - https://www.mono-project.com/news/2018/01/16/mono-static-web...

Will it ever be as small as a systems language like Rust or C? No - never. But the productivity gains that C# & the .NET framework provide are a worthwhile tradeoff for 99% applications.

The .NET team is actively working to optimize the payload to a manageable size.

You haven't specified what evidence you're basing this statement on:

> ".NET just isn't likely to be a good fit for the browser for high-scale applications where performance is critical."

Because Javascript is a good fit? Facebook sends down 500k+ of JS and how many of their billion+ customers complain about it?

⬐ pknopf

WebAssembly (currently) doesn't have direct access to DOM, so it has to use JS, hence the GC.

Here is some of the JS for Blazor: https://github.com/aspnet/Blazor/tree/master/src/Microsoft.A...

⬐ m_fayer

I was going to reflexively downvote this but it doesn't quite rise to the level of bad faith that I look for before I downvote.

But, I'd ask you to recheck your impressions every couple of years, especially if a technology seems to be gaining popularity as opposed to dying. Stubborn and irrational corporate loyalty and manufactured hype are not the only reasons a technology stays alive, quality does play a role sometimes.

.NET these days, especially with core, has a focus on power, performance, portability, and a sleek user experience. C# is a widely loved language that has a plethora of good stable tooling around it, and an intelligently evolving featureset that enables terse, expressive, functional-if-you-want-it coding. I think, like Kotlin, it's very well suited to writing "functional core, imperative shell" apps. You can also use it to write bloated J2EE-style lasagna-code, but no one's forcing you to do that.

As for Blazor itself, it's similar to React/Vue/etc., but in C#. Writing complex frontend apps is hard even with TS and the big frameworks, and I can't think of why a new entrant with a statically typed language (with types at runtime!) that's still web-native would be a bad thing. As for startup time, hopefully they'll improve that, but you wouldn't use Blazor for a simple app anyway.

⬐ userbinator

But, I'd ask you to recheck your impressions every couple of years

My most recent experience with a .NET application was within a day, and my impression has not changed since the beginning. (Although hardware has gotten faster...) Essentially every time I've had to use an annoyingly sluggish app that looks like a native one, I later discovered it was written in .NET . Despite all the claims of performance I have not once encountered an app that reflected those. It's never been "wow, .NET is so fast now?" but always "why is this so slow? ...oh, it's .NET."

You can also use it to write bloated J2EE-style lasagna-code, but no one's forcing you to do that.

That's the same non-argument the Java folks give. In theory it's possible to do better, but the language and culture naturally tends toward overengineering monstrosities because it is so much easier to do so when the language makes complexity easy to create.

...which brings me to the point I'm trying to make: your users don't care what fancy language or framework or whatever else you used. They care about the speed and (implicitly, since it affects speed) resource usage of your application, and that's what they'll notice.

⬐ quickthrower2

This framework is still fledgling, however it is very exciting for a .NET developer, not because it's a shiny new thing to learn, but because it's the opposite ... it's allowing you to reuse existing skills to code for the web, while seemingly allowing you to create a React-like architecture of components / state. All using a decent language C#. This is simplifying things if you are already doing a full stack and working half the time with JS/TS and the other half with C#.

I hope MS really get behind this and see it through to a production ready version.

⬐ mattferderer

A lot of people seem to be voicing strong hate without understanding what this even is. (Not the parent comment, but others)

Wasm (Web Assembly) is still early in development. It's looking like it will create a high performance & excellent VM to compile code to for the browser. This is great for any language. A lot of proposed features could give it all the same features you have in JavaScript. But those features are only proposed. Lin Clark gives a great intro on this podcast - https://pca.st/5rjS

Blazor is an experiment at utilizing Wasm to do JavaScript like things with C# in the browser. I've never heard anyone say use it for production yet. The YouTube video here is 1 of the best talks you'll see on it if you watch it. I was lucky enough to attend in person.

You can use Blazor without a server to create static sites & host them on servers like Netlify.

Performance & file size isn't something they've put much effort into at all yet on Blazor. Way to early & easier problems.

There are other experiments going on with .NET, Mono & Wasm . See Uno & Ooui.

Steve Sanderson did an experiment a few years ago to see if this was even possible based on some interesting research he found. It grew from that. They have put a really awesome team behind it. It's gained a great following & has a very active Gitter channel that the MS team (notably PM Dan Roth) talks in. They're also quick to respond on GitHub.

⬐ knocte

> All using a decent language C#

F# is also supported, and potentially any .NET language.

⬐ eksemplar

We’re a .net house, or we see to be, so I should be embracing this like you are. I’m not though, not because it’s not cool and all, but because js front end has so many things that aren’t in .net.

I mean, where is the graphql and Apollo like functionality in .net?

How do you make a pretty reactive frontend easier and faster with .net compared to vue/react/angular?

How big does the browserbased app get when it has to load .net libraries?

Maybe I’m just not seeing it, but I honestly think what laravel is doing with PHP on the backend and vue on the front end is the brilliant way of approaching web apps and I think what Microsoft is doing with web assembly is going to be a needlessly complicated mess that’s really, really unproductive in terms of time to market. And I think they are mainly doing it because Microsoft never made their own JS front end.

I’ve been following it for a while too, and I see a lot of the xamarin disaster in it.

⬐ pjmlp

I am yet to bother with GraphQL and Appolo, and I bet in 5 years they will be in same place as NoSQL databases are today.

I honestly don't see any benefit over plain Web APIs.

⬐ eksemplar

Then you haven’t used them. They are to rest apis what rest were to soap times ten.

You don’t have to take my word for it though, try it yourself: https://graphql.org/swapi-graphql/

⬐ pjmlp

You mean like dropping the documentation and schema validation tools that REST still wasn't able to match beyond what Swagger kind of offers?

⬐ learc83

That's a very strong statement.

I have used them and I dont agree with this at all.

I suppose next you're going to say I haven't used them enough?

⬐ eksemplar

I think you may have been fortunate enough to use a lot of well documented rest APIs.

I work in the public sector, we integrate with more than 600 different IT systems. I’d say around 10% of them have the documentation they ought to.

With graphql, the API is the documentation.

On our own end, it’s improvee production and quality because it’s faster to build an API with it, that lives up to our standards for APIs. It’s also harder to fuck it up without realizing because it’s typed and forces schemes.

The last advantage is that it allows for an easy way to get the data you need from a general query, that might not be important in a lot of places, but when you build apps for workers who use them in a rural setting, it’s kind of nice to minimize the data they need to transmit to the bare essentials. You could do that with a rest api, but it would take a lot more time to implement.

⬐ learc83

I'm not going to rehash the numerous argument against GraphQL. My point is Plenty of people who have experience with REST, SOAP, various old school RPC protocols, and GraphQL (myself included) prefer REST.

The superiority of GraphQL is not as self-evident as you believe it is.

⬐ cm2187

First this is not just websites. It is also webapps (think universal, cross platform client apps).

Then the assemblies will be cached and I understand they are working on getting them small. Silverlight wasn't that bad in term of load time.

If the website really deserves a SPA (creating a blog in a SPA is ridiculous), people expects the website to take a little time to load even with javascript, and it does. My online broker trading platform does, webmails do, etc.

For reactivity, I am not sure I get your point. With async/await it is going to be trivial, and .net on wasm will likely be faster than javascript.

⬐ None

None

⬐ recursive

.net was doing graphql back when it was called odata.

⬐ pknopf

What about tree-shaking/bundling/splitting? I don't see that happening, which means that you have to literally download the dlls needed to render every single page/component.

⬐ mattferderer

Blazor is an experiment. They're trying to get an MVP & figure out a solid foundation.

There are a ton of performance wins they can do later. Those have little value right now.

⬐ GiorgioG

Tree-shaking is already there:

https://github.com/aspnet/Blazor/issues/1076

⬐ grokys

If you're interested in seeing how a GraphQL client might look in .NET, over at GitHub we've been working on an experimental LINQ-like GraphQL client for our APIs:

https://github.com/octokit/octokit.graphql.net/

It only supports the GitHub GraphQL API right now, but everything is generated from the schema so it should be possible to make it support other APIs.

⬐ Serow225

Thanks!

⬐ eksemplar

.net core really should adopt it, that would make it really competitive to node on the backend in terms of prototyping.

⬐ cm2187

I heard in previous podcasts that they surveyed large clients and that the response was enthusiastic to this technology. My guess is that they are serious about it.

Now we must distinguish blazor and mono on wasm. Mono on wasm allows the .net runtime to run in webassembly. Blazor uses the mono runtime and creates a UI framework. I think the game changer is the .net runtime in wasm. Once it is production ready, I am sure we will see competing UI frameworks, some possibly even based on xaml.

⬐ mattferderer

Competing UI frameworks exist. Blazor is just one. See Ooui & Uno for others.

⬐ xab9

Whenever Microsoft tried to do web frontend it was "not really good" (it was borderline catastrophic). Asp spaghetti, aspx components, viewstate handling, razor templates etc.

When I worked with .net guys (which happened quite often) 9 out of 10 had been like wow, I don't have to touch frontend, because MS will solve that for me "somehow", plus the frontend is messy and crap and javascript is a terrible language and C# rocks (but F# even rocks more) and I'm not going to learn all this sillyness (because I want to reuse my skills).

At least with new-angular they feel a bit better and they can praise typescript, because typescript is "just like C#". Let's just hope noone pulls an angular-one-to-two style rewrite/clusterfuck...

⬐ voltagex_

I started professional web dev doing ASP.NET around the time of the ASP 2 to 4 transition. After looking at a Vue/Typescript/Webpack template that had 400 dependencies, give me User Components and ViewState any day.

⬐ keithnz

I was doing some work recently on an old asp.net app, and rather than rocking the boat, I just updated it with the existing webform / viewstate structure... which I haven't touched for years. Was weirdly smooth and easy to do things. There is some disadvantages to the approach... but there is definitely something kind of nice about the approach.

⬐ thrower123

It's so good that they brought it back as a first-class thing, see the newer Razor Pages stuff. I'd definitely use that for any kind of quick little internal applications, there's so much less ceremony involved.

⬐ cm2187

You are comparing 90s technologies to today's web standards. It's like saying that "open source isn't good for websites because look at php".

⬐ eksemplar

Microsoft front ends haven’t really changed since the 00s.

⬐ jrs95

Razor templates are quite good as far as server side templating goes imo

⬐ czechdeveloper

To me razor seems great, but I can only compare it with quite horrible HUGO templating.

⬐ pknopf

Blazor, to me, feels like WebForms/UpdatePanel.

WebForms/UpdatePanel was a half-baked solution to pick-up and drop-in .NET developers from WinForms to the web, while Blazor seems to do the same thing for server-side and client-side developers.

Microsoft eventually created MVC, which embraced the nature of the web (HTTP verbs, no viewstate, etc). I would urge developers to just dump into the deep end and use tech native to the browser. I know wasm is now native, but Blazor is running a VM in it that wasn't designed for it.

C# developers might find some comfort in TypeScript. Maybe Angular?

⬐ recursive

Wait, what's wrong with razor?

⬐ pjmlp

I have been jumping between native and web development, alongside backend since the late 90's.

I will take any server side rendering framework, with some sprinkle of JavaScript, over any SPA framework.

A node_modules directory with several thousand packages just for a basic CRUD app, really?

⬐ jgalentine007

I have a very similar background and hate the idea of having a bunch of dependencies too - but I found my Vue pwa 'just works' even with 1007 folders in my node_modules directory. We'll see if it stands the test of time.

⬐ manigandham

It's a lack of any well designed standard library for JS, combined with weak namespacing and modules, as well as the rougher compilation step.

⬐ dustingetz

which yields better outcomes: organic growth (open source) or central planning (microsoft)?

⬐ pjmlp

Central planning for sure, given the lack of UI/UX focus we usually see on open source stacks.

Coding is fun, but providing a productive experience also requires doing lots of stuff that FOSS coders don't invest any resources into it.

⬐ dm3

Clojurescript is quite nice in avoiding the whole webpack/npm/grunt/gulp/... build and dependency tooling evolution nonsense. There are a few other compile-to-javascript environments that are as good by now I suspect if you don't like parens as much.

However, I agree that server-side rendering is much simpler in all of the cases where desktop app-like experience isn't required.