I've been developing web apps for over a decade now, all the way from CGI to ASP.Net and Struts+Spring+Hibernate. The prevalent architectural style seems to be server-assisted MVC, e.g. Struts, Ruby on Rails, etc. Recent developments lead me to ask if these are on the decline.
Adobe's AIR and Flex
Microsoft's WPF and Silverlight
Google's Chrome and Gears
SOFEA and SOUI
All of this leads me to believe that we're starting to come full-circle after a 15-year distraction kicked-off by the invention of the web. Over this period of time, we've been so fascinated by all the web has to offer that we didn't notice that the usability (and the developer experience) of web apps pretty much sucked in comparison to desktop apps. It seems we're now saying "Screw this! We love the web's benefits but we also want better usability, offline capabilities, and better integration with the desktop!".
All of the above mentioned developments seem to be moving us in this direction of putting the presentation logic back where it used to be: the client. Don't get me wrong, I don't think server-assisted MVC frameworks are going away anytime soon, but I do think they are on the decline and RIAs and RDAs are on the rise.
So, what do you think? Are server-assisted MVC frameworks near their peak?
I agree, to a point - we are becoming are more client-centric, but I think this is because the clients are actually advancing in a standardized way.
We started out with everything on the client - because thats all there was. Then it was client-server, which separated the two, then gradually the client bit was thinned out and pushed back to the server, for one reason:
clients sucked (win95, macos<10, unix X11), and deployment was a nightmare. Deploying a browser was trivial.
Thats changing tho. Air is an easy install, as is .NET 3.5. Air apps are easy to deploy (click here - say yes!) as is a WPF Click-once app. The network is now a defacto part of the environment, not something special that had to be added. A database is something you can embed into a silverlight app (SQL Server Compact Edition), or an iphone (SqLite), not something you have to have a big server for.
and everything has auto-updating, which makes the post-install story a lot better.
I dont think they are on the decline - I think the logic has just been pushed out again, and it'll be pulled back in the future, only to be pushed back out etc.
Silverlight/Air/Flash etc are all very powerful, but HTML + Javascript, which is the basis of the server MVC frameworks, has come forward massively, esp if you ignore the b'stard that is IE6.
Regardless, I'll still be writing the backend for RIA's in a server-assisted MVC framework, even if they are throwing out JSON, not HTML. So while they are no longer the be-all, they are far from dead (or peaking)
Lets clarify something!
MVC is only a design pattern for the seperation of concerns. There is no really relation to server side frameworks.
There is no technical Web 1.0 or Web 2.0 ... JavaScript and Flash were there for years. It's only about social networking, tagging etc.
The server side frameworks are not dead at all. I agree with Nic Wise in case of the bad client architectures/rendering. Can you print a HTML page (every time in the same way)? No, you can't, because every browser(-engine) has it's own representation your HTML description. Only because JavaScript/Flash... are restrictions for a lot of people/companies, the server side processing will stay there for a long time.
Developing "Run anywhere" JavaScript has been a burden for a long time! Nowadays we have Frameworks like JQuery which do this job for you. I've written my own homepage in JavaScript, using EJS (Embedded JavaScript) for the templates/mvc. The old bloated JSP/PHP pages have shown, that differing the business logic from the design is a really good thing.
A bad problem of every web application is to decide, where you save the state of the application! If you choose a bad way, you are not able to scale. Client centric frameworks with service oriented backends allow you to scale very good.
I have been working a little bit with SOFEA/SOUI. If you have an ready framework stack for the most common problems, you'll love it.
Air and Flex are nice, but they bring in a lot of restrictions (Flash/JS...).
Google's Chrome and Gears need you to install Google software at your computer. Who has Gears around here? Gears hasn't established as a wide distributed standard.
If you have experience with Hibernate/Spring and Struts, you sould try Grails! It is nice to develop GWT/FLEX&AIR/SOFEA&SOUI backends and also for the good old server side HTML rendering.
I like SOFEA/SOUI because it isn't such invasive, it offers an investment protection (SOA services) and high rate of reusability. It's also a nice way to move the load from your server to the clients.
Related
We are a small software Development company (<10) mainly in custom made Desktop Database applications. We have developed few Web Applications mainly used in VPN for centralized Query and reports with Flex 4.6, Spring, myBatis, Jasper Reports and Firebird. None of these is hosted on Publicly accessed web server but on VPN accessible cluster of 2/3 Load balanced Linux Tomcat servers.
Flex has been donated to Apache and Future development is geared towards (flaconJS) cross compilation to Java script, then a thought came forward "why not consider matured JS spitting Framework like GWT ?". We studied about GWT, GXT, smartGWT, vaadin, ZK. After reading many xxx vs yyy posts we have shortlisted GWT and GXT for our future data intensive web applications which may be hosted on Real world web servers. Considering our prospective client base we are considering to have GWT/similar for front end using REST calls to backend in either PHP or Spring/java depending on nature of project. We are also expecting requirements of Android Mobile applications augmenting already deployed projects.
Many of the POSTs which we have studied are from 2007 - 2012. Since then many things have changed so We feel that fresh opinions be sought before finalizing the decision. Our capabilities are, Java for 8 to 10 years, PHP never, HTML/CSS/JS never, Flex/spring/mybatis 8 to 10 years, RPC most of the time and REST for a recent project, Database applications in delphi > 15 yrs.
Clients Like Desktop Feel, very much fond of grids, modal popup data entry forms, tabbed views, menu navigation, expects use of ENTER even in Browser based forms, likes to preview reports before print/export etc. etc. We have shortlisted GWT/GXT based on these requirements, GXT demo application ticks most of the boxes. BTW we can afford to spend ample time for learning since we are planning for future development projects.
Please help us by sharing experience, suggestions, alternatives etc. etc. Your comments on this subject are valuable to us. We open to any other viable alternative so feel free to suggest it.
Thanks and warm regards.
Raja Patil
I've got an app that's been started on the Microsoft stack as a smart client (notionally WCF/WS enabled) with a small client app that gets deployed and the rest of the app running in our private cloud. It's only real dependency is internet connectivity, .net 4 and a windows operating system.
I am under pressure to convert over to a browser based architecture for all future development. Based on other web apps I've worked on, I'm concerned that the way that client IT organizations can control the browser, it will cause more problems down the line than what I really want to deal with.
Do you have experience making this kind of decision? What technical factors did you consider when deciding to go smart-client vs. browser? What resources were helpful in making this decision?
My app is a healthcare app targeted at healthcare providers (eg. hospitals), so everywhere I go, I have to worry about the Healthcare CIO looking over my shoulder.
Interesting. Originally I'm from C# winform and WPF Desktop programmer, and later being assigned to do web development. Haven't touch Smart Client yet but I think it should almost be the same with Native app. Based on experience, the technical things to consider are:
Multi browser support
Especially for reporting and graphic processing, without some library / plugins / framework for your component, it will be insanely hard to keep your app multibrowser. Especially in css style and less in javascript.
Client programming(javascript)
You will lose the ability to create controls and animation using C# controls. Instead you must using javascript (jquery or other library) in exchange. Javascript is not fully OOP, and intepret language (no compile error), making it harder (maybe there is some framework like coffeeScript which I haven't yet explore). In addition, it is harder to make since it will need server request / response activity in between the process, which I will describe later.
Request / Response Client-Server Architecture
This means that most process in client will need to request for the server (request for data to display, request to modify the data, etc). It also means that you lose the ability of control event, even if you use asp.net webform (it still need some tweaks for the event to work). However I assume you already used the WCF so this kind of architecture must be that hard.
Security
Don't keep important information such as password, etc in client (hidden field, javascript variable, etc). The concept should be the same with multitenant client, however in browser, user has free access to debug your webpage.
Concurrent and Multithreading
In browser, it is easier for multitab page and concurrent process will be very highly to occur. Your code must able to handle the multi threading for client side. For server side, you can still use your WCF to handle concurrencies.
My 2 cents.
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.
This post is intended to start a deeper discussion on Single Page Applications for the web. There are questions that do not seem to have a clear answer in most resources on the subject.
They are in my mind
Authorization and authentication.
With entire web app being on the client, it may make calls to the server in any of its functions, even those that the user does not have rights to. The fact that the user cannot see a menu, does not preclude that person from invoking java script functions. This is easily handled in MVC app, for example, by using controllers that validate user rights to a specific function based on a cookie for example. However, some SPA apps just use single controller with Breeze or Web Api, which make authorization server side impossible.
Memory management on the client
For small sample apps this is not an issue, but imagine an app with 100's of screens or an app with a single screen that pulls thousands of records over the course of one day. With persistent caching one could imagine large memory issues, especially on under-powered devices with little RAM, like phones or tablets. How can a group of developers had SPA route without a clear vision of handling memory management?
Three Tier deployment
Some IT departments will never allow applications with a connection string to a database located on front end web servers. Every SPA demo I have seen is structured exactly like that, including Breeze or Web Api for that matter.
Unobtrusive validation.
It would require developers to use MVC partial views and controllers instead of just HTML files, which seems to fly in the face of SPA concepts, while it provides a very robust way to easily incorporate validation and UI to support it into web applications.
Exposing primary integer based keys in the url.
This is non-no in OWASP.
As a result, SPA applications "seem" to target areas with few security requirements and small feature sets. What do you think?
Thanks.
#Sergey - I think this is just too broad a question for StackOverflow. S.O. isn't a discussion forum; it's a place to go for specific answers. So while your questions are potentially valid, I don't think you should hold out much hope for deep substantive responses here.
May I add, in the friendliest possible way, that your sweeping, unsupported, and negative statements make you look like a troll. You're not a troll are you Sergey?
On the chance that you are in fact authentically concerned, I offer a few quick reactions, particularly as they pertain to Breeze.
Authorization. In Web API you can authorize at the method level. The ApiController base class has a User property that returns the IPrincipal. So whether you have one controller or many (and you can have many in Breeze if you want), the granularity is method level, not just class level.
Memory management. Desktop developers have coped with this concern for years. It may cause you some astonishment if you've always developed traditional web apps where process lifetimes are brief. But long-running processes are not news to those of us who built large apps in desktop technologies such as WinForms, WPF, and Silverlight. The issues and solutions are much the same in the land of HTML and JavaScript.
Layers on the backend. You've been looking at demos too long. Yes most demos dump everything into one project running on one server. We assume you know how to refactor the server to meet scaling, performance and security requirements for your environment. Our demos are concerned mostly with front-end SPA development. We do dabble at the service boundary to show how data flow through a service API, through an ORM, through to the database. We thought it sufficient to identify these distinct layers and leave as an exercise for the reader the comparatively trivial matter of moving these layers to different tiers. We may have to re-visit that assumption someday. But does anyone seriously believe that there are significant obstacles to distributing layers/responsibilities across server-side tiers? Really? Like what?
Unobtrusive validation. When most people start using the word "unobtrusive" in connection with HTML, they are usually making a point about keeping JavaScript out the HTML. Perhaps that's what you mean too, in which case SPA developers everywhere agree ... and that's why there are numerous "unobtrusive validation" libraries available. HTML 5 validation, jQuery validation and Knockout validation come to mind. All of them are in the SPA developer's toolkit and none of them "require developers to use MVC partial views and controllers". What gives you the impression that a SPA would need any server-side resources of any kind to implement validation with JavaScript-free HTML markup?
Ids as security risk. Really? This is bogus. The key value is no more a security risk than any other data value. Millions of applications - not just SPAs - communicate key values to the client, both in the URL and in the body. It's standard in REST APIs. It's standard in ODATA. And you want to dismiss them all by saying that they "target areas with few security requirements and small feature sets"? Good luck with that. I think you'll have to do better than rest your case on a link to a relatively obscure organization's entire web site.
I have built some SPA applications, ranging from small to large (over 100 scripts and views). Only a handful of them had every view accessible to the public. The rest went through a strict access structure. It was so simple to return a 401 unauthorized from the server and the client just handling the 401 to redirect it to the login screen. Mr. Ward and Mr. Papa put it right. Get out of the Demo mode and try to find solutions to the issues you come across. I have watched John Papa's SPA on pluralsight, gone through numerous articles and applications on Breeze and I have to tell you, none of my applications use Breeze to do queries from the client side, because YOU DON'T NEED TO!!
Moreover, I have only extended what I have learnt and come up with my own way of solving problems. This is not an answer to your queries, but I only can provide a short comment. No technique is perfect and there is no ONE way to do everything. My server side is locked down where it needs to be locked down, my routes on the client side are locked down (if using durandal take a look at guardRoute), my scripts are minified and my images are sprited (if there is a word like that). All in all, SPA is a great technique, you got to find solutions to the quirks!
I am looking to develop a browser-based front-end/client to what is essentially a database-like back-end/server.
The server application will need to access some local hardware I/O and will be logging events to a database (or even a fixed format text file).
The front-end needs to display real-time status of the remote I/O, as well as be able to browse the event log by date. This means that the server will likely need to be able to push to the client as events happen or status changes.
My background is in embedded/firmware, assembly, C/C++, and I have done a fair bit of work with Windows/MFC clients providing UI to devices via TCP/IP, UDP, and serial connections, but I don't have any web based experience.
The number of choices for web development these days is overwhelming, so I am really looking for somebody with experience to point me in the right direction for which technologies/platforms to consider researching. (ie. AJAX, ASP.NET, NODE.JS, Javascript, PHP...)
I suspect providing the information to the front-end will be the easier part, and that the back-end will require two parts (one app/service to interface with the hardware and create a database/file that the other part can access and serve to the client).
What tools/platforms/technologies would you recommend to tackle this, and why?
Any advice is appreciated. (Links to references/tutorials also appreciated).
Thanks!
I would recommend looking at the ext.js framework. This is a client-side framework that is server agnostic that can greatly speed up development. Being a client framework it is based on JavaScript an can talk via AJAX with JSON/XML to server-side systems. It offers a very rich and professional experience and wirth the $595 price tag.
You build most of your application client-side and it can works with almost any back-end. The engine is fast enough to display real-time data and has a strong developer community.
Let me introduce myself a bit.
I have 7 years of C++ (most MFC) experience, 1 year C#.NET and 2 years Java experience.
I know little about web application, what I did and am doing is Windows desktop applications.
I start to do some (minor) (freelance) side projects in the past half year and uses C# mostly as it's more "rapid" than MFC. But seems there's more web projects in this market than desktop projects. And I do not feel good as long as I do not know web development.
So, should I touch the new web filed for me or just stay focus in desktop application but learn more e.g Python, or Frameworks/Libraries such as Qt or Boost?
My gut feeling is that more and more people/companies are moving their projects to the web. My company, for example, has added numerous web applications since I have been there. Another prime example of this is Microsoft (yes, even them) providing a web-based version of Office, their flagship product.
There will always be a need for desktop applications, but I see more web-based projects in the future. It's always good to learn something new, anyway.
EDIT: Oh, and you don't lose anything by being aware of "desktop-based" processes. You may be doing more server-side programming, even if it is web-based. So, in other words, it doesn't hurt to continue expanding your knowledge in that arena, as well.
There will most likely still be a market for desktop applications for many years to come. However, web development seems to have taken over a large share of the development market from what I can see. I would recommend definitely getting familiar with web development as it definitely can't hurt to increase the number of skills you have even if you never stop writing desktop apps.
Since you have experience with C# you might want to consider doing some ASP.NET work. Or if you feel the need to learn a new technology then maybe consider a framework like Ruby on Rails.
I'd really suggest looking into web development - like you said, there are many more web application projects - and you already know C#.NET and Java, and both of those languages have really good API's / frameworks for web development. ASP.NET for C# and Java Servlets/JSPs.
I'd first suggest learning some really basic HTML to learn how pages are rendered, then try to make dynamic versions using the language of your choice. Then I'd learn some other web technologies like CSS/Javascript/some Javascript libraries - then I'd start looking at frameworks that build on top of the basics in the language of your choice.
Oh, and some further suggestions - there are web frameworks that are component-based rather than request-based - you may be tempted to learn these as a shortcut to web development since most claim that developing in them is similar to desktop development. I really wouldn't suggest this - as in practice you really do need to know how the web works at a lower level to develop custom components, include things that the framework doesn't do, or to debug them when things go wrong even when using these frameworks. If you jump right in you can get lost/confused pretty quickly.
Microsoft Office 2010 will have an online version. To me this is a watershed moment for Web applications. Office apps are an important litmus test as once you can do Office on the Web (which has been the case with Google Documents for some time but Office has important symbolic meaning) you can do most things that most users care about.
Desktop apps won't die but I definitely think they're going to take more and more of a backseat.
I'd highly suggest you read How Microsoft Lost the API War if you haven't already. One of the things that's particularly amazing about this post is that it was written in 2004.
I honestly believe that with maybe the exception of OSs and browsers, everything will be a web app within the next 10 years. Having said that, let me clarify that by everything I mean everything that a) involves a UI of some kind and b) can be guaranteed secure.
User-interfaced apps will always at some point need a backend, which will at some level require code that is not being interfaced by humans and not being executed via HTTP. I am always reminding myself that things like 'cat' in Unix are actually programs that the OS is calling, not just a function built into the OS. MySQL won't be a web app (as far as I know), but app that powers web apps. We may get to a point where these apps are fully developed via a web interface, written, audited, uploaded and called all via a browser, but at some level its still running behind the scenes.
On that second point, about guaranteed security, I can very easily imagine a large corporation or government office running 95 percent of their daily routines via web apps, but mandating that certain high-security operations be done on a machine directly interfaced with some sort of mainframe, after passing through the cool doors with the retinal scans and what not. Or simply because they can't risk moving certain mission-critical apps over to the web, from fear of it breaking our losing data in the process.
But with those two things aside, I honestly believe everything will be web-based. With the advancement of Web Services and XML in general, it will be possible to not only access and interact with our data, but to plug our custom apps into another app and extend that interaction further and in any environment we want.
It's like that Apple ad "There's an app for that." Except once people get the real picture, it won't be an app written for your iPhone, but a URL. "There's a site for that."
I recommend learning the Lift framework. It's as easy to use as Rails, and it's based on a statically-typed language for the JVM, Scala. From the perspective of your background, Scala should be middling to easy to learn, and you'll be more likely to be comfortable with it than with a dynamic language.
In my opinion, you have a good chance of picking it up quickly, learn a lot about good practices in web development, and even expanding your programming horizons a bit.