Javascript RIA vs..NET GUI
I am considering moving my company's internal business application from VB.NET to PHP. Some of the people were worried about losing the GUI functionality found in .NET. I get the impression that with the correct javascript structure, everything in the .NET GUI can be replicated.
While I am still researching this question, I would like to ask if the form functions in the .NET GUI can be replicated using javascript and more importantly, would it take much longer development time to get the same results?
source to share
First of all: to answer your question.
Tree management is difficult to emulate in a web environment. Reasonable but tough (look at Yahoos YUI for an example).
- Condition : You get it in WinForms, not the Internet. It has more to do with how people use the app.
- Interaction . It's easier on WinForms than on the web. Again, this is doable, but more layers involved.
- Data size . How much data is displayed? You don't see a grid with thousands of records on the Internet that WinForms might have in common. This can affect network load times more than WinForms.
- Testing : How many browsers do you need to test. JavaScript / CSS differences between browsers can make life difficult. Oh heck, IE6 will make your life difficult if you have to develop for it.
- Development Time : This is roughly the same for a developer with experience in both environments.
But there are a number of other questions that pop up in your initial statement.
Why migrate from WinForms VB.Net to PHP? Switch to ASP.Net with VB.Net instead. Could save you from completely reimagining the wheel. Also, then you don't have to learn how to convert between frameworks.
source to share
I will say that yes anything "MAY" be replicated, but the amount of time to do this can be a big bottleneck right away.
I'm going to assume that your current application is an ASP.NET application and that you are not migrating from WinForms. (If you answer, it doesn't matter anyway, but I can add some additional comments).
Out of the box with drag and drop functionality from a UI perspective, you have data validation and many other common elements out of the box, although although they are performed by clients, you don't need to write a single line of JavaScript to make them work. This is a big economical savings, but it can be replicated elsewhere, yes, but it takes time.
Second, you can very easily work with ASP.NET AJAX features in combination with the AJAX Control Toolkit. They again allow .NET logic to be used to bundle things together, but can they be replicated? Yes, jQuery and many other AJAX frameworks contain similar elements for many elements.
The biggest point I have to make is that if you already have something and are familiar with the language and technology behind it, why give it up without risking doing it on time and entering the unknown world of the new language. I think it's only $ 0.02.
source to share
In general, it always takes less time to use Microsoft technologies, be it web apps, desktop apps, or Silverlight apps lately. There are several reasons:
- Microsoft provides wizards for everything.
- Microsoft raises the level of abstractions high, to the point where it is sometimes perceived as "throwing down" developers, although this is debatable. More on this in No. 5.
- An abundance of third-party widgets, controls, etc.
- Tight integration with IDEs like Intellisense, Source Control, IE, Excel, SQL servers, etc. is not included.
- On the same line with # 2 MS provides drag, click and click in its IDE. Microsoft also loves the concept of data binding, so you end up with a table or data grid with potentially very small lines of coding.
- Debugging is seamless, out of the box most of the time.
I would say that if your application is somewhat simpler, you can do it faster with the Microsoft framework. In an Intranet environment, where you can control the browser (in the case of web applications) which users should use, or which framework to install (.NET framework and / or Silverlight plug-in) and development time are critical, the Microsoft path might be the way.
There are downsides (I have to say the following, with the exception of StackOverflow and a few sites that are built using ASP.NET which are really well done):
- Your apps tend to be bloated. A simple desktop application still requires a complete installation of the .NET framework.
- Sometimes doing the easy thing can make you end up doing all sorts of confusing things, as Microsoft APIs aren't always the cleanest.
- For a web application using ASP.NET, you might end up with applications containing very ugly JavaScript code. While not directly related to this point, there was an instance that was discussed on Ajaxian.com a while ago when someone discovered some really ugly JavaScript code right inside SharePoint. Culturally, most ASP.NET developers don't care if they don't need or just don't know JavaScript. This is because the framework encourages this (although this may change in the future with jQuery integration).
- Your web application will generally not run on anything other than IE, and this may be acceptable in your situation. If it does, it might happen by accident and not by design.
- Microsoft replaces its own technology every few years and offers very little backward compatibility. They force developers to retrain every few years or so and can get confused in any transition period we try to figure out. As an example. this is currently the case with ASP MVC and Silverlight. But that might be a good moment, not a disadvantage.
source to share