Google AngularJS Framework - Worth the risk? - c#

I have been asked to build a small web application for one of our clients and think it might be a good opportunity to try out a different framework for building web applications. Most of the applications we build are based on asp.net web forms and we have no yet done anything in an MVC architecture but I am eager to start building web applications in a more structured manner with the right tools.
I have been researching things like asp.net MVC and the likes which look quite good but I am wondering is there anything to be said for using something like the Google AngularJS Framework.
If possible I would still like to be able to write my server side code using c# and I have not researched AngularJS enough to know if this is even possible, although I assume I could use web services.
Has anyone had any experience with developing an app using AngularJS and if so, how was it and can you point me in the right direction for some tutorials?

We have been developing a port of a Swing fat-client application in AngularJS for the last couple of months and I think it is worth recommending. As far as learning resources go, check out the official project site (and be sure to read the tutorial) and the mailing list (the authors are very helpful).
The good stuff:
great testability
the two-way data binding is a very powerful feature, and it can be extremely helpful once you "get it"
IMO the AngularJS templates are much less brittle than using data- attributes or "special" CSS classes to mark elements that do something
it greatly reduces the need for using jquery plugins, because implementing that functionality in AngularJS is very easy (stuff like trees, tabs, accordions, etc.)
The bad stuff:
the learning curve seems pretty steep (I didn't have much of a problem, but I've seen some people struggle with it)
validations in AngularJS suck for the time being (a new implementation is on the way)
not all libraries/jquery plugins play nicely with Angular and usually you have to wrap them
the API is still being polished, so expect breaking changes (not a big problem with frequent releases and very good changelog, though)
performance is OK up until several thousand bindings on a page - most of the time this is not a limitation, but there are cases when this could be a problem.
Some pointers (if you ever decide to learn AngularJS):
some people really overuse widgets. In my experience, it's much better to use HTML "partials" + services, and only use widgets sporadically.
read source code of the library - it's the best place to learn stuff about angular
no DOM manipulation in services/controllers
if you use css classes to bind to events, you are doing it wrong

+1 #psycho's answer
AngularJS is client-side framework, so you can use any language on the server. It's designed to work well together with jQuery, with big emphasis on testing...
Here are some resources you might find useful:
TUTORIAL: http://docs.angularjs.org/#!/tutorial
API DOCS: http://docs.angularjs.org/#!/api
Developer Guide: http://docs.angularjs.org/#!/guide
Some example apps:
http://cburgdorf.github.com/angular-todo-app
http://www.fluid.ie/angular/calculate/
http://hookercookerman.github.com/angularjs-todos/
http://paul-hammant.github.com/StoryNavigator/navigator.html
Adapter for SenchaTouch: https://github.com/tigbro/sencha-touch-angular-adapter
Adapter for jQ Mobile: https://github.com/tigbro/jquery-mobile-angular-adapter
Feel free to ask any question on mailing list !
We are still in beta, but there are already several internal apps at Google, powered by AngularJS.
UPDATE (26th July 2012):
AngularJS v1.0 has been released.
For some public AngularJS-powered apps, check out http://builtwith.angularjs.org

IMHO developing something for a client which they may have difficulty supporting is unprofessional. You have to bear in mind that it will be difficult for your client to hire experienced Angular professionals, or train their own people to climb that "steep learning curve". Also, so far the documentation is not that great. Can you easily, in a few moments, answer the question, "How can I connect my shiny Angular app to my client's database?" Can your client sometime in the future easily grab some existing code and adapt it to their potential future needs? Be honest.
Compare plain old reliable LAMP development to Angular. For a "small web application" I really believe that a professional should give his client something maintainable and simple.
It's not to say that Angular isn't cool and sexy etc etc. But you have your client's future maintainability to think about in addition to the latest framework fad. Tread lightly would be my recommendation. Build your own website with Angular first and see what you think before you bestow your fabulous new skills on some trusting client.

I remember reading this SO thread couple of months back with same question in my mind, and we decided to go ahead with AngularJS, and the best decision we made on this project yet.
We are using AngularJS + ASP.NET MVC4 REST WebAPI.
Most probalbly after such a nice client side Javascript MVC framework, you would only need REST API layer interacting with Business Logic Layer at server side, and no MVC at server Side (ASP.NET MVC/Spring/Structs would feel like old memories).
You will find Angular-UI good add-on (esp ng-grid)
Soon after our project finishes, we might put some of our directive we wrote for open source world.

I have been researching the merits of AngularJS for many months to utilize as a core framework for product I am creating.
There are many aspects of AJS that make it worth while to learn. Yes there is a bit of a learning curve but its well worth it, especially if you wish to have more control on client side capability.
JQuery manipulates the DOM at run time, whereas AJS situates itself within the JS rendering lifecycle. This allows you to teach the DOM new tricks by creating your HTML Elements and Attributes. This is very, very powerful. As what you are able to do is introduce new Element behaviors for whatever your purpose and need. In AJS these custom HTML Attributes/Elements are called Directives. With the ability to craft your own Directives, you are able to build functionality that the current HTML doesn't have, pushing out capabilities that will run on all modern browsers now and into the future. Of the many approaches to inducing new behavior, AJS appears to be the safest direction one could take due to how they have chosen to implement it.
There is a huge performance gain over JQuery in AJS.
I love the simplicity of the two-way data binding, and the separation of concerns in their client side MVC pattern, which as pointed out above provide great testability. There scope object is the glue between the View (HTML), the Model (your Data) and your custom Controllers. The scope provides access to parent attributes and can be isolated at the sibling level, which is important for some reusable templates.
Templates can created and reused across your application which can contain 0 or more custom directives.
I have been using frameworks such as PRISM and MEF but I am finding that AJS has most of the same features that exist in these .NET frameworks but in a 29K footprint. There is rumors that they are working on lazy-loading which if provided will provide for some very interesting LOB type capabilities.
There are a number of UI frameworks that are being built for AJS but you can wrap any 3rd party control lib as needed, given a bit of effort. The trick is to ensure that when these 3rd party controls have changes induced, that you ensure AJS is properly notified using their apply method.
If you combine AJS with MS TypeScript within VS 2012, it provides the ability to manage and build some very impressive projects which will work well for those who are more comfortable with projects within VS.
There are a ton of other reasons to look at AJS, but if you are considering frameworks such as KnockOut I'd highly recommend AJS instead, regardless of it's perceived learning curve. Knockout is a library, AJS is a framework.

So far i think Google's Angular is great. Particular like the databinding and dependency injection.
For other js framework, there are knockout.js , backbone.js etc.
here are some posts:
angular.js example in backbone.js and/or knockout.js

I realise this post is old and you haven't gone with Angular, but I have a similar background to you, and I'm at the same point as you when asking the question.
So for the benefit of future visitors, some of the "risks" and links to resources I've found useful...
As many have already mentioned, Angular can have a very steep learning curve "Not only me, but co-workers that I consider highly smart developers, have struggled with some of the basic concepts" AngularJS is amazing... and hard as hell (link also has some good tutorial links which you asked for), and the version 2 stuff is looking more like java, which wouldn't have been a problem with your C# background, in my opinion Directives are hard enough to understand without verbose annotations and so on.
Angular performance can be poor in some cases, especially when using ng-repeat on a large number of elements Considering Speed and Slowness in AngularJS and Scaylr's experience. Other's have mentioned that performance really degrades over ~2000 bound elements, but that's usually met with arguments about how any app with more than that many elements probably isn't a good app. Keep it in mind though if you have legitimate use cases which call for many bound objects.
Angular is popular in terms of contributors, but ranks way way behind, say, jQuery in terms of production usage. Finding Angular developers might be tough, and jQuery or other developers converting have that "steep learning curve" to deal with.
Because Angular is young, you have no guarantee that it'll gain enough traction for your new Angular skills to be employable, and your new application not to quickly become legacy code
In v1.2 Angular doesn't support IE7 and below and v1.3 will drop IE8. For >=IE9, you need to follow some special coding practices.
The many javascript widgets, plugins and libraries which you might be used to using can't be used properly with Angular without heavy modification and people often suggest to re-write your component in Angular anyway.
UPDATE March 2014: after 2 months attempting to build a non-trivial densely functional one page app: There are many versions of Angular, and it's hard to say which is the best or most stable. It will depend on what you're coding with it. I'm finding some bugs Angular that are fixed by upgrading to a later version and others fixed by regressing to an earlier one. I've never had to go version shopping like this with jQuery.
UPDATE May 2014: Young, broken tools. Batarang is great until it doesn't work. I can't trust it until they fix this one.
And finally, the three best resources I've found for learning this stuff
Todd Motto's ultimate guide, and
UPDATE April 2014: this eBook chapter is quite amazing. I didn't buy the rest of the book yet, but the concept is fantastic
A full non-trivial app written in Angular (the accompanying book is OK, but doesn't really talk about the non-trivial app enough, as they appear to be saying advertised on their site)

I would say yes to this and check out John Papa's hottowel implementation as a way to do it.

Related

Separating Javascript in Server Control

I am trying to refactor my code by migrating a "Web User Control" which has become quite complex into a separate standalone "Server Control" project. Moreover, the control also has some javascript logic inside it.
So, I would like to get some advice on :
How and where to put (migrate) the existing javascript logic from the Web User Control?
How to logically and cleanly separate existing javascript for ASP.net pages? Any directory structure suggestion will be highly appreciated.
Please bear with me because I am a very beginner.
Kind Regrads
The answer to this question is long, complicated, and varies from case to case. Still, having worked on codebases like this, here are a few things I learned:
write tests: essential to any legacy codebase. you must write tests before changing your code. If it's as tightly coupled as you say then not writing tests will give you hell 2 months into the project when small side effects of your changes begin to creep into production.
make javascript Unobtrusive: put all javascript into .js files, away from the server and away from the structure. this way you'll have one less thing to worry about when writing your server side code.
divide and conquer: this is probably the best tip anyone can give you. I once worked on a project that had 5000 code line files, with html, javascript and visual basic all mixed in one ugly mess. There I learned that by extracting these mega classes into 100-line files, I could better understand the intent of each block and easily find dupes.
have a BA handy: sometimes a whole web page / class is so mangled that rewriting portions of it is the only way to bring it back to a maintainable state. Having someone who can explain the business logic is really important especially under these circumstances since they can tell you what a class is supposed to do, why it does it, and what parts are obsolete. In this same project I was talking about, we started rewriting certain pages. Having a BA there with us allowed us to remove around 30% of the code, since it was obsolete. having 30% work to do on a 250 thousand line codebase is really useful, especially when a deadline is looming.
don't use web controls, use html / jquery and handlers: asp.net web controls don't play nice with web standards. They don't play nice with ajax and the don't play nice with SPA oriented approaches. If you're refactoring towards this, replace web controls with their html input equivalents, then use javascript (jQuery, ext/sencha, dojo, etc) to add the desired behaviour. on the server you can then write handlers that can be called with AJAX.
you shouldn't do it alone: you should be part of a team that has an architect that sets the roadmap and patterns to use; a frontend developer that knows javascript, html, and some .Net; a backend developer that knows c# and .Net, aswell as SQL Server or the database technology and a designer that knows html5 and css, so he can propose better ways of structuring the documents.
you probably shouldn't be doing this at all: if you're a beginner like you say you are you should be working on properly made web projects and learning how to write correct code. I certainly don't mean to insult you, but this is a monumental task, with lots of complexities and tons of pitfalls. These projects are normally apps developed by VB6 programmers getting onto the web bandwagon as quickly as possible in the beginning of the past decade, and as a result have lots of procedural code copied and pasted into multiple classes and quirky ways to do things, as if the coder knew not much about OOP (and let's face it, most VB devs don't or didn't at least when ASP.net first came around). The person in charge should be a seasoned ASP.Net developer with solid understanding of modern web technologies and desirably experience in bringing a legacy project up to speed with the latest industry standards.

ASP.NET/MVC 3 Status

What is the status of ASP.NET/MVC technology? Would there be big changes that affect every code base? Is it stable (backward compatible) enough to be used in real world?
Best Regards
You know, the very site you're using.. Stack Overflow, was written in MVC. That should answer your question.
Yes, it is stable. Yes, it is production ready. It is used on this very same site. Depending on your existing code base there might or might not be big changes in order to port it to ASP.NET MVC 3.
Kaveh, I banned using MVC1 in my team because I am a late adopter but a fast adopter (agency work doesn't have time for discovering bugs on behalf of the creator).
Since MVC2 (and now including MVC3), I am very very keen for people to use it. There are some things about MVC that might be difficult if you've only ever worked in web forms, but if you understand http, and html, then it has cut away a lot of the annoying bulk in web forms.
MVC will quickly overtake Webforms in popularity.
MVC
requires less code in most cases.
MVC enables very easy integration
with other client side frameworks and now defaults to using jquery as a standard (in webforms, lightweight ajax usually requried a lot of custom code and quite a bit of repetition).
MVC generates almost no
garbage in your html output.
MVC is
long overdue, stable, secure and simply a
fantastic step in the right direction
for Microsoft.
I would only suggest you tread carefully with where you get your advice on how to do things and any use of 3rd party products like StructureMap that are not supported by Microsoft. I have seen some people make big mistakes with that combination, but never because of MVC.
There was little or no breaking changes from MVC2 - MVC3 unless you'd used certain approaches. I would actually say you are less likely to get breaking changes in future but any version upgrade in any platform will require some work if the changes are worth it.

My first .net web app - should I go straight to MVC framework (c.f. ASP.net)

I'm done some WinForms work in C# but now moving to have to develop a web application front end in .NET (C#). I have experience developing web apps in Ruby on Rails (& a little with Java with JSP pages & struts mvc).
Should I jump straight to MVC framework? (as opposed to going ASP.net) That is from the point of view of future direction for Microsoft & as well ease in ramping up from myself.
Or if you like, given my experience to date, what would the pros/cons for me re MVC versus ASP.net?
thanks
Have look here it will help you Choosing the Right Programming Model
If you need to work really close to the wire then MVC is a great choice. By this I mean, if you need to have very tight controls over markup then; while acheivable with WebForms; it is much easier with MVC. This would be common for applications that are targeting a public (e.g. internet) audience which might have a richer graphical experience. In contrast, if you're developing an internal (e.g. intranet) business application where graphical presentation is not as critical, then WebForms has a lot of really nice enabling capabilities that will allow you to move more quickly.
Don't get me wrong, you can make WebForm applications look really really nice, but you give up some control over the markup.
Very often ViewState comes into this kind of discussion. MVC will not have any ViewState so the on-the-wire footprint will be much smaller which translates to speed and bandwidth cost savings at some point. On the downside, making stateful applications with MVC can be more painful. In contrast, WebForms will carry ViewState by default and are inherently more stateful. This is typically fine for internal applications. Keep in mind that ViewState does not have to be sent over the wire... there are extensions that allow you to offload that to a local cache. I'm not favoring one over the other, but you should be aware of what each can do in this regard.
If unit testing is important to you then MVC is also a much better choice, as this is easier as well. This is totally acheivable in WebForms but requires you pattern your code behind correctly.
Security is not a major factor since much of setting up the IPrinciple and IIdentity occure in the HTTP pipeline via HttpModules, so either will do in that regard.
Another major factor in making your choice relates to your skills relative to the time you have to deliver... If you're not used to working in a stateless manner or coding standard web technologies (e.g. html, css, jquery, etc...) MVC will take you longer to do very basic things. With that said, once in place it will likely be cleaner, smaller, more testable, and faster. If you need to move very quickly there is a lot you can do faster in WebForms. WebForms also does a lot of heavy lifting with respect to markup so there are a number of details you can leave to ASP.NET.
I actually use both for a variety of reasons, and MS has stated they plan to continue support and development for both.
MVC is part of ASP.NET. You must mean MVC vs Webform to which the answer would be: coming from a Winform background, you will find webform easier to use. For the future, go MVC.
I used to work on desktop applications too, and never really got into web stuff. I didnt even (gasp!) knew HTML (yeah, that was my programmers shame). In my new job we were going to start a new application using ASP.NET MVC and I gotta tell you, I love it. HOWEVER I think you should only go with MVC if you are or you count with someone with good html/css design skills.
Html is easy I know (I've learned it know!) but I think its kind of hard to make nice designs with html and css, specially if you suck at designing and you could probably do prettier stuff using webforms, which is a little bit easier/similar to winforms.
Also, if you go the MVC way make sure you have enough time to learn it, since you are going to go a little bit more low level, gonna have to learn more of the little details, like the actual difference between post/get and all that stuff that is pretty much completely hidden in webforms. I would really recommend getting a book, I used this one Pro Asp.net MVC and really liked it.
Finally, if your page is gonna have interactive bits, or ajax-y things, if you go the MVC way you are more likely gonna have to learn javascript/jQuery too. If you go the webforms you can use the included drag'n drop ajax controls.
Coming from Ruby on Rails or other MVC based frameworks ASP.NET MVC is almost the best choice. (ASP.NET MVC is actually only the "VC" part, so you have to add an ORM of your choice. EF and Linq to Sql is the Microsoft way, NHibernate or other ORM's are the other way. One good quick start project is S#arp Architecture which uses NHibernate as the "M" part, or you can check out WHCM, which is a project built on S#arp Architecture and other good frameworks (it is considered an ASP.NET MVC best-practices demo project) ). ASP.NET MVC uses almost nothing from the WebForms package (the only exception I found is the AntiForgeryToken), so you'll loose nothing if you're unfamiliar with ASP.NET WebForms.
But as you said you have also made console applications, which ASP.NET WebForms resemble more.
If your project is new, I advise you to use ASP.NET MVC. If your project clearly separates the M-V-C part (like in S#arp Architecture, where they reside in different assemblies), creating a console application that uses the same business logic shouldn't be too hard. If your current project is to port a WinForms application to the web, then it might be easier to use WebForms.
I should get familiar with the language before using "fancy" stuff like MVC, because it's just way easier to learn when you could almost think in the language (but it's not necessary).
Horses for courses. If you're slapping together a quick app for someone, web forms is probably quicker and easier.
If you're building a long running enterprise app MVC gives you better testability a SoC.

Is there a reason I should not start with C#

I think I'm leaning toward C# and .net as a concentration language for learning web development. I would like to learn good programming fundamentals and I've looked at pretty much everything else. The four I've narrowed it down to have been C#, Python, Ruby and PHP. Is there a reason to stay away from C# (and I don't think the cost issue would really apply to my solo-developer situation but I could be totally wrong). Any thoughts?
I realize that these are all great languages so I'm not trying to ask which is the best overall. However, would Ruby be a viable alternative for a first language or does it have too much "magic under the hood" coupled with Rails, and unorthodox methodologies? I do like what I've seen with the language.
This is likely to result in a flamewar but I think C# is a pretty good language to start with for Web Development.
It is a full featured object oriented language and is statically typed and compiled. It's very well documented and has a huge developer community.
If you absolutely have to run on Linux/Apache and do not want to use Mono, that would be a reason not to use C#. Other than that, I don't think there is a compelling reason not to, particularly with ASP.NET MVC, which lets you move away from the WebForms model.
This is not to say that WebForms is necessarily bad but some might object to WebForms as it introduces abstractions that are not inherent in other web development platforms.
If you go with C# for web development, depending on your experience with web technology, I'd heartily recommend starting with ASP.NET MVC before ASP.NET Web Forms.
ASP.NET Web Forms is the original style of building ASP.NET applications, and tries to abstract a lot of the details. It allows you to build applications without realising what's happening under the hood (post data, state management). In my opinion, these abstractions although making things easy at first begin to "leak" when you get into more complicated scenarios (as this tutorial proves).
ASP.NET MVC on the other hand makes it easier to build web sites that are a lot "closer to the metal" while still keeping you productive. If you want absolute control over the resulting HTML and aren't afraid of things like cookies, form tags, post and query string data, then you might enjoy ASP.NET MVC a lot more.
Of course it would be beneficial to know both. But if I was starting now, I'd probably start with MVC and move to Forms (then realise how bad it is and move back :)).
There are no "best language over all". You use one tool for the purpose it has been made, that's why there are several tools.
Since your question is "why not learn C#", I'd say :
If you plan to work with other OS then Windows (Mono cannot compare).
If work in an env or with people not .net friendly (e.g : bank, scientists)
If you work in an env or with people that are expert in another good tech (never underestimate the use of a good master).
If you think Free Software matters so much that using a MS product is not worth it.
If you don't like MS Visual Studio (working in c# without a good IDE is a pain).
If You plan to program something that .net is not suited for (e.g embedded devices, scripting, real-time, fault tolerant system, AI, etc).
If you are a web dev and can't afford a Windows Server Licence.
If you want to learn programming with the very basics, including simple functions and quick and dirty scripts.
Now, I program in Php, Python, Java and C#. Python is my language of choice, but c# is really the first MS programming tool that seduced me : it's clean and efficient. Really, it's about what you want to do, not a question of religion.
Make YOUR choice.
That's said, C# sucks and Python rocks.
I agree C# is a pretty complete language, it's syntax is clean and extensible. There's a huge amount of web resource already available, but and it's a big but, it effectively ties you to windows as your platform. For web especially that's an important consideration. On the desktop windows is king, but for web servers the market it isn't nearly so dominant.
Another side issue, if you're looking at rich media on the web you have to consider Flash and/or Silverlight. If you go C# then you're someway to using Silverlight without learning a different language.
Don't worry about the cost. The compiler is free to use, along with the rest of the Fx SDK, and you can even download Visual Studio for free.
The disadvantage to learning C# is that it ties you to a proprietary platform and software stack. Now, there is Mono, which does a good job of implementing much of C# and .Net, but the primary and most complete implementation is Microsoft's which is non-free.
I have not used C# enough to debate it's technical merits with respect to Ruby or Python. I can say, however, that learning to use and even contribute back to free software can be quite educational, in addition to the other benefits (discussed in length elsewhere) that free software provides.
c# is a good language to start with because:
It is a very good and very clean language
It has an excellent library (.NET framework). This is one of the most important things to consider when choosing a language.
It is very popular, you'll always be able to find the answer you are looking for from the community.
If you know c#, you pretty much know VB.NET.
c# is syntactically similar to Java. Learning c# won't teach you Java's libraries, but it will significantly reduce the learning curve if you want to enter the Java camp.
c# is syntactically similar to c++. Again, it uses a different library and unlike c++ you get memory management; but the learning curve should be somewhat reduced if you decide to play with c++.
As for the web...
ASP.NET webforms does a lot of magic for you. ASP.NET MVC (just released) does almost no magic for you. For learning, MVC is the better choice.
C# is a great language to use. And since you are using it via the web and not desktop applications for example, you don't have to worry about being multi-platform since the code is run on your server and the output delivered to the clients. With that said, you will have to find Windows hosting (which can sometimes be a bit more expensive) or use mono (which isn't exactly the most updated software out there). The downsides are minimal though, grab a copy of the express edition and go for it!
I think the cost of deployment might be a different thing, i.e. if your project needs to scale horizontally, and add more servers to load balance or even for geographically distributed servers. Usually the windows hosting will run a bit more than linux (without even considering the flame wars reasons).
C# is fine for starting if you are doing web development. However, I recommend that you don't start programming with web development. Web development is hard to get right. Way harder than little command line things. I recommend that you get some good experience programming for the command line, and then move up to GUI, and then move on to the web. The web has a whole bunch of things you have to worry about. You have to know 3 languages (HTML, JS, C#(or insert your server side language here)). Plus you have to worry about all the browser quirks and stuff. And that's without even getting into databases. Which is usually used in most web applications, but opens up a whole other can of worms.
Considering all the answers so far, I thought I'd look at all four languages mentioned.
While I've done a lot of development in PHP, and sadly continue to do so, I think PHP was never a great language (though it had a few great elements) and these days there's not much point picking it up. It remains extremely easy to get into but I think in general, PHP is a "bad habit".
Python is a great language, but to me, Ruby is all that Python is and a bit more. Personally I would go for Ruby.
C# is also a great language, but while I haven't used C# enough to say anything with confidence, I feel that Ruby is a better choice.
No reason in particular to stay away from C#. It's as good a language as any. Stackoverflow uses it for example, so it works on a successful website, and you can get jobs programming in it.
The proprietary thing would be a consideration if you were programming as a hobby or off your own limited budget, or you wanted to contribute to the development of the compiler/language. I'm guessing neither of these are the case. (Edit: as others have pointed out, open source environments for C# exist.)
It depends on a couple of things. C# and .Net is populate and th tools are really very easy (complared to Java! Java developer talking here...) but Windows Hosting is expensive vs LAMP (which include Ruby, Python and PHP).
For me it all depends on the tool that you want to use. For web services etc I would use C# but for a simple website PHP since its easy.
It also depends on the job market of your location... here in South Africa you get alot more C# jobs and not much PHP etc. Off course if your a freelance you will struggle to find work.
For me Ruby again is good for my own person stuff but you don't get any Ruby jobs here.
My advice? Learn the differences for yourself. Play around with both of them. If you have a project in mind, write a prototype for it in them. You'll always be at the mercy of other peoples' biases otherwise.
ASP.net (C#) and Ruby on Rails are used in high-profile sites, so you can't go too wrong with either one. Might I also suggest that you try out Python programming with django? It's what I tend to prefer for web programming.
I'm a C# .Net developer and I think it's great, but I'll highlight a danger in the Asp.Net WebForms. It is unlike the majority of other web frameworks and does A LOT of magic under the covers. As others have said ASP.Net MVC is probably more inline with other web frameworks (Rails for example). Web Forms abstracts a lot of the nuts and bolts of webdev away which If you want to be web developer you'll end up needing to know. So yes C# is great but I'd start with MVC and then look at web forms possibly. Also looking at other languages and frameworks is highly encouraged there's always stuff to learn.
Commercially I am a C# developer. I love C#. C# is a great strongly typed language. With Resharper installed I can build my ideas in code rapidly and flex it to my will.
When I go home each evening I use Ruby. Even though I have no refactoring support (snif.) I find I am much more productive in Ruby than in C#.
I worked writing a large ASP.Net application for a couple of years. We implemented MVC to try to detangle the view from the model. It always felt like I was fighting the framework, not working with it. The latest .Net frameworks for doing web application are based on Rails... just a couple of years behind. I love the language. I love the CLR. I'm not too keen on .Net.
I find the ruby community to be friendly and vibrant. The rails open source community produces loads of tutorials and plugins that make getting up to speed easy and putting your application together simple.
Another thing to consider (as far as choosing a language to learn) is that ruby is an Object Oriented language. Even classes are objects. C# is a Class Oriented language, ie. it provides you one way to create objects.. define a class first. (not totally true.. you can generate assemblies in memory using codedom.. but that is by no means easy).
This may seem like a subtle point, but there is a difference.. and until you get experience with an OO language like ruby or smalltalk it's not obvious what that is. Once you have felt the freedom of building objects by mixing in functionality at runtime etc. you find that all the 'work-around's you had to do in C# disappear. Not having the safety net of interfaces does seems scary at first.
In all, I'd learn ruby..
If you are new to programming (totally) I'd start with http://pine.fm/LearnToProgram/
Then I would learn BDD (RSpec) and get test infected as soon as possible.
Then I'd consume rails tutorials and screen casts until my eyes popped
The only problem is .. if you start with ruby then later go to C# you'll find yourself going "Aaaaagh! This would be so much easier to do in ruby" all the time. I know I do.
It really depends on what you are trying to achieve. I program in both and to be brutally honest, if you are trying to make a career out of programming, I get paid twice as much for .NET programming. The types of clients that I do PHP dev work for are not the types that pay a lot (PHP is often chosen based on saving some $$$). .NET seems to be much more entrenched in larger corporations.
Just my observation...
No disadvantages really except that you will be unwelcome in those social groups (and even geographical regions) that pose themselves against the "evil Microsoft".
The language (better .NET platform) is quite good. One important thing is that it is being very actively developed causing some people trouble keeping up. But I'd rather have rapid development compared to year-long stagnation.
You might consider checking what employers in your area prefer as a technology stack.
Considering licensing costs you can consider the following: If it is a small site you can use Visual Studio Express/SQL Server Express for free and it will be sufficient. If you come up with some major heavy trafficked project you will likely to find a way to make revenues and cover licensing costs.
Learning C# is great in 2009.
Way back in the day, when I entered the professional world, the language landscape was very different. I coded professionally in C and Modula 3 (Pascal replacement language).
My point is that I would plan for the technical landscape to change over time, and plan for that in your professional career development.
Learning multiple platforms is a great way to accomplish this. For example, you could have C#/.NET as your primary skill, but also work with JAVA. When a new platform emerges, you could add it as your transition or backup skillset.

Asp.Net MVC vs Castle MonoRail

I've some experiences on build application with Asp.Net, but now MVC frameworks become more popular. I would like to try building new multilingual web application using with Asp.Net MVC or Castle MonoRail but I don't know which one is good for me. I don't like the web form view engine, but I like routing feature in Asp.Net MVC.
Could anyone tells about pros and cons between those?
Which ViewEngine is the better as well for overriding the master template?
Speaking as an advocate of monorail, I've got to say you should probably go for ASP.NET MVC. To be honest, the simple fact that ASP.NET MVC is going to become the default architecture within three years should probably swing it. This equation was different a year ago, simply because the default architecture had serious productivity problems compared to MonoRail.
If you want to talk technical advantages and disadvantages:
ASP.NET AJAX is a mess (avoid it), but they've now got jQuery. In fact, the jQuery support is better than any other environment. Of course, you only fully get that with IDE integration with the standard view engine.
There are some aesthetic improvements (for instance, the way model information is passed around is much cleaner and more obvious than Monorail).
Also, don't dismiss the standard view engine out of hand. You don't have to throw controls at it like you did with ASP.NET, you can code it in a pretty similar manner to Brail, only using C# instead of Boo.
There are things that are just plain ugly
* the number of methods that take object for a parameter. Good luck finding the documentation on what exactly they expect.
* Microsoft's fondness for abstract classes over interfaces. They have their reasons, but I still dislike it.
Also, in many ways, MonoRail remains the more complete platform. There's no abstraction for validation or paging in ASP.NET, for instance. Also, there's not really any help for binding to a model. The helpers have very little functionality compared to their Monorail equivalents.
Overall, though, I think ASP.NET MVC is a winner.
MonoRail and ASP.NET MVC are fundamentally very similar, you should be well off using either one of them. MonoRail has existed much longer and has therefore more higher level features.
The main strength of ASP.NET MVC is it's routeing engine, to be fair MonoRail has pretty much an equivalent routing engine, and with some modification you can use the ASP.NET MVC routing engine with MonoRail as the routing engine is not really in ASP.NET MVC but in System.Web.Routing (Released in .NET 3.5 SP1). ASP.NET MVC and integration with Visual studio is also a plus, and will probably get better as we approach RTM of v1.
The MvcContrib project contains some great view engines, like Spark, NHaml and Brail. No one could be considered "Best", A personal favourite is Spark. For more on spark: http://dev.dejardin.org/documentation/syntax
The WebForms engine has intellisense which is a great advantage that to my knowledge all alternative view engines lack.
Apart from perceived popularity and support from Microsoft, ASP.NET MVC still lacks some core features that Monorail has had for a long time like controller organization (Areas), native ViewComponents and Filters that can use IoC to name the most important ones.
I have some big applications that use all of these features and I've had a hard time porting them to ASP.NET MVC.
I have worked with Monorail for some years now and while MVC looks promising and it's flexibility is awesome, I still find it akward that for every other thing I try to do, turns out it isn't there and I have to either plug a little piece of MvcContrib, another piece of SharpArchitecture, build it myself, you get the picture. Monorail is so much easier to work with (right now, that is).
I expect things will get better in the next few of months as some proposed solutions will begin to rise against others and become more mainstream. Hey, diversity of options is good but trust me, you don't want to be in Java-land 3 years ago where there were so many web frameworks that you could build your site using one for every different page!
In the meantime I will keep slowly porting my MR apps to MVC, just in case.
I think MVC wins hands down. Its feature set is very similar, but is going to be the more "popular" of the two (and thus typically more widely supported, documented and extended throughout the development community). In addition, the new ViewEngine (Razor).. and IDE improvements factor in for me, and boost the value of choosing MVC over monorail, in my opinion.
I've used pretty much all the common ViewEngines, but wound up rolling my own (created an OpenSource Project for it) utilizing the awesome StringTemplate template engine. ST is a true separation of concerns, IMO. I find myself writing better apps as a result, with MUCH less tag soup. I also threw out a quick intro and reference guide if you choose to kick the tires on the engine. I've had awesome luck on projects I've deployed thus far using it. That being said, Razor (MVC 3) looks pretty impressive.

Categories