Everyone wants to extend their knowledge of favourite technology. I am going to be a full stack dev in the future. Backend frameworks are quite well understood by me already. Things like ASP.NET MVC or .NET Core. Database connection covered by EF6. A little about azure components - app services, web jobs, etc. Now I am learning about js basics and I want to know what should I focus on later?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (15)
Based on my current job search, I'd say Angular mixed with .NET web services is rather popular right now. This might change since front end frameworks are fickle. If you know Javascript basics along with some Typescript and JQuery you should be able to adapt to sudden but inevitable changes.
Learning HTML5 and CSS3 will be helpful and that's more framework independent.
On EF, I'd echo the recommendation to learn more about what goes on in the DB. There will be times when EF will fail you, most often when you have to deal with legacy data. Dapper or even a lighter weight data-to-object mapping system might be the better choice.
Azure and AWS are popular right now. The same seems to be true of NoSQL DB's like Hadoop. However, the implementation of them seems to be a bit unsettled so far. Everybody wants to use them but most don't seem to have a good plan behind the idea.
If EF6 is has been the primary way for you to access the database then in the long run it might be worth learning about SQL and performance.
Use the index Luke is a great resource for that. It'll teach you to configure your database indexes such that your EF generated queries perform well.
I am quite familiar with mssql also, but thanks. I will consider this training shortly :)
Look into F# and Fable+elmish for front-end work. Fable is a F#-to-JS cross-compiler, and the elmish "framework" is Model-View-Update. MVU is great because there's not much to it, and most of the code you write is your own functions and data instead of being heavily entangled with framework abstractions. I haven't used Fable/Elmish yet, since I was already using Elm, upon which it is based.
I despise ORMs (including EF). However, I do highly recommend Dapper. It is a "micro-ORM", basically just a row-to-object mapper. It's really fast.
Would you care to elaborate? For the record: I don't wish to start a pro or anti discussion.
It is one of those things I've invested in heavily and later been bitten by its constraints.
Where an ORM really pays for itself is loading/saving nested object graphs that are represented by multiple tables with FK relationships. However, I can usually load/save the same object graph as a document (e.g. JSON-serialized) just as easily and without all the extra ORM tooling.
This is about as complicated as I make database access nowadays. Plus a few more features around performance (run multiple queries at once to avoid round trips, unbuffered reads for large result sets, etc).
But our app is designed to support that. I can save an entity both as a document for viewing/editing purposes, and also save some of the information in a flat table along with a full-text search column for listing/searching.
Thanks for sharing your view and the article :)
I like how your tooling is lightweight and simply using sql.
I am aware of dapper and in my company we already use it in our system.
Do you have any starting point for those F-things. If not, I suppose, that best place to start is pluralsight or something similar?
I learned a lot from F# for Fun and Profit on the language itself.
Most of the F# courses you find on Pluralsight will be on the server-side. Check out some courses by Mark Seemann. Probably a lot of good ones out there, but I'm familiar with his work from his blog and videos.
I can't immediately point to a Fable-Elmish (front-end) tutorial since Fable hit 1.0. There are some older ones for 0.8, but the setup is a little different. However, the fable-elmish github provides a brief overview and some sample applications. AFAIK, when you see React mentioned, it is for the DOM rendering engine not the full React framework.
I was in the same boat. I found it easier to learn a TypeScript friendly JS frameworks first.
I first learnt Ionic (because I had to), and then learnt VueJS with TypeScript. Currently experimenting with Angular which is very similar to Ionic (since Ionic is build on Angular).
In general I prefer to learn a framework and then learn the language.
While react is on my radar, I've always had the feeling I'll get around doing it someday, so I've been trying to stay away from it while I can.
If you're looking for more .NET stuff to learn, I highly suggest getting at least a basic knowledge of Dependency Injection, Inversion of Control, and Mocking frameworks. This knowledge is invaluable if you ever need to write a large, loosely coupled, and testable application. More specifically, I would suggest looking at a combination of Autofac, Moq, and NUnit. It's very easy to get started with these tools and get a Proof of Concept up in running in less than 30 mins. They are all available on Nuget.
If you're looking into more "frontend" stuff and less .NET focused, I'd say at this point it's worth dabbling in the "big" frontend frameworks such as React and Angular 2 (don't bother with 1.0). These will continue to dominate for many years to come.
Anyway thanks :)
I'd suggest learning something completely different. A front-end thing like Angular (Microsoft seems to like it) or React, or something in the DevOps space (albeit it'll probably be more Linux-centric) like Chef/Puppet, Ansible.
We are talking about OOP do you know OOP? Do you know extract a class not a .cs file. First you need to learn other concepts. If you learned this concepts first this other things are easy. And yes, .NET rock !!!
Fire up Visual Studio for Mac and start coding. Deploy your stuff on Linux. Learn the key parts of DotNetCore. Then you never need to go near a JVM again.