Hacker News Reader

> Angular (their current choice) has, ah, high training costs

Does it? You need to know typescript (which you arguably should be using regardless of frontend framework) and what dependency injection, observables and components are. Plus some syntax for the templating language, which is fairly intuitive. That’s enough to get you going, I don’t see it as being much more of an investment than learning a react stack.

It also has the benefit of being all in one, like .NET, so there aren’t multiple different packages for every function that could be used, depending on who your team is. That all in one factor is probably why it’s a natural complement to .NET.

I think you answered your own question when you mentioned Angular being an "all in one".

Angular needs a bit more training because you are heavily encouraged to do things the "Angular" way which requires a lot of abstraction and componentization.

I was more referring to the essentially mandatory third party packages that you need with react, react router, redux/whatever you please, something for your styles, something for forms etc. With angular you just use what comes out of the box, but either way you have to learn whatever the thing is so the effort seems to be the same. Not sure what you mean about abstraction and componentisation vs other frameworks.

Angular likes when you structure your application a certain way.

You try and tweak how you want to break up a component and the house of cards starts to fall over.

I feel house of cards is a very good metaphor for the whole angular ecosystem.

Unsubstantive. Care to share your thoughts?

I agree, the versioning has been a mess and they're constantly breaking changes to the API. Just trying to update a project is like trying to change playing cards in a house of cards...

Does it? You need to know typescript (which you arguably should be using regardless of frontend framework)

That's highly debatable. We moved back to ES after using Typescript for years and couldn't be happier. We're much more productive than we were with Typescript, and that's with people that know the language. We get much of the benefits of Typescript by just using a jsconfig.json file in our project and using VSCode. The Typescript language service will typecheck JS code if you want it to.

And there is a big upfront cost for onboarding developers with Typescript and Angular.

This is interesting, I'm mostly hearing the opposite experience. What made you decide to make the switch back?

It’s not faster, but it does improve code quality. I also don’t think it’s that hard to learn, but I’m coming from a strongly typed, object orientated background. Like the sibling commenter I’d also be interested in hearing your team’s experiences with it.

> That all in one factor is probably why it’s a natural complement to .NET.

Very much agreed. And I also agree that, at least in a corporate context, training for a React stack would also be expensive, potentially more so.

And there are plenty of people out there who have no problem picking up Angular.

Looking at job market data alone, though, Angular commands a premium to .NET-only. Anecdotally, folks who feel comfortable with .NET, but who find eg; React+Redux bewildering, also feel constantly confused by Angular and can get themselves into trouble without close guidance.

> Anecdotally, folks who feel comfortable with .NET, but who find eg; React+Redux bewildering, also feel constantly confused by Angular and can get themselves into trouble without close guidance.

Makes sense, the modern frontend frameworks are pretty similar anyway, despite the amount of noise about their differences. If you find react hard you’ll probably find angular hard and vice versa.

Exploring a bit, and sharing for those with similar curiosity...

This seems to have a React-ish architecture with familiar C# templating (Razor):

Razor syntax is the JSX-equivalent, which has been used for C# templating for years: https://docs.microsoft.com/en-us/aspnet/core/mvc/views/razor...

Blazor Components: https://blazor.net/docs/components/index.html

Their docs are pretty scattered, especially for someone coming from React, but it seems to have similar features and lifecycle methods, albeit a bit more ersatz.

    onClick => onclick (etc)
    componentDidMount => OnInit / OnInitAsync
    componentWillReceiveProps => OnParametersSet[Async]
    componentDidUpdate => OnAfterRender[Async] 
    shouldComponentUpdate => ShouldRender
    componentWillUnmount => Dispose

There is also a convenient `bind` which is shorthand for `value="@Foo" onChange="@(e => Foo = e.target.value)"` and a magical `<FooComponent bind-Foo="@ParentFoo">` for passing state down...

You don't seem to be able to define multiple components in a single file (which in my experience leads to bloated components).

Routing seems to be defined within the .cshtml file rather than centrally, which can get messy in my experience.

I don't see anything to support state that is shared across far-flung leafs of a deep UI tree (eg; Redux, Context), but maybe there are standard .NET constructs for that which I'm not aware of.

I don't think this is going to win anyone from the React world – some design choices seem not to grok some key insights of React – but I can imagine it taking off amongst folks who were happy with server-side Razor templating and have been unhappy with Angular.

> Keeping engineers fungible and cheap to hire & train is a priority for enterprise software divisions. Software ecosystems that rely on the patience and curiosity of developers to explore an uncoordinated constellation of packages and design their own architecture (eg; Java, React ecosystems) can be suboptimal.

I can't help but feel this is a cleverly worded put down of Enterprise software developers. Having worked on both sides of fence, there are significantly differences but it mostly comes down to the type of end product rather than whether developers are "fungible and cheap".

For example, at the company I work for now we develop at least 12 different fully deployed products year. When I worked for a startup, we developed a single product over 5-10 years. Most modern frameworks are definitely geared more to the latter than the former.

Blazer is definitely not geared for the single highly optimized application. But I could definitely see using it to get much better results for our internal applications with much less effort. We could probably absorb the run-time cost.

Shipping the runtime as a compressed file is only a few hundred kilobytes right now, which is smaller than many JS payloads. That's before any optimizations which are far easier to do in statically compiled languages and binary files like WASM. I expect the overall payload size to be far lower than an equivalent app in React.

The current JS frontend frameworks are great but they all require a tremendous amount of work to get going for any complex application. The tooling, build chains, libraries, boilerplate code and general verbosity of JS really needs a cleanup and Blazor is incredibly attractive in that regard.

Ah, an update re; bundle size:

> Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. Blazor now runs on Mono, which is currently significantly larger. However, opportunities for size optimization abound, including merging and trimming the runtime and application binaries. Other potential download size mitigations include caching and using a CDN.

Why is .NET valid only for enterprise applications?

Sorry, I didn't mean to imply that it is. .NET, and C#/F# generally, can be useful in a tremendous variety of applications, and especially outside of the SF bubble, are used for... everything, startups included.

.NET's most common use case, based on my research, is enterprise applications, but certainly not its only.

Thanks for calling this out.

I'll throw in my two cents on top of this:

* SPAs: Microsoft has a vested interested in porting a lot of code to SPA applications. Teams being the latest example.

* Windows is dead, long live Windows: A desire for a lighter version of Windows in the near future running on ARM and you suddenly have existing dev tools and code moving to a Chrome OS like environment with little fuss.

* Edge: Is jumping over to chromium and wishes to support existing chrome extensions. What blazor may also allow are some pretty sophisticated download-once applications also coming through that 'store(?' with first class support.

* Linux Love: If linux is the rural America of 2016 then MS is Trump. OSX and Google seem to be locking people in and MS is trying to give more choices.

* Windows is Dead, part 2: Can't stress this one enough. Giving enterprise developers and teams a way out of the legacy sandbox seems to be key.

tl;dr - Re-cut the Star Wars scene of 'Luke I am your father' to Nadella and myself. Change the response to 'Yesssssssss! <hug>'

I feel like I've been licking toads recently. So much crazy going on.

web2py was “the first truly full-stack, integrated, get-it-all-here, framework for modern web app development” years ago and still thrives.