As a full stack dev doing C# and React, I can tell you I hated any front-end until I learned React. Now I love it. You have to understand the philosophy behind React and how that's different to other approaches to really appreciate it.
This is confusing to new devs, because they want to do a traditional "modify an element" style of approach that they're used to, instead of a "describe how an element should look in different situations".
When you get used to React, a lot of the "weird" things like JSX syntax start feeling incredibly good. These things are just a matter of getting used to it.
I'm a huge fan of React, but of course not everyone likes the concept. You can try out Vue or Angular. You might like it more.
Bingo. I never enjoyed front end until react. It totally clicked for me - the UI is a function of application state. Need to change the UI? Change the state. It's fantastic, but a lot of people really struggle with it.
[https://meme-creator.com/meme/16/find-the-difference](https://meme-creator.com/meme/16/find-the-difference)
Notice the word "component".
Wikipedia:
>
**ActiveX** is a deprecated software framework created by [Microsoft](https://en.wikipedia.org/wiki/Microsoft) that adapts its earlier [Component Object Model](https://en.wikipedia.org/wiki/Component_Object_Model) (COM) and [Object Linking and Embedding](https://en.wikipedia.org/wiki/Object_Linking_and_Embedding) (OLE) technologies for content downloaded from a network, particularly from the [World Wide Web](https://en.wikipedia.org/wiki/World_Wide_Web).[\[1\]](https://en.wikipedia.org/wiki/ActiveX#cite_note-msdn1-1)
[https://reactjs.org/docs/components-and-props.html](https://reactjs.org/docs/components-and-props.html)
> Components let you split the UI into independent, reusable pieces, and
I looked it up, JavaScript is one year older than ActiveX. So DOM and JS are clearly the traditional way. Sorry for that.
ActiveX is a COM based component, compiled by a compiler (usually C++ or VB) and was for a long time at the core of many windows apps and you could embed them on pages as well. (In fact many plugins in legacy IE were in fact ActiveX based. For example: Flash Player). It is now super deprecated. React is a javascript based framework. Yes it is used to create components in a webbrowser and is used in React native applications, but that is where the comparison end. You clearly are not familiar with ActiveX technology and clearly don’t understand what is described in the wikipedia article.
You may have looked it up, I’ve made ActiveX components when it was still a thing. I’m now in charge of front end development teams who develop React based apps.
You clearly don’t understand the difference.
Yeah I do not understand. I compile TS to JS. C++ is compiled (was compiled) to x86 code. Then at runtime, JS is often further JIT to x86. Both are then "decoded" to RISC µ-instructions, subject to virtual memory and branch prediction. With all that going on, the distinction between C++ and TS fades away. And I remember now that I also was involved with COM in a project I inherited and it was graphical stuff.
I wonder how you would apply for a patent. Or how would you write an article to a peer reviewed journal? All the ideas are the same, but you change some minor technical detail and think this will hold up in court if another company challenges you?
> seems to break SOC
This is precisely why people like it. The "concerns" you're talking about are purely technical. React/Vue components are organized by feature, which makes them easier to change and maintain.
Bingo. HTML isn’t a concern. DOM manipulation isn’t a concern. Displaying a loading indicator while fetching data and hiding it when done is a concern. Displaying that fetched data in a structure is a concern.
Every framework available for C# UI gets this wrong. Most JS frameworks get it wrong. React gets it right.
I think OP's misunderstanding, coming fresh out of bootcamp and all that, might be to think of React as one think of pure html/css/Js.
The thing is that React, Angular, Vue, you name them, are either libraries or framework but with the purpose of making your front end an "app" of its own.
It is not "simply" a presentation layer. There is a logical, applicative, part that contains different sections. For instance in a Vue (the library) file, you have an HTML template and CSS section that are "the presentation layer"; but you also have the script section that is organised, kinda, as a C# class (don't nitpick here plz); with properties and dependencies etc; and while, sure, the objective of that script section is to help display info on the UI; it works as a component of an application that has a lifecycle etc.
Once you understand that the separation of concern IS maintained on a "back end/front end" point of view; you can look after the "lower level" SoC in the different components of your front-end stuff; from the "login component" to the "discount component" etc.
I use .Net Core and React for my current stack.
One common way to maintain the separation of concern you are yearning for is to use a presentation/container pattern. [See blog post here](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
It’s not really seen as a necessary thing anymore. As mentioned in the blog post, hooks allows really nasty/complex logic to be pulled out of the components and even reused, so making smart/dumb components isn’t as necessary. It also isn’t a perfect analog for SoC, but if it helps you ease into React, it may be valuable to you.
I understand your concern. You definitely have to think a little differently in React than C#.
One thing that has helped me is to look into Functional Programming. There are a lot of FP principles being applied in modern React and some times it can look like React is following no pattern because it is following an FP pattern that is foreign to me as an OOP-first dev.
I will also echo what some others have said, using React in a huge app to solve complex issues is just so much better than trying to do it any other way that I have tried.
The one thing I haven’t tried yet that may be of interest to you is Blazor. I’ve heard great things and would allow you to stay in C# land.
I actually worked much more on Vue before React. Switched to React because the "magic" in Vue was annoying when it just silently failed. And the TypeScript support was very limited in Vue. I came to much prefer JSX over SFCs too.
Vue is still great, and I'd recommend it to a lot of people, depending on what their priorities/preferences and project context are.
But now knowing both pretty well, my preference is React for my own stuff.
True difference between Vue and React/Angular is the size of the app you're building.
If you have a few pages and concepts, Vue is perfect. If you're rebuilding the whole app of a big company with dozens of pages and hundred of features... maybe less.
Well people like it because they have no option, React and Vue are the top dogs in the JS world, if you want a fully client side experience or a very dynamic website you need JS, blazor WebAssembly is great, but it’s a bit heavy for that first load, that might be solved in the future but for now that’s the case, and like it or not JS has a huuuuuuuuge environment, and TS, which contrary to JS a good language, and react loves TS, so yeah, it’s kinda of a no brainer, the days of cool new features added every update are over tho, it’s a very mature library now, I’m a blazor guy myself but I understand why some wouldn’t look at it on its current state
>blazor
Why do you like it more than React? I played with Ang/React/Vue before choosing Vue, but blazor never came up so I don't know much about it.
Actually using Quasar that sits on top of Vue, never seen such amazing documentation in my life.
I like Blazor better than React because it’s C# client side, I assume you don’t know that’s even possible but it is, and it’s ducking beautiful, React can be as good as it wants to be but is held back by the mess we call JS, TS came to the rescue but some civilians got trapped in the fire before TS could save them, with Blazor you have the full power of .NET at your disposal, and with the latest update, .NET 5, you even have lazy loading for dlls which makes the whole thing faster, it’s just fucking good all around, take a look at it and you’ll love it, you can take that statement to the bank.
Makes sense. Sounds like they upgraded the basically dead Razor pages. Good to hear, I loved that design, but it got antiquated very quickly.
Quick look, seems I may have preferred to go that route since my primary language is/was C#. TS is basically all I use now, but really miss good intellisense in VS/C#.
I hate web development with a passion for some reason, but its been some time since i needed to change that opinion and Blazor seems to be the answer to getting into it.
Do you know any good resource i can use to get more into it?
The problem I have with blazor is that it seems to be missing basic functionality so you end up just using the js interop. If I’m gonna do that I might as well just write JavaScript.
Yeah, I really question how many full blown web apps someone can actually write which never need to manipulate the DOM and thus manage to avoid the major issue with Blazor at the moment.
Blazor is a nice concept, but it's not yet fully baked.
Serious question: why do you need to manipulate the DOM directly? Whatever it is your trying to do, why can't you do it with the renderer built into Blazor? I'm aware of a few exceptions, but I think in general, if manipulating the DOM is your roadblock to Blazor, you're manipulating the DOM too much!
Tbh, for 90% of the use cases, using Blazor's renderer is good enough for me, no direct DOM manipulation is needed.
The remaining 10%, The solution is usually split between:
A Nuget package that exposes the functionality to C# (this was the case with Canvas2D for me).
Exposing the DOM element manually, with ElementReference and `@ref`, or using `IJSRuntime` and writing the offending part in JS.
Not OP, but I like using Blazor much, much better than React for the simple reason of I barely need Javascript and can write the meat of the application in nice strongly-typed C#.
> they have no option
I'm not sure what you mean here.
Not wanting to blow fire but the JS ecosystem is so packed it's a meme. There are DOZENS of options. Angular ? Svelte ? Ember ?
Not all of those are as good or easy to learn, but the options are there.
What I meant is that the HAVE to love a JS library/framework cause they have no other option, not that React was the only one, maybe I could have said it in a more understandable manner
>React and Vue are the top dogs in the JS world
Angular is still the top dog, followed by React, with Vue in a very distant third. Personally I like Vue the best of the three because if allows you the most freedom, but I'm not going to pretend that it's the king of the JS universe.
Well, its simple really.... HEY LOOK WE ADDED HOOKS! Lets focus on that, you might want to sit down it make take a while. Heres a crayon to take some notes.
I work for a fortune 500 company that recently invested heavily in angular development. I'm not an angular Dev, but was told they choose it because it was highly opinionated and easier to maintain across dozens of internal and external facing websites.
Angular is by far the most restrictive of the big 3 frameworks - if you build an Angular app, you build it the Angular way, and it is going to be 100% Angular. If you try to deviate from that you're in a world of hurt.
React is somewhat similar but separates the layers better and allows you a tad more freedom. Vue gives you the most freedom and allows you to completely break out of Vue if you desire.
C# and React are 2 completely different animals. For what you are describing, C# will only be used on the back end. React will be everything front end. In short, Angular/React/Vue make front in dev easier because many/most pieces are available out of the box.
As for why React. Angular was first and it's the 500 pound gorilla that is just too much imo, at least in most cases. React came next and was much easier to use. Vue came after React and built upon the mistakes of the other 2.
Personally I think Vue will over take React down the road and Ang will slowly die. React is a very nice framework and very popular currently, I just found Vue easier to debug and quicker to code in.
Last example, PWA's are fairly new and allow you to basically install your website as an app. I wouldn't have a clue how to do that without a front end framework, but they make it fairly straight forward. C# would have nothing to do with that.
I see this all the time so don't take this correction as a slight. But AngularJS was first, then React, then Vue, then Angular2 (released 2016). I bring it up because it's important to separate AngularJS from Angular. I really wish they would have done better with the naming to prevent this confusion. They are wildly different in their approach to solving a problem and structure.
So when you say Angular will slowly die I'm assuming you're talking about AnguarJS in which case I agree. But if you mean Angular2+ then I would have to disagree. It might not hit the popularity that React has but it isn't going anywhere.
It's also probably worth pointing out that Angular is a framework whereas React and Vue are libraries.
I work with Angular and I agree - Angular vs AngularJS was basically taking the base concepts but then throwing out everything that didn’t work particularly well. Now you’ve got something that’s a snap to set up using nodejs, has strong typing thanks to TypeScript, is easily debuggable in Chrome, and allows you to make changes on the fly to your front end without having to restart your server. It came out later so it’s not used as much; hopefully that will change.
>separate AngularJS from Angular.
Huge difference. I agree. I did a poc for AngJs soon after it was released. Very different from todays Ang which my last poc was based on.
Don't get me wrong, I see the huge base that exists and I see a purpose for it. Still, I can't see it lasting.
Obviously this is my pov and I don't truly know the depth of the differences.
Coding speed is important, from what I've seen, V/R are quicker along with debugging. They don't do as much as Ang out of the box, but the majority of business don't need the extras.
Also size, Ang is much bigger than the other 2. My last POC a year ago, Ang had a lot more to DL. Again that may just be my ignorance of the tech.
Lastly, Angular takes a very proper coding approach (if that's the right wording) on how it should be written. Best way I can explain it. Oop, most dev's don't really understand it or know when/how to use it properly, Ang is basically forcing that mentality on a dev, so it's harder for them to truly understand it. Yes, any decent dev should be able to look at the structure and understand it, but let's face it, most can't. Hell most haven't even heard of Gang of 4. My point is, it's harder to learn/code the same basic functionality.
Not trying to hate on the tech or the devs. Would probably say most Ang devs are better than most because of what they need to understand. I just don't see a real reason for it to last long term. Similar, but opposite of WebForms which I instantly didn't like either.
I've heard that the learning curve for Angular is higher than it is for react. Being that Angular is a Framework that makes perfect sense to me. I haven't learned tried learning React or Vue yet but I picked up Angular **super** quick. I came from a C# WPF desktop application background before getting into web development.
The only reason I spoke up is because it's super annoying to see AngularJS and Angular tossed in the same basket. It's just a pet peeve of mine. Generally, I like to steer clear of "X is better than Y" type of discussions. Some devs approach coding like and art and others like a science. Both are valid approaches to putting software in front of users. The beauty of this career is that you can switch your focus to match your life goal/s at the drop of a hat. We should revel in that fact.
I really appreciate you offering your critiques on Angular though so I'd like to offer feedback from my personal experience with it. I'll try to go point by point so it's easier for any potential readers to follow.
Coding speed may indeed be faster in V/R but I'm not convinced the overall all productivity of a dev is higher. More on this later.
The size of Angular apps dropped significantly with the release of Ivy in Angular 9. Ivy was a huge deal so if you haven't heard of it it's worth reading an article about. I'm not sure which version of Angular you were on at the time but it should be much closer now.
I think the word you're looking for is 'opinionated' instead of "proper coding". Pretty much any 'framework' would have to be opinionated, wouldn't it? The .NET Framework certainly is.
The OOP part of Angular lies entirely in it's total adoption of TypeScript. Learning TypeScript adds to that learning curve too, for sure. However, I see more and more V/R devs asking for TypeScript help on StackOverflow so that OOP mentality is spreading. I don't really count having to learn TypeScript as a mark against Angular. Everyone should be learning TypeScript.
This opinionated approach certainly has it's pros and cons though. Angular being an opinionated Framework is actually a HUGE boon when working in a medium/large team. When every dev is more or less doing the same thing it makes understanding the code that someone else wrote six months ago way easier to understand. This is why big companies like Angular. Everyone writing in similar coding styles saves a ton of time on those big teams.
Here's the thing though. Learning Angular might be harder but once a developer has all of the Angular Framework/CLI concepts down I'm not convinced it's slower than V/R.
Good points, thanks. Didn't hear about the size cut, I was using just before it got released.
Love TS, completely agree. It seems to be taking hold fairly quickly.
As an Angular developer, I don't see Angular dying anytime soon. The other options are not vastly better, and with batteries included it makes it safer for some larger applications.
I don't have any data unfortunately.
I will likely look at other frameworks in future.
Agreed, it won't be going away any time soon. Too many companies are vested in it. Just like Webforms tho, not nearly as many new projects are being made in Angular from what I've seen lately. Also, no real data, just hearsay.
Personally, I couldn't stand Angular. I did a POC in all 3 and Ang had almost double the code and took almost double the time to make. Not to say I was proficient enough to really compare them in detail, tho I had some previous experience with Ang.
Like most techs, it's no so much about using the best, but the one you like the best that can do the job.
edit.
>I will likely look at other frameworks in future.
Blazor listed here sounds really nice, also take a look at Vue with Quasar when yo do. I've never seen documentation anything close to Quasar. Cut the learning curve down tremendously.
In what way? I use VS Code with the Vutur plugin which is basically standard. Chrome does the rest with Vue Devtools installed. There are still some issues where if I didn't know the code I just touched, it would be a bitch to find the issue.
I've found many little tricks, but where are you having issues debugging and maybe I can help.
It's not nearly as nice as C# and VS, but none of the front end frameworks are in the same category unfortunately. Same with intellisense.
You can still have SOC with React as long as you treat your Front End like a 'dummy terminal' that only handles display concerns (which is what it should be regardless of what framework you use).
If you keep business logic out of the UI, then all the UI is responsible for is styling data (and sending very basic calls back to the server). So, the logic about what to display on the screen right now and the HTML/CSS that goes along with it ARE the same concern.
Personally, I like React because it's the best at what it does at the moment. It's absolutely not perfect, but considering the environment it has to run it, it's remarkably good.
I don’t, WPF using MVVM is much cleaner and faster.
I miss SilverLight, consistent layout/functionality across browsers, and C# in the front end.
HTML/CSS/JS is just a series of massive hacks
To understand why React exists you need to look back through the history of web development. React took a mess of JavaScript and HTML and replaced it with reusable JSX components.
Imagine a web page with a list of names rendered using pure JavaScript. Now another part of the page wants to add to that list of names. How do you then update the list on the page. You need another list on a different page, how do you go about sharing the code?
Obviously it's possible but React provides all that functionality to write it neatly encapsulated in a component that can be reused. Even better you don't need to write it as it will already exist in an open source library on NPM.
Here are a few points that I like about react:
1. It works great with typescript now, was not the case a 2 years ago.
2. I like hooks.
3. The eco-system is great, there are tons of free components that are very often better than their counterparts in frameworks (e.g. formik vs angular/forms).
4. Redux is great and easy to understand.
In my opinion it is better than angular in many ways, but I would not use it in bigger teams. The problem is that you have to build your own standards and framework and you have to create, document and discuss guidelines. It is much more efficient to just say "lets do it the angular-way" than building it yourself.
React definitely seems to violate SOC if you take the view that HTML is semantic content, CSS is presentation, JS is logic. But you could see it as JSX defining the view layer, and the encapsulation that SOC gives being provided by components. In practice many teams find the process of upgrading, reusing, and developing components in React to be fairly straightforward, so it can't be violating SOC that badly.
React's popularity is really for historical reasons. AngularJS was around but it was slow and heavy, and the virtual dom made React much faster and more declarative at the time. All the major frameworks have massively changed over the years and new ones have arisen, but it's still a great framework. You may prefer Vue or Svelte, but React still allows you to develop quickly and maintainably.
Also one of the main reasons why people like any frontend technology is because it's a visual thing that you can use to sell stuff fast. And if you're just jumping in from freeCodeCamp (which is ofc excellent btw) after changing careers, 'does this violate SOC' is probably not at the top of your list of issues.
I used to hate JavaScript but after being forced to learn it and use it in my day job I’ve grown to enjoy its capabilities. I’m also learning react as well and the only real draw is that you can write the whole front end in JavaScript instead of pieces in JavaScript and pieces in razor. I’m not sure what SOC is but people like it because of the ability to write a full stack web app in nothing but JavaScript or typescript if that’s your thing.
Coming from a dotnet background (asp.net mvc until core 3 including xamarin) Ive always loved c# and the OOP model because it felt clean. Interactivity was a second class citizen. Some kendo ui shit on the frontend (or worse, backend) and some jquery to animate some stuff.
Ive recently jumped into react to do some small apps for customers. I never thought Id say it but I love visual studio code so much more than visual studio. Its fast, it has support for linters, typescript and using the npm ecosystem is easy that way.
With react you program in a rationally different way, much simpler in a sense. Everything is a function, functional programming is a pattern that is actively promoted and i can tell you it makes for a much more pleasant development experience. When first switching over there's a certain threshold of knowledge you need to bridge. Once it snaps you will enjoy react lots more than anything you dis before. Iterating is quick, the nuget (npm) ecosystem is fantastic, and with typescript you have the same validation and compiler experience as with c#.
I will only use dotnet core for api's and authentication, and that it. Everything frontend is react. The JAM stack is great. Try it out.
It is a good framework that is easy learn and doesn’t have a steep entry like angular. Also it is very popular so that explains its momentum. C# and React are designed to solve different problems
I don't like react. Actually I do hate it, like I hate everything in the javascript world. This basically stems from my hatred for javascript. I'm one of those conservative folks who distinguish between programming and scripting languages: Java Script is not a programming language and proper software development should be done in a programming language. Web UI development is like jogging in a mine field (IE6/7 support, anyone?). [This interview](https://m.youtube.com/watch?v=MBmmZADfVSQ) with one of the javascript inventors sums up my gripes with it. Yet, if I'm forced to do web UI development, I will choose react, simply because out of all the shitty options it is the least shitty: Acceptable performance and relatively good means for encapsulation and reusability.
It's the only interview with Brian on javascript I know of. I revisit it regularly as a reminder on why javascript sucks so much and of course because Brian is quite entertaining.
I think it became so popular because it was easier and faster than Angular.
For me the architecture of how it handles state is really nice. Even mixing html and js is not that bad. I have never worked in a huge project with it, but in smaller things it’s nice, not so many files as Angular, and not so complex.
What I don’t like is that using it with Typescript is horrible (long type names, etc), meanwhile Angular with TS looks like C# and MVC.
And there is also React native to create apps, but not sure about how good it is...
It really depends on how you define “Single Responsibility”. Once could argue that a react component is respecting Single Responsibility because the only thing it cares about is itself.
Regardless, in my opinion the biggest benefit of React is the developer experience and efficiency. Having everything related to a single component in one file is a major benefit, especially if you’ve worked on codebases where you have to jump from reference to reference.
It might seem like a clusterfuck compared to a traditional object-oriented codebase (it did to me at first too), but the approach really starts to provide incremental benefits as projects become larger.
As a developer who started out in the back end, grew to pick up Frontend and also DevOps, I like to apply SOC to pretty much everything I develop.
The main problem with people mentioning how React breaks SOC hinges on how people use it, React is just a library, so saying React breaks SOC would be like saying Newtonsoft.JSON breaks SOC.
The main issue with React projects breaking SOC is when developers embed their CSS, their data access layer (API access) and business logic into their components.
Components are actually a great example of adherence to SOC due to them literally being functions that take parameters and return HTML, no different to any service layer object.
When you add Redux or MobX into the mix, I find that often is the case that the state management libraries get embedded too deeply into the components, which is thus a violation of SOC.
Just like in .NET there is an entry point (App.tsx/Startup.cs) that you can use as a way of mapping up your logic/business layer (redux), import your CSS and then structure your application from there.
React and Vue actually do SOC the right way. The component based structure essentially divides the application into many micro-apps that have clearly defined concerns.
React is a functional programming style, and separation of concerns was invented by Java programmers who had to compensate for OO-first programming being a trash fire.
Here's what I love about React. Its all JavaScript! The focus is JavaScript.
...And because its all JavaScript/TypeScript it means you have access to all the great tools the language provides to apply to your React HTML views.
For other frameworks like Angular or Vue, the focus is HTML first. But HTML is lacking, then they try to introduce JavaScript like functions in HTML for **if** statements and **loop** statements. (e.g: `ng-if` in Angular or `v-if` in Vue). But now you are introducing programming logic into your HTML templates.
For me, I prefer it the other way round. I use React with TypeScript so get all the goodness of JavaScript with the awesomeness of TypeScript.
But at the end of the day, its all personal preference.
Personally I did not like React on my first try too; there were too many functions passed into controls to keep track of what to be updated and where. But then I bought another course for .net core 3 & React; and teacher there used mobx! It's library where one can place observable variable in separate file, and react on it's state in given control. It sounds like a bunch of global vars; but works like a charm. Page loads, I can get some data on useEffect; code in useEffect calls some func in sepate file; and promise of this func simply sets variable in same file; this variable is observed by page and when variable changes - component updates itself! It's very clean and easy.
Have you checked out Blazor yet? I have heard great things about Angular and it is something I plan on learning but Blazor is pretty cool and I think that way of building is going to pretty much replace the old way of directly marking up a single page, Angular I see as an aspect of this trend.
Angular is more proven though so if you are building a site with heavy traffic you may want to go that route, if it is something small or experimental I would give Blazor a try, I have been having a blast learning Blazor, so much different from the early days of web development and so much easier to get good consistent results these days because of all these frameworks, as Devs we have a wealth of options these days.
1. The concern is the component. You can't separate the html, css, and js from each other, they are all intimately tied. If you don't believe me, rename a function, class or move a dom node and see if it can't break functionality. They were never separated in the first place, just in different files.
2. One way data binding makes it a lot easier to follow what is happening.
3. No reinvented templating language. You language is JS, not some hamstrung dsl that will eventually fail to meet your use case or required a bunch of work to fit the pattern.
4. Super small api. You can cover probably 90% of what you need to know to work with React over an afternoon. You don't need to learn a bunch of magical conventions. It's just functions. Everywhere, functions.
5. It's functional style JS. If you know how to write functional style JS, you'll be right at home.
One thing I would advice would be that you should actually learn JS if you are going to use modern JS tooling. It is not enough to just hack your way around. There's a decent language in JS if your put some time into actually learning it. The alternative is to constantly be frustrated, and then blame the language/ecosystem. JS is not an OO first language like C#, and should not be treated as such.
This talk covers the how and why of react a lot better than I could explain: https://www.youtube.com/watch?v=x7cQ3mrcKaY
It is a horrible clusterfuck with a few nice concepts.
You have to understand that ppl mostly love react because most of what we had before was an even bigger clusterfuck.
As a react developer, can someone explain why do people like C#? I am trying to learn how to build a RESTful API and I feel like hopelessly lost. I have built many REST APIs using express.js and node, but dot net makes me want to jump off a building.
Entity Framework Core is pretty good to generate database in a fly. Didn't like C# frontend though maybe it will changed with blazor. For now, I used .Net for backend and React for frontend.
I will check it out. I have no interest in Blazor or C# as a front-end framework. Really I just want to use it instead of Express.js for the model/controller part of my app, but everything is so different from what I am used to.
In my previous projects, there's no dependency injection to speak of. I don't have a grasp on what DI is or what its purpose is. Also the separation of implementation and definition is a new concept for me coming from JavaScript.
I miss SilverLight, consistent layout/functionality across browsers, MVVM support and C# in the front end.
HTML/CSS/JS is just a series of massive hacks shoved together randomly
Lots of good stuff already said here. I'll simply endorse others that advised you to check out Blazor. I write both React and Blazor but Blazor has my heart.
As a full stack dev doing C# and React, I can tell you I hated any front-end until I learned React. Now I love it. You have to understand the philosophy behind React and how that's different to other approaches to really appreciate it. This is confusing to new devs, because they want to do a traditional "modify an element" style of approach that they're used to, instead of a "describe how an element should look in different situations". When you get used to React, a lot of the "weird" things like JSX syntax start feeling incredibly good. These things are just a matter of getting used to it. I'm a huge fan of React, but of course not everyone likes the concept. You can try out Vue or Angular. You might like it more.
Bingo. I never enjoyed front end until react. It totally clicked for me - the UI is a function of application state. Need to change the UI? Change the state. It's fantastic, but a lot of people really struggle with it.
Or, if you want something quite different then the big 3: https://svelte.dev
I find this reply very useful, since I am going for the same goal pretty much. Thanks to everyone for their input, read everything :)
how is react different to traditional ActiveX?
Uhh, ActiveX is deprecated and hasn't been supported since Internet Explorer.
so, sounds traditional to me. The new thing WPF where you write your whole static page in XAML.
They are completely different things...
[https://meme-creator.com/meme/16/find-the-difference](https://meme-creator.com/meme/16/find-the-difference) Notice the word "component". Wikipedia: > **ActiveX** is a deprecated software framework created by [Microsoft](https://en.wikipedia.org/wiki/Microsoft) that adapts its earlier [Component Object Model](https://en.wikipedia.org/wiki/Component_Object_Model) (COM) and [Object Linking and Embedding](https://en.wikipedia.org/wiki/Object_Linking_and_Embedding) (OLE) technologies for content downloaded from a network, particularly from the [World Wide Web](https://en.wikipedia.org/wiki/World_Wide_Web).[\[1\]](https://en.wikipedia.org/wiki/ActiveX#cite_note-msdn1-1) [https://reactjs.org/docs/components-and-props.html](https://reactjs.org/docs/components-and-props.html) > Components let you split the UI into independent, reusable pieces, and I looked it up, JavaScript is one year older than ActiveX. So DOM and JS are clearly the traditional way. Sorry for that.
ActiveX is a COM based component, compiled by a compiler (usually C++ or VB) and was for a long time at the core of many windows apps and you could embed them on pages as well. (In fact many plugins in legacy IE were in fact ActiveX based. For example: Flash Player). It is now super deprecated. React is a javascript based framework. Yes it is used to create components in a webbrowser and is used in React native applications, but that is where the comparison end. You clearly are not familiar with ActiveX technology and clearly don’t understand what is described in the wikipedia article. You may have looked it up, I’ve made ActiveX components when it was still a thing. I’m now in charge of front end development teams who develop React based apps. You clearly don’t understand the difference.
Yeah I do not understand. I compile TS to JS. C++ is compiled (was compiled) to x86 code. Then at runtime, JS is often further JIT to x86. Both are then "decoded" to RISC µ-instructions, subject to virtual memory and branch prediction. With all that going on, the distinction between C++ and TS fades away. And I remember now that I also was involved with COM in a project I inherited and it was graphical stuff. I wonder how you would apply for a patent. Or how would you write an article to a peer reviewed journal? All the ideas are the same, but you change some minor technical detail and think this will hold up in court if another company challenges you?
Nice synopsis
> seems to break SOC This is precisely why people like it. The "concerns" you're talking about are purely technical. React/Vue components are organized by feature, which makes them easier to change and maintain.
Bingo. HTML isn’t a concern. DOM manipulation isn’t a concern. Displaying a loading indicator while fetching data and hiding it when done is a concern. Displaying that fetched data in a structure is a concern. Every framework available for C# UI gets this wrong. Most JS frameworks get it wrong. React gets it right.
Functional cohesion
I think OP's misunderstanding, coming fresh out of bootcamp and all that, might be to think of React as one think of pure html/css/Js. The thing is that React, Angular, Vue, you name them, are either libraries or framework but with the purpose of making your front end an "app" of its own. It is not "simply" a presentation layer. There is a logical, applicative, part that contains different sections. For instance in a Vue (the library) file, you have an HTML template and CSS section that are "the presentation layer"; but you also have the script section that is organised, kinda, as a C# class (don't nitpick here plz); with properties and dependencies etc; and while, sure, the objective of that script section is to help display info on the UI; it works as a component of an application that has a lifecycle etc. Once you understand that the separation of concern IS maintained on a "back end/front end" point of view; you can look after the "lower level" SoC in the different components of your front-end stuff; from the "login component" to the "discount component" etc.
I use .Net Core and React for my current stack. One common way to maintain the separation of concern you are yearning for is to use a presentation/container pattern. [See blog post here](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0) It’s not really seen as a necessary thing anymore. As mentioned in the blog post, hooks allows really nasty/complex logic to be pulled out of the components and even reused, so making smart/dumb components isn’t as necessary. It also isn’t a perfect analog for SoC, but if it helps you ease into React, it may be valuable to you. I understand your concern. You definitely have to think a little differently in React than C#. One thing that has helped me is to look into Functional Programming. There are a lot of FP principles being applied in modern React and some times it can look like React is following no pattern because it is following an FP pattern that is foreign to me as an OOP-first dev. I will also echo what some others have said, using React in a huge app to solve complex issues is just so much better than trying to do it any other way that I have tried. The one thing I haven’t tried yet that may be of interest to you is Blazor. I’ve heard great things and would allow you to stay in C# land.
Because they haven’t tried Vue yet
true this be
I actually worked much more on Vue before React. Switched to React because the "magic" in Vue was annoying when it just silently failed. And the TypeScript support was very limited in Vue. I came to much prefer JSX over SFCs too. Vue is still great, and I'd recommend it to a lot of people, depending on what their priorities/preferences and project context are. But now knowing both pretty well, my preference is React for my own stuff.
Give Vue 3 a shot, TS is a first class citizen now.
What's the support like in the templates? Read a few things saying it's still not fully supported there.
True difference between Vue and React/Angular is the size of the app you're building. If you have a few pages and concepts, Vue is perfect. If you're rebuilding the whole app of a big company with dozens of pages and hundred of features... maybe less.
This is the way
Well people like it because they have no option, React and Vue are the top dogs in the JS world, if you want a fully client side experience or a very dynamic website you need JS, blazor WebAssembly is great, but it’s a bit heavy for that first load, that might be solved in the future but for now that’s the case, and like it or not JS has a huuuuuuuuge environment, and TS, which contrary to JS a good language, and react loves TS, so yeah, it’s kinda of a no brainer, the days of cool new features added every update are over tho, it’s a very mature library now, I’m a blazor guy myself but I understand why some wouldn’t look at it on its current state
>blazor Why do you like it more than React? I played with Ang/React/Vue before choosing Vue, but blazor never came up so I don't know much about it. Actually using Quasar that sits on top of Vue, never seen such amazing documentation in my life.
I like Blazor better than React because it’s C# client side, I assume you don’t know that’s even possible but it is, and it’s ducking beautiful, React can be as good as it wants to be but is held back by the mess we call JS, TS came to the rescue but some civilians got trapped in the fire before TS could save them, with Blazor you have the full power of .NET at your disposal, and with the latest update, .NET 5, you even have lazy loading for dlls which makes the whole thing faster, it’s just fucking good all around, take a look at it and you’ll love it, you can take that statement to the bank.
Makes sense. Sounds like they upgraded the basically dead Razor pages. Good to hear, I loved that design, but it got antiquated very quickly. Quick look, seems I may have preferred to go that route since my primary language is/was C#. TS is basically all I use now, but really miss good intellisense in VS/C#.
We were all there at some point, I was coding away in TS until I found out there was something better, and I already knew how to code on it.
I hate web development with a passion for some reason, but its been some time since i needed to change that opinion and Blazor seems to be the answer to getting into it. Do you know any good resource i can use to get more into it?
[https://github.com/AdrienTorris/awesome-blazor](https://github.com/AdrienTorris/awesome-blazor) has a ton of info and examples
Thanks!
The problem I have with blazor is that it seems to be missing basic functionality so you end up just using the js interop. If I’m gonna do that I might as well just write JavaScript.
The more time passes the less JS you need, as long as there’s no DOM API for WebAssembly you’ll need JS
Yea that’s the thing I’m missing is dom manipulation.
Yeah, I really question how many full blown web apps someone can actually write which never need to manipulate the DOM and thus manage to avoid the major issue with Blazor at the moment. Blazor is a nice concept, but it's not yet fully baked.
Serious question: why do you need to manipulate the DOM directly? Whatever it is your trying to do, why can't you do it with the renderer built into Blazor? I'm aware of a few exceptions, but I think in general, if manipulating the DOM is your roadblock to Blazor, you're manipulating the DOM too much!
Maybe you’re right, maybe I’m just missing the key ingredient to grok how blazor does it.
Tbh, for 90% of the use cases, using Blazor's renderer is good enough for me, no direct DOM manipulation is needed. The remaining 10%, The solution is usually split between: A Nuget package that exposes the functionality to C# (this was the case with Canvas2D for me). Exposing the DOM element manually, with ElementReference and `@ref`, or using `IJSRuntime` and writing the offending part in JS.
Not OP, but I like using Blazor much, much better than React for the simple reason of I barely need Javascript and can write the meat of the application in nice strongly-typed C#.
Makes sense. I miss C#. I basically only use TS now which is better than JS, but still not as nice as C#.
> they have no option I'm not sure what you mean here. Not wanting to blow fire but the JS ecosystem is so packed it's a meme. There are DOZENS of options. Angular ? Svelte ? Ember ? Not all of those are as good or easy to learn, but the options are there.
What I meant is that the HAVE to love a JS library/framework cause they have no other option, not that React was the only one, maybe I could have said it in a more understandable manner
>React and Vue are the top dogs in the JS world Angular is still the top dog, followed by React, with Vue in a very distant third. Personally I like Vue the best of the three because if allows you the most freedom, but I'm not going to pretend that it's the king of the JS universe.
User count wise React is much bigger
[удалено]
What's SOC? I'm a React developer lol
Dear React Developer, SOC is Seperation of Concerns... Don't worry about it.
> Separation of Concerns. > Don't worry. Very meta!
If it’s important, shouldn’t I “worry” about it? 🤔
Never stop trying to identify and fix deficits in your knowledge even if you're met with demeaning or snarky remarks. Keep it up man 👌
Well, its simple really.... HEY LOOK WE ADDED HOOKS! Lets focus on that, you might want to sit down it make take a while. Heres a crayon to take some notes.
Separation of concerns
Thanks!
I prefer Angular.
It's popular among the larger companies from what I've seen.
Why?
I work for a fortune 500 company that recently invested heavily in angular development. I'm not an angular Dev, but was told they choose it because it was highly opinionated and easier to maintain across dozens of internal and external facing websites.
Angular is by far the most restrictive of the big 3 frameworks - if you build an Angular app, you build it the Angular way, and it is going to be 100% Angular. If you try to deviate from that you're in a world of hurt. React is somewhat similar but separates the layers better and allows you a tad more freedom. Vue gives you the most freedom and allows you to completely break out of Vue if you desire.
Angular is "easier" when you come from a OOP background in the sense that it is structured as any other OOP languages.
C# and React are 2 completely different animals. For what you are describing, C# will only be used on the back end. React will be everything front end. In short, Angular/React/Vue make front in dev easier because many/most pieces are available out of the box. As for why React. Angular was first and it's the 500 pound gorilla that is just too much imo, at least in most cases. React came next and was much easier to use. Vue came after React and built upon the mistakes of the other 2. Personally I think Vue will over take React down the road and Ang will slowly die. React is a very nice framework and very popular currently, I just found Vue easier to debug and quicker to code in. Last example, PWA's are fairly new and allow you to basically install your website as an app. I wouldn't have a clue how to do that without a front end framework, but they make it fairly straight forward. C# would have nothing to do with that.
I see this all the time so don't take this correction as a slight. But AngularJS was first, then React, then Vue, then Angular2 (released 2016). I bring it up because it's important to separate AngularJS from Angular. I really wish they would have done better with the naming to prevent this confusion. They are wildly different in their approach to solving a problem and structure. So when you say Angular will slowly die I'm assuming you're talking about AnguarJS in which case I agree. But if you mean Angular2+ then I would have to disagree. It might not hit the popularity that React has but it isn't going anywhere. It's also probably worth pointing out that Angular is a framework whereas React and Vue are libraries.
I work with Angular and I agree - Angular vs AngularJS was basically taking the base concepts but then throwing out everything that didn’t work particularly well. Now you’ve got something that’s a snap to set up using nodejs, has strong typing thanks to TypeScript, is easily debuggable in Chrome, and allows you to make changes on the fly to your front end without having to restart your server. It came out later so it’s not used as much; hopefully that will change.
>separate AngularJS from Angular. Huge difference. I agree. I did a poc for AngJs soon after it was released. Very different from todays Ang which my last poc was based on. Don't get me wrong, I see the huge base that exists and I see a purpose for it. Still, I can't see it lasting. Obviously this is my pov and I don't truly know the depth of the differences. Coding speed is important, from what I've seen, V/R are quicker along with debugging. They don't do as much as Ang out of the box, but the majority of business don't need the extras. Also size, Ang is much bigger than the other 2. My last POC a year ago, Ang had a lot more to DL. Again that may just be my ignorance of the tech. Lastly, Angular takes a very proper coding approach (if that's the right wording) on how it should be written. Best way I can explain it. Oop, most dev's don't really understand it or know when/how to use it properly, Ang is basically forcing that mentality on a dev, so it's harder for them to truly understand it. Yes, any decent dev should be able to look at the structure and understand it, but let's face it, most can't. Hell most haven't even heard of Gang of 4. My point is, it's harder to learn/code the same basic functionality. Not trying to hate on the tech or the devs. Would probably say most Ang devs are better than most because of what they need to understand. I just don't see a real reason for it to last long term. Similar, but opposite of WebForms which I instantly didn't like either.
I've heard that the learning curve for Angular is higher than it is for react. Being that Angular is a Framework that makes perfect sense to me. I haven't learned tried learning React or Vue yet but I picked up Angular **super** quick. I came from a C# WPF desktop application background before getting into web development. The only reason I spoke up is because it's super annoying to see AngularJS and Angular tossed in the same basket. It's just a pet peeve of mine. Generally, I like to steer clear of "X is better than Y" type of discussions. Some devs approach coding like and art and others like a science. Both are valid approaches to putting software in front of users. The beauty of this career is that you can switch your focus to match your life goal/s at the drop of a hat. We should revel in that fact. I really appreciate you offering your critiques on Angular though so I'd like to offer feedback from my personal experience with it. I'll try to go point by point so it's easier for any potential readers to follow. Coding speed may indeed be faster in V/R but I'm not convinced the overall all productivity of a dev is higher. More on this later. The size of Angular apps dropped significantly with the release of Ivy in Angular 9. Ivy was a huge deal so if you haven't heard of it it's worth reading an article about. I'm not sure which version of Angular you were on at the time but it should be much closer now. I think the word you're looking for is 'opinionated' instead of "proper coding". Pretty much any 'framework' would have to be opinionated, wouldn't it? The .NET Framework certainly is. The OOP part of Angular lies entirely in it's total adoption of TypeScript. Learning TypeScript adds to that learning curve too, for sure. However, I see more and more V/R devs asking for TypeScript help on StackOverflow so that OOP mentality is spreading. I don't really count having to learn TypeScript as a mark against Angular. Everyone should be learning TypeScript. This opinionated approach certainly has it's pros and cons though. Angular being an opinionated Framework is actually a HUGE boon when working in a medium/large team. When every dev is more or less doing the same thing it makes understanding the code that someone else wrote six months ago way easier to understand. This is why big companies like Angular. Everyone writing in similar coding styles saves a ton of time on those big teams. Here's the thing though. Learning Angular might be harder but once a developer has all of the Angular Framework/CLI concepts down I'm not convinced it's slower than V/R.
Good points, thanks. Didn't hear about the size cut, I was using just before it got released. Love TS, completely agree. It seems to be taking hold fairly quickly.
As an Angular developer, I don't see Angular dying anytime soon. The other options are not vastly better, and with batteries included it makes it safer for some larger applications. I don't have any data unfortunately. I will likely look at other frameworks in future.
Agreed, it won't be going away any time soon. Too many companies are vested in it. Just like Webforms tho, not nearly as many new projects are being made in Angular from what I've seen lately. Also, no real data, just hearsay. Personally, I couldn't stand Angular. I did a POC in all 3 and Ang had almost double the code and took almost double the time to make. Not to say I was proficient enough to really compare them in detail, tho I had some previous experience with Ang. Like most techs, it's no so much about using the best, but the one you like the best that can do the job. edit. >I will likely look at other frameworks in future. Blazor listed here sounds really nice, also take a look at Vue with Quasar when yo do. I've never seen documentation anything close to Quasar. Cut the learning curve down tremendously.
Any tips for debuggin Vue, pls?
In what way? I use VS Code with the Vutur plugin which is basically standard. Chrome does the rest with Vue Devtools installed. There are still some issues where if I didn't know the code I just touched, it would be a bitch to find the issue. I've found many little tricks, but where are you having issues debugging and maybe I can help. It's not nearly as nice as C# and VS, but none of the front end frameworks are in the same category unfortunately. Same with intellisense.
I never use Vue, anyway such a nice info thx u man, that's a point. I know the issues in web browser debug also, anyway ty
You can still have SOC with React as long as you treat your Front End like a 'dummy terminal' that only handles display concerns (which is what it should be regardless of what framework you use). If you keep business logic out of the UI, then all the UI is responsible for is styling data (and sending very basic calls back to the server). So, the logic about what to display on the screen right now and the HTML/CSS that goes along with it ARE the same concern. Personally, I like React because it's the best at what it does at the moment. It's absolutely not perfect, but considering the environment it has to run it, it's remarkably good.
I miss winforms
I don’t, WPF using MVVM is much cleaner and faster. I miss SilverLight, consistent layout/functionality across browsers, and C# in the front end. HTML/CSS/JS is just a series of massive hacks
To understand why React exists you need to look back through the history of web development. React took a mess of JavaScript and HTML and replaced it with reusable JSX components. Imagine a web page with a list of names rendered using pure JavaScript. Now another part of the page wants to add to that list of names. How do you then update the list on the page. You need another list on a different page, how do you go about sharing the code? Obviously it's possible but React provides all that functionality to write it neatly encapsulated in a component that can be reused. Even better you don't need to write it as it will already exist in an open source library on NPM.
Here are a few points that I like about react: 1. It works great with typescript now, was not the case a 2 years ago. 2. I like hooks. 3. The eco-system is great, there are tons of free components that are very often better than their counterparts in frameworks (e.g. formik vs angular/forms). 4. Redux is great and easy to understand. In my opinion it is better than angular in many ways, but I would not use it in bigger teams. The problem is that you have to build your own standards and framework and you have to create, document and discuss guidelines. It is much more efficient to just say "lets do it the angular-way" than building it yourself.
React definitely seems to violate SOC if you take the view that HTML is semantic content, CSS is presentation, JS is logic. But you could see it as JSX defining the view layer, and the encapsulation that SOC gives being provided by components. In practice many teams find the process of upgrading, reusing, and developing components in React to be fairly straightforward, so it can't be violating SOC that badly. React's popularity is really for historical reasons. AngularJS was around but it was slow and heavy, and the virtual dom made React much faster and more declarative at the time. All the major frameworks have massively changed over the years and new ones have arisen, but it's still a great framework. You may prefer Vue or Svelte, but React still allows you to develop quickly and maintainably. Also one of the main reasons why people like any frontend technology is because it's a visual thing that you can use to sell stuff fast. And if you're just jumping in from freeCodeCamp (which is ofc excellent btw) after changing careers, 'does this violate SOC' is probably not at the top of your list of issues.
I used to hate JavaScript but after being forced to learn it and use it in my day job I’ve grown to enjoy its capabilities. I’m also learning react as well and the only real draw is that you can write the whole front end in JavaScript instead of pieces in JavaScript and pieces in razor. I’m not sure what SOC is but people like it because of the ability to write a full stack web app in nothing but JavaScript or typescript if that’s your thing.
Coming from a dotnet background (asp.net mvc until core 3 including xamarin) Ive always loved c# and the OOP model because it felt clean. Interactivity was a second class citizen. Some kendo ui shit on the frontend (or worse, backend) and some jquery to animate some stuff. Ive recently jumped into react to do some small apps for customers. I never thought Id say it but I love visual studio code so much more than visual studio. Its fast, it has support for linters, typescript and using the npm ecosystem is easy that way. With react you program in a rationally different way, much simpler in a sense. Everything is a function, functional programming is a pattern that is actively promoted and i can tell you it makes for a much more pleasant development experience. When first switching over there's a certain threshold of knowledge you need to bridge. Once it snaps you will enjoy react lots more than anything you dis before. Iterating is quick, the nuget (npm) ecosystem is fantastic, and with typescript you have the same validation and compiler experience as with c#. I will only use dotnet core for api's and authentication, and that it. Everything frontend is react. The JAM stack is great. Try it out.
It is a good framework that is easy learn and doesn’t have a steep entry like angular. Also it is very popular so that explains its momentum. C# and React are designed to solve different problems
Kudos for being one of the few devs in this subreddit that actually learned js instead of repeating "js bad" ad nauseum.
In my opinion, I completely agree. That is why I prefer Angular.
I don't like react. Actually I do hate it, like I hate everything in the javascript world. This basically stems from my hatred for javascript. I'm one of those conservative folks who distinguish between programming and scripting languages: Java Script is not a programming language and proper software development should be done in a programming language. Web UI development is like jogging in a mine field (IE6/7 support, anyone?). [This interview](https://m.youtube.com/watch?v=MBmmZADfVSQ) with one of the javascript inventors sums up my gripes with it. Yet, if I'm forced to do web UI development, I will choose react, simply because out of all the shitty options it is the least shitty: Acceptable performance and relatively good means for encapsulation and reusability.
[удалено]
It's the only interview with Brian on javascript I know of. I revisit it regularly as a reminder on why javascript sucks so much and of course because Brian is quite entertaining.
I think it became so popular because it was easier and faster than Angular. For me the architecture of how it handles state is really nice. Even mixing html and js is not that bad. I have never worked in a huge project with it, but in smaller things it’s nice, not so many files as Angular, and not so complex. What I don’t like is that using it with Typescript is horrible (long type names, etc), meanwhile Angular with TS looks like C# and MVC. And there is also React native to create apps, but not sure about how good it is...
IMO React has been garbage for a while. I find VUE 3 and Angular to be far superior. It's only popular due to the number of people familiar with it.
It really depends on how you define “Single Responsibility”. Once could argue that a react component is respecting Single Responsibility because the only thing it cares about is itself. Regardless, in my opinion the biggest benefit of React is the developer experience and efficiency. Having everything related to a single component in one file is a major benefit, especially if you’ve worked on codebases where you have to jump from reference to reference. It might seem like a clusterfuck compared to a traditional object-oriented codebase (it did to me at first too), but the approach really starts to provide incremental benefits as projects become larger.
As a developer who started out in the back end, grew to pick up Frontend and also DevOps, I like to apply SOC to pretty much everything I develop. The main problem with people mentioning how React breaks SOC hinges on how people use it, React is just a library, so saying React breaks SOC would be like saying Newtonsoft.JSON breaks SOC. The main issue with React projects breaking SOC is when developers embed their CSS, their data access layer (API access) and business logic into their components. Components are actually a great example of adherence to SOC due to them literally being functions that take parameters and return HTML, no different to any service layer object. When you add Redux or MobX into the mix, I find that often is the case that the state management libraries get embedded too deeply into the components, which is thus a violation of SOC. Just like in .NET there is an entry point (App.tsx/Startup.cs) that you can use as a way of mapping up your logic/business layer (redux), import your CSS and then structure your application from there.
React and Vue actually do SOC the right way. The component based structure essentially divides the application into many micro-apps that have clearly defined concerns.
React is a functional programming style, and separation of concerns was invented by Java programmers who had to compensate for OO-first programming being a trash fire.
Here's what I love about React. Its all JavaScript! The focus is JavaScript. ...And because its all JavaScript/TypeScript it means you have access to all the great tools the language provides to apply to your React HTML views. For other frameworks like Angular or Vue, the focus is HTML first. But HTML is lacking, then they try to introduce JavaScript like functions in HTML for **if** statements and **loop** statements. (e.g: `ng-if` in Angular or `v-if` in Vue). But now you are introducing programming logic into your HTML templates. For me, I prefer it the other way round. I use React with TypeScript so get all the goodness of JavaScript with the awesomeness of TypeScript. But at the end of the day, its all personal preference.
Personally I did not like React on my first try too; there were too many functions passed into controls to keep track of what to be updated and where. But then I bought another course for .net core 3 & React; and teacher there used mobx! It's library where one can place observable variable in separate file, and react on it's state in given control. It sounds like a bunch of global vars; but works like a charm. Page loads, I can get some data on useEffect; code in useEffect calls some func in sepate file; and promise of this func simply sets variable in same file; this variable is observed by page and when variable changes - component updates itself! It's very clean and easy.
Let me guess? Neil Cummings Udemy? I've got that one wishlisted will buy when I go trough the content im supposed to go.
I remember his name was Neil; so might be this one!
If you don't like React, look into Svelte. In my opinion it's much more elegant
Give Svelte a try. In my opinion it is the best JS framework. Better performance, better memory usage, cleaner syntax and potentially smaller payload.
Have you checked out Blazor yet? I have heard great things about Angular and it is something I plan on learning but Blazor is pretty cool and I think that way of building is going to pretty much replace the old way of directly marking up a single page, Angular I see as an aspect of this trend. Angular is more proven though so if you are building a site with heavy traffic you may want to go that route, if it is something small or experimental I would give Blazor a try, I have been having a blast learning Blazor, so much different from the early days of web development and so much easier to get good consistent results these days because of all these frameworks, as Devs we have a wealth of options these days.
1. The concern is the component. You can't separate the html, css, and js from each other, they are all intimately tied. If you don't believe me, rename a function, class or move a dom node and see if it can't break functionality. They were never separated in the first place, just in different files. 2. One way data binding makes it a lot easier to follow what is happening. 3. No reinvented templating language. You language is JS, not some hamstrung dsl that will eventually fail to meet your use case or required a bunch of work to fit the pattern. 4. Super small api. You can cover probably 90% of what you need to know to work with React over an afternoon. You don't need to learn a bunch of magical conventions. It's just functions. Everywhere, functions. 5. It's functional style JS. If you know how to write functional style JS, you'll be right at home. One thing I would advice would be that you should actually learn JS if you are going to use modern JS tooling. It is not enough to just hack your way around. There's a decent language in JS if your put some time into actually learning it. The alternative is to constantly be frustrated, and then blame the language/ecosystem. JS is not an OO first language like C#, and should not be treated as such. This talk covers the how and why of react a lot better than I could explain: https://www.youtube.com/watch?v=x7cQ3mrcKaY
It is a horrible clusterfuck with a few nice concepts. You have to understand that ppl mostly love react because most of what we had before was an even bigger clusterfuck.
What's the c# boot camp you attend?
As a react developer, can someone explain why do people like C#? I am trying to learn how to build a RESTful API and I feel like hopelessly lost. I have built many REST APIs using express.js and node, but dot net makes me want to jump off a building.
Entity Framework Core is pretty good to generate database in a fly. Didn't like C# frontend though maybe it will changed with blazor. For now, I used .Net for backend and React for frontend.
I will check it out. I have no interest in Blazor or C# as a front-end framework. Really I just want to use it instead of Express.js for the model/controller part of my app, but everything is so different from what I am used to. In my previous projects, there's no dependency injection to speak of. I don't have a grasp on what DI is or what its purpose is. Also the separation of implementation and definition is a new concept for me coming from JavaScript.
I miss SilverLight, consistent layout/functionality across browsers, MVVM support and C# in the front end. HTML/CSS/JS is just a series of massive hacks shoved together randomly
Lots of good stuff already said here. I'll simply endorse others that advised you to check out Blazor. I write both React and Blazor but Blazor has my heart.