I work in a company which is primarily concerned with desktop apps not served over the internet.
Part of my value is I have a web based background and proficiencies in ASP.NET, JavaScript, JQuery etc.
The issue I'm having is that compared to a traditional desktop application building a rich web based app is more time consuming. This is understandable in terms of the hoops that need to be jumped through for web development. This is a cause of frustration for those not familiar with the ways of the web.
However because people are used to the non web world where I work I need to utilise every possible tool and technique to be productive as possible while building web based applications.
As such I'm looking for what other people do to be as productive as possible while making web based applications. I'm primarily thinking of ASP.NET (not using MVC) but apart from that everything is open.
The best tools for web development, in my opinion, are:
.Net Reflector
Firebug
IE Developer Toolbar
IE Tester and MyDebugBar
Fiddler
You should also look into NHibernate as an option.
The best choice of tools tends to vary quite a bit from one developer to another. It's also very dependent on the details of the type of application you're building.
For me, Visual Studio Team Suite is indispensable. It has a rich set of visual designers and other features that have a big impact on my productivity. Deep integration with bug reporting and source control is another huge time saver (I use Team Foundation Server).
With web forms, you can of course often use drag-and-drop components, which improves productivity for some people (although not me). I can't say I'm a fan of most third-party components. They can be quirky, take a long time to learn well, and then still not do exactly what I want them to. It's also a skill that often isn't portable from one job to the next.
You can leverage jQuery to help simplify scripting -- although even with jQuery I find scripting to be one of the most time-consuming and error prone aspects of web development.
If it's suitable for your environment, you might explore Silverlight. That way, you can often have the best of both worlds, building desktop-like apps using desktop-like tools, but with web-based deployment (Expression Blend is an awesome tool). You can also use Silverlight as a replacement for JavaScript in many cases, with code that's compiled and type-safe.
Good tools on the data side are critical, such as SQL Server Profiler. Visual Studio Team Data (part of Team Suite) is invaluable for it's data generation, unit testing and deployment and management aspects.
Something very underrated by many web developers is building up an appropriate infrastructure: things like logging and performance counters, that can help you track down problems quickly when they occur. A solid configuration system is also important.
In case it helps, I put together a longer list of tools. I also write about something I call the "ultra-fast approach" in my book, which is about more than just building web sites that run fast; it's also about how to build them quickly and reliably: Ultra-Fast ASP.NET.
You should use third party tools.
Telerik RAD Controls and the AJAXToolkit are two such tools available to you. They make much of the 'fancy' stuff built in.
Then, and probably preferably, use JQuery.
With those three options, you can make a fancy web application in the quickest way possible.
Finally be sure your UI and business logic is properly segregated so you can reuse your business logic easier.
There are several ways to increase productivity while building web applications, and they're not too different from desktop programming.
Code re-use. As a shop that is primarily desktop-based, this may not be an immediate option. But as you build your code-base, you'll find that you can use some of the code over for new applications, and even begin building your own customized frameworks.
Development tool knowledge. If a lot of the tools are similar, then you may see immediate benefit from this. If not, it may take more time as the team gets used to new IDEs, etc.
Third-party tools. UI toolkits, backend frameworks. These exist in both worlds, and could be utilized to help jump start development, until items 1 and 2 can be worked in.
A few must-have tools on the client side (i.e. the browser)
FireBug - let's you debug your javascript, DOM, headers, etc
WebDeveloper - provides all sorts of information about the rendering of the page
Selenium - Web UI functional testing framework + tool
(all are firefox add-ons)
Here's some of the tools I use for IE and FireFox, http://www.learn-ajax.com/blog/2008/04/debugging-tools-for-web-applications_03.aspx . Chrome, Opera and Safari also have their own built in client-side web development tools as well.
Most important tools for ANY productive development
Dual large screen monitors
keyboard and mouse that works for YOU.
Comfortable high-backed chair that will save you taking 2 weeks off for physiotherapy down the road.
Related
everyone, maybe on many occasions you have come across someone who has many winforms applications developed in visual studio. Well, in my case, I have a fairly complete system made in a winforms environment and I need to transfer it to the web since a client changed his entire team to use mac. Someone has a recommendation because I would not like to have to start from scratch to reprogram everything. I also did not bother the customer by asking him to install virtual machines.
In advance, thanks for any suggestions
Converting Winforms to ASPX aka Webforms? Probably not a good idea: Webforms is discontinued. I would prefer Blazor, that is built on ASP.net Core. With outstanding interface performances.
You don't have much of a choice.
this really comes down to two systems having VAST different architectures.
Even on the desktop? You can no more convert a complex FoxPro application to vb.net. Or convert a ms-access system to FoxPro. They all would have been built from the ground up with 100's, if not 1000's of little design choices based on the given tool set.
This is kind of like the difference between a car, and say a airplane. They are both machines for transportation. But even things like the seats. One (the car) might have big comfortable seats - power assisted tilt etc. The goal is comfort, and total over all space and weight of that seat is not all that huge of a design goal.
Now, take the design for a seat in the airplane. It has to be lighter, thinner, probably use more fireproof materials. So 100's if not 1000's of SMALL design choices along the way will result in a seat for that car, or the plane.
It just a seat, right? So, since the architecture between the desktop and the web is much like the difference between a car and a helicopter? then little of the 100's if not 1000's of design criteria you used to create that desktop application simply will not apply, and thus the work can't be salvaged.
However, if you had used WPF in place of win forms for the desktop application? Then you can salvage a LOT more, since both the web application and the desktop application will have "mark-up" used to create the form/display in question.
In fact, this is one reason developers will choose WPF over winforms. (it allows easier migration to the web). And for those coming from web development? They will find WPF forms and layout VERY similar to how they do web development.
And the other reason of course is now with css, HTML5 and a whole bunch of other new things for the web? Well, then web developers actually have MORE UI choices then the desktop now!. So, WFP is an attempt to leverage many/much of the web based new technologies into desktop development. So while winforms don't support a graphics in a button? WPF does support this - so does the web.
But, ask any WPF developer? The cost + time for WPF desktop applications is a LOT more work. And so is creating web based. Some claim they can develop just as fast with WPF applications for the desktop - that's not what I seen - and NOT even close!! You find for the web, as much as 2 times, and often 3-5 times the cost compared to desktop.
Now to take a huge application and re-write because of a few Mac's? Well, that is crazy. You would setup terminal services, and have those Mac use remote desktop to run that application. Thus, the Mac's don't need VM's or anything.
But, there is no automated conversion system, and like parts, sets and doors from a car? They don't work nor fit on a helicopter. Too much difference of a architecture is at play here.
I guess this would depend on the size, scope and estimated cost of the existing application. But to allow workers at home (remote), people on the road, and that of allowing Macs to use that software? I don't see why terminal services is not a solution - and that can be setup in less then 1 day as opposed to a whole re-write of the given application (to run on a few Macs? - doubt that can justify a re-write).
If you're asking how to take the code you wrote over the years to create Winform-based, rich user experiences and adapt it for the web, then you will be disappointed.
The best you can hope for is to have such a clean separation of concerns in your existing app that it would allow you to salvage all code that's not UI dependent and use it in the backend of a whole new application. Everything else will have to be rewritten from scratch.
If your client still wants to use your Winform-based app in a Mac environment, he'll have to use a VM.
Is Silverlight just basically Microsoft's version of Adobe Flash? If so, I've read over the years that Flash is very SEO unfriendly (SE bots see it as a blank page, I've been told), and some browsers don't like Flash too much. Are the same things true for Silverlight?
I just have a company website I made in Visual Studio 2010 / vb / asp.net 4.0.
Do you have to be an experienced programmer to work with Silverlight, or is there a nice GUI to help out newbies? I'm just trying to find out, now that I've downloaded 5.0, if the value of learning it is worth it. Thanks!
Silverlight is a lot of things, in summary you could say that it's a light-weight .NET run-time, a subset of WPF and a capable video player.
Silverlight brings XAML to the web, yes, but more importantly it appears that it's becoming more and more a framework for deploying rich business applications over the web, but not through the browser.
Some would probably argue that Silverlight (along with Flash) is dead, and that the HTML5 is the way forward. That might be true, under certain circumstances but Silverlight has a lot of cool data binding tricks as well as a very capable retained mode render which is very suitable for business GUIs.
I would argue that the choice wheter to invest in Silverlight as a technology or not is a question you should ask yourself, basically what's your reach? e.g. I would not develop Facebook using Silverlight because Facebook has to be everywhere. If you wanna go social, then the web is ubiquitous. But if you have a customer base that acknowledge Microsoft, and already run Windows everywhere, the kind of headway you can make with Silverlight is quite astonishing.
I urge you to look at some Silverlight demos to gain a better feel for what Silverlight has to offer. Then to build great Silverlight applications you need to invest time in learning, things like XAML and MVVM (using a lot of data binding).
Silver light is Microsoft's option or alternative to adobe flash its provides user with the feature of developing Application that are rich in UI we do have tools that enable us to develop appealing UI that is Expression Blend. SO there is lot to learn in it but talking about the future of this technology i doubt as after HTML 5.0 which enables us to get most of the features of silver-light i don't think any one will be interested to get an add on plugin to silver-light to achieve same result so its up to u if u want to learn it as some new technology its good but as a future its not that great.
SEO friendliness depends on the amount of effort your developers are ready to put into it, Silverlight and Flash both. Silverlight has a framework (Navigation) allowing deep linking that can help for instance.
The tool chain is top class, you get the arguably best IDE (Visual Studio 2010), and a cool designer friendly tool (Blend) that enables, among other things, non-code oriented development, or put the other way, a designer friendly workflow. The XAML+data binding approach is also much more productive than most of the competing alternative (personal opinion, but shared by many developers).
The value of using and of learning Silverlight both is very dependent on your company's objective and skill set. If you already have proficient .NET developers, intend to target Windows Phone or Windows 8 or even do some WPF (Windows desktop counterpart of Silverlight), the learning is either small or a good one. If you're a pure web shop, valuing multiplatform, needing iOS/Android/etc... support, you're probably better off with HTML+CSS+JS.
Currently i am working on developing one Warehouse solution from scratch, i am planning to build it in silverlight (as this solution will take around 8-10 months) and the programming will start from Feb 2010.
I need to develop this application for one organization. Certain parts needs to be accessed by public which we are planning to build in ASP .Net 3.5
Now i just wanted to start a thread here for pros and cons of using silverlight, some of them i have already analyzed
Pros :
Rich UI
Excellent user experience
Reduction of scalability concerns
New set of features like data binding, control template etc..
Speed of development (After initial learning curve..my experience says it is faster to develop it in silverlight)
Other rich set of features coming up with SL 4.0 (SL 4.0)
Cons :
Cross platform issues (moonlight is there but it may take some time)
Cross browser issues (Chrome or other browsers)
Learning curve
Any other unknown risk (As there are not many enterprise level application developed in silverlight...or may be i am not aware)
I have also got one link for Pros and cons of silverlight(here) some of the cons might not be relevant with SL 4.0
Also i am having one good link for comparison between ASP .Net Ajax with Silverlight (here)
EDIT :
I have also found Technical Article series in code project (Just Type # google "Adventures while building a Silverlight Enterprise application" and you will get it, i am trying to analyze this series as well)
Please add some pros and cons if you find as i am trying to analyze it from all the angles. It will be of great help if you find any whitepaper on it.
The Pros and Cons have to be weighed against your own requirements.
Rich UI
Compared to what? Its not really a Pro, other tools can deliver Rich UI, where does one draw the line that allows a UI to call itself Rich? A Pro can't be a Pro if can't be measured.
Excellent User Experience
That isn't a Pro either. I wish I could buy product that delvers such a thing out of the box. The reality is it's up to you to deliver the UX. E.g. Stackoverflow delivers an excellent user experience, it doesn't use a tool like SL and it's entirely down to good design not the tool (ASP.NET-MVC+various other tools).
Reduction of Scalability Concerns
Compared to what? Early ASP.NET Forms with extensive use of callbacks then yes. However plain old HTML with Javascript frameworks can deliver this same "Pro".
Speed of Development
Well that depends on how you measure speed and how you weigh the importance of the UX. Currently SL developement isn't any better at ticking off business function points than other tech like poor old ASP.NET Forms and is probably worse. However delivering those same function points with a slick, imaginative UI may tip the balance more in WPF/SL's way. In reality SL allows you deliver more UX with some (but importantly not prohibative) extra effort.
Other Rich Features in SL4
Only a Pro if they would actually add value to your requirement.
Cross Platform
Do you really have a Cross Platform requirement? Within a warehouse business how many Linux and Mac desktops are there? That should answer your cross platform question.
Cross Browser
Is this a Con? Does the company in question allow the use of a variety of browsers? If so which? You can compare that to the browsers SL4 supports and out pops your answer but its your answer not everyones answer. Isn't cross-browser a bigger concern for the Extranet-esq part of the app?
Learning Curve
In all of these factors what are you already versed in is by far and away the most important. I'm guessing its MS tools and in particular .NET, right?
If you're not familiar with WPF already there is some learning curve but its not very steep. However you should definitely make sure you take the time to perform some training projects before you even start designing your real product. That process should help you measure how long it will really take and whether it is really feasable.
Other Known Risks
SL is still very young and it won't sit still. Frustrating "issues" will eat time.
Other questions to ponder
What UX ideas do you have that can't be delivered by a browser?
Why deliver the app via a browser hosted app at all? A WPF application not an option?
Silverlight 4
Considering your timescales if you do choose Silverlight you should target SL4.
Since you are developing solution for the warehouse, you may need consider building a web service with wcf pollDuplex (basically push data from server to the client periodically), just a note on it: it is not (yet) a very scalable and reliable (prior to SL4). Default concurrent connection is 10 (if I remember well), and you have the option to overwrite this default number, however, I haven't find a way to dynamically change this number which turns out to be a scalability issue.
One cool feature I like about SL 4 is the added support of printing, now you have the built-in ability to print the content.
Anyone bulding an Enterprise LOB with a Silverlight client should take a look at John Papa's PDC video.
However, IMHO the initial release of RIA Services was too limited. Now that the next version is buit on top of WCF Services, and the endpoints can be switched out to make them more accessible by more UI clients RIA Service is probably a very sensible investment too.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What's the advantage of one over the other? I am so tempted to implement everything in silverlight now, so is ASP.NET, in particular, with Ajax, going to be dead?
For an enterprise solution especially, with 100+ views and 1000+ pages, is it still feasible?
Why isn't silverlight adopted that much by most enterprises? It is mostly used for videos and galleries, etc.
Cheers
Two completely different tools.
They aren't even competitors, much less one killing the other off. Silverlight just came out, requires browser plugins and a client-side runtime, and only has a fraction of the .Net framework available to it. Enterprise hasn't adopted it yet because most clients are wary about having to roll out browser plugins (anyone remember IE5 and ActiveX?) and still consider Flash a more mature and viable way to do client-side browser apps.
ASP.Net works with any web browser, is well-established, has access to the full .Net framework and the web environment, and can easily handle the load that you are sort-of describing, as long as you know how to set it up properly.
Silverlight is a client-side based solution. It's a miniature .NET runtime and Windows Presentation Foundation package, rolled into one and made (somewhat) cross-platform.
Silverlight won't work on your iPhone, it won't work on really old PCs, etc... You can use it in the enterprise, but if you're doing an enterprise based app based on it, you should probably just develop your stuff in WPF and get all of the features of .NET.
Silverlight isn't adopted much because either A) enterprises are using Windows Forms or WPF because they can or B) because it's relatively new to the game, and it remains to be seen how much traction it will get in the marketplace vs. Flash and Java.
Some advantages/disadvantages:
Silverlight
Lower installed base (although increasing at a good pace), due to necessary VM.
You can program in one language, any of the .Net languages supported for Silverlight
Equivalent apps may perform better on the Silverlight VM due to compiled code nature.
ASP.Net
Higher installed base, due to apps being executed on browser, no extra VM needed.
Ususally use multiple languages for programming - C#/VB.Net, CSS, JavaScript, HTML (there are tools that allow you to circumvent this such as the Google Web Toolkit (GWT).
Equivalent functionality web apps may perform more poorly due to interpreted nature of code executed by the browser.
Why isn't Silverlight adopted by enterprise? Because most computers would need a client installation to view the site. Flash is widespread (most computers have at least some version). HTML and Javascript are even more commonly supported. But Silverlight would definitely be an annoyance which would lose some users.
That said, we use some Silverlight on our internal apps. We have a portal/intranet which runs in a controlled environment and we use some Silverlight there. But Flash and Ajax on the public site.
I can do some amazing things faster in Silverlight than with ASP.net, which would be perfect for a targeted population like enterprise customers. I can't run Silverlight off of my Iphone but I have accessed some of my ASP.net apps from it so that's one example where ASP.net wins.
I'd say it will grow but even at version 3, it's a jumble of codeplex projects and 3rd party controls.
I'm looking for a solution now for drag and drop treeview which I can do easily in AJAX but having trouble finding a solution with silverlight and I've tried on my own.
I would learn both and mix them.
I've targeted certain areas of my personal sites for Silverlight, but am wary of overloading a user with too much. For a blog, for example, I wouldn't redo the whole site in Silverlight--that's overkill--and similar to how you wouldn't have (or shouldn't have) an entire site done in Flash. No matter what, some people will have it blocked or not installed at all, and why exclude potential users/clients/readers?
There's the fact that clients need the runtime installed, which means I'm hesitant to convert any critical functionality over to Silverlight for fear someone just won't have or want to install the runtime.
As far as professionally, we are moving forward with web apps that at least partially make use of Silverlight, but the targeted audience is fairly well-controlled in that we can tell them, "You'll need to have Silverlight installed", and we can reasonably be certain they'll comply. For internal tools where it makes sense we are 100% Silverlight all the way as we have total control over that audience. Again, though, the usage has to make sense.
I am tempted to say go with silverlight, its installbase is still low but its because there still isn't very many silverlight apps out there. It is still very easy to install(not as easy as flash though) so I dont see that as a big issue. Html was never ment to be used for applications so a silverlight app is far better suited for application programming. This is of course only my own opinion but I am sure the direction is more, bigger and higher quality applications running on web and not least apps running on mobiles (Silverlight is also coming to mobiles)
I think we need a better programming model for web applications to keep productivity up when creating more complex web applications and silverlight is certainly a step up from html and javascript.
I'm working on a project that currently has zero users but we would like to scale up to potentially hundreds. Currently we are running on a MySQL database with AMFPHP interacting with Flex. We used Flex because of its robust graphic features (important to this project) and because the initial developer (not me) already knew ActionScript. We are currently using AIR but might switch to web-based Flash at some point.
My questions are:
Is Flex a good tool for a project like this?
What are the main limitations of Flex that we might encounter?
What are other development platforms we might want to consider?
Thanks.
- Dave
Short answer, Yes. There are already many prime-time Apps using Flex as their UI development platform. If you go to the Adobe site they showcase quite a few.
Speaking personally, I chose Flex for two reasons, first was that, although you probably can do much of what Flex does in HTML or with an appropriate toolkit, Flex is designed for attractive and compelling user experience and has available all of Flash. Plus the development environment and available widgets make it easy and fun to program. I don't want to spark a religious war about HTML vs. Flex, so I'll leave that there - it works for me and my application and customers.
Second, and more important, was that it balances the processing load more towards the client which means my server architecture can be optimised just for serving the content and persisting the data. Most of my business logic has migrated across to the client. Having spent many years in classical architectures I think this is a huge step forward, but I can already her a chorus of disagreement about that too.
My word of caution about Flex comes from needing to adopt the right architecture for your client code. It is pretty easy to create a huge and badly performing app with Flex if you get that wrong. Make everything event driven and apparently asynchronous and you should be OK ('apparently' because the Flash player is single threaded). And that is downside 1, the single threaded Flash player sometimes causes issues.
Downside 2 is perhaps more serious and that is locked down desktops in corporate environments. Quite often your target audience won't have administrative rights to their computer and will have either the wrong flash player or none at all. This is particularly true in public sector organisations and the military, so if you are heading there I would test carefully the presence of Flash amongst your users.
Other than that I heartily recommend Flex. It's also a great thing to have on your CV!
HTH
Flex has no inherent scalability problems, however if you have a graphic intensive application, proper serving of these resources might be a problem, but that has little to do with Flex.
The only note-worthy and likely platform you won't be able to run on is the iPhone (no flash) and some older non-flash mobile devices (although most support Flash-lite nowadays)
As for alternatives, if you are Graphics heavy, and don't mind the iPhone, then Flex is good if not best cross platform solution besides using pure HTML technologies, the trick here is HTML alone can do 99% of what Flex can do, but if your App requires the missing 1% then you're out of Luck, also Flex will reduce crossplatform and most browser compatibility issues. So it might make your work more productive.
Silverlight 2 is an alternative to consider. WPF if you're looking for something with offline support.
Yes, the scale and type of project
fits.
Immaturity of frameworks and libraries you might depend on. Immaturity of IDE's.
Silverlight, JavaFX.
Flex + AIR is probably as good a tool as Visual Basic was; it may be a better tool for having a much more flexible programming language and having free development tools, but keep the limitations in mind....
The main limitation I've seen from working with it is documentation. There seems to be not enough documentation, not good enough documentation, and not enough high-visibility work on it in the community. (This is coming from years in .NET; I've been constantly upset with how little MSDN says about methods but generally able to deal with it by finding the most useful blog posts.)
Other possible development platforms would depend very heavily on the specifics of the project. Web-based platforms bog down in deep, stateful interactions with data sets (even with nice AJAX libraries), whereas maintaining client-side installations of any thick client program (say, Flex + AIR) might be overkill if it's just a few CRUD forms.