Every once in a while I’ll hear people say something along the lines of “well that’s for web sites, but it’s not really relevant for web apps.” That implies there is some kind of line that separates the two. Different needs and rules that change the game and alter the conversation around them. Is it true?
The new poll up in the sidebar asks this question:
Is it useful to distinguish between “web apps” and “web sites”?
I’m asking in a very broad way. Is this a generally useful distinction to make that will help conversations and blog posts and conference talks and thus alter how we think and work on the web going forward? It’s a boolean choice to make the results more clear:
- Yep. They are different things with different concerns.
- Nope. It’s all just the web.
Food for Thought
A restaurant site that displays hours, the menu, and photos. That’s a web site right? But what if you add an interactive map for directions. Is it a web app now? Or a web site with an embedded web app? What does it change? What if you could make reservations through the site?
Is the distinction as simple as “you log in to web apps”? What if you could log into a blog site, but the only reason you did that was to leave comments without having to type your name every time (and for spam protection). The site was otherwise just full of articles. Is that a site or app?
Is the distinction related to “you go there to browse” vs. “you go there to do stuff”?
Are sites all about content, while apps all about performing actions? What about a newspaper website with a paywall, customizable subscriptions, and re-arrangeable modules? Certainly a newspaper site is about content, so what does that make it?
Where do social media apps fall? How about sites where you build things? Online photo editors? Accounting apps? Bank software? Does “content” generally mean public content or can it refer to user generated or private content also?
Perhaps there are more practical differences to focus on. Perhaps sites have lots of navigation while apps have less. Perhaps sites need to assist more in search and discovery of content while apps less-so. Sites might need to consider things like Responsive Web Design more seriously, since it’s open and the traffic could come from anywhere. Whereas on apps, it’s more reasonable to ask someone to use specific software to get done what they need to.
Are sites “easier” than apps? Vice versa?
If there is a gray line, how thick is it? Is it still useful to know where you sit on that spectrum?
I believe that it is not useful to distinguish between the two, but there are times when it is useful to be able to tell whether it’s a web-app or a website, mainly when you want to see where it’s going in the future (only important for developers and investors).
Interesting point about looking at the future of a web property from an investor’s point of view, but I disagree that it’s not useful to distinguish between the two.
Categorization is a fundamental element of what we do as humans and helps us rationalize and understand our environment.
Just like language, there are nouns, verbs, adjectives etc. in the web world.
Humans are categorization machines because categorizing helps us to rationalize our world. The great thing is that category definitions can change. Before large well-known apps like Facebook, “web app” meant a native PC/Mac business app that was ported to the web. Now, it’s a more general term as people’s awareness grew.
We categorize SUVs and XUVs. vans and minivans (same, aren’t they?), sedans and hatchbacks, sitcom and romcom, yellow labrador and toy poodle, etc. because we immediately understand a general set of properties from it.
We do this because they help us to fit a set of generic properties to that object. It’s a form of mental shorthand than only humans do. It also reduces mental weight and speeds up mental processing.
On the other hand, we don’t categorize when the category doesn’t add any important information.
For example, if you tell someone you’re enjoying reading Tom Sawyer” are you reading it in paperback, hard cover, epub, mobi, html, pdf or maybe even audio book? IT doesn’t matter, because the content is what you’re reading.
Could you argue that on the web, it’s all just html, css and javascript… so they’re all the same? I don’t think so. People aren’t consuming html, that just happens to be the machine that makes it possible.
The question is: Does categorization of a a web property allow us to make better sense of the web around us? Personally, I think it does and to be honest, I expect to see even MORE categories as the industry matures.
@Armstrongest, That’s why we humans create so many dumb stuff too.
Check this post out for a clear example.
That example is a good example of how we tend to categorize and how categorization is helpful. While someone may wear multiple hats and roles, those titles take on a general meaning that quickly gives you a sense of what they do.
When the web was shiny and new, Web Master was apropos. People (especially those doing the hiring) didn’t know enough about the web to categorize any more than that. They just know they needed someone with a mastery over computers and the ability to turn the codez into something that will work. It’s likely that it was a self-title profession as well, probably influenced from game master as in the early days, many who were into gaming were also into programming and the like.
Web site and web page may one day become outdated. In truth, web “pages” are closer related to ancient scrolls than paper (at least how we think of paper in the codex form). Web sites are being replaced by web properties in some circles. No one talks about going to the twitter web site, they talk about tweeting, or “using twitter.”
I believe the line is there and should stay as it is since some stakeholders who does not possess necessary technical knowledge to estimate cost and time requirements would otherwise abuse the term website by setting unrealistic goals, thinking browsers do the hard work.
They should make all sites responsive! … give people the best of both worlds :) … at least it works with all mobiles regardless whether it is an iPhone, Samsung, etc … Since you can’t use these apps on either device.
The distinction may only be useful for the people creating the Web. I am a developer and I have built many applications and started out working on the desktop. I have now been building Web sites and Web applications for a number of years. When I am asked by a client for a new Web site I primarily think of static content if they ask for a Web application I am thinking of some server-side coding.
For the users of the Web the distinction is moot, they use WWW and regardless to what it does before they get to see it, what they get is html, js, css (yes there other bits) and that is the Web and they aren’t even bother that it is html, js and css all they care is that the browser returns the site requested by the address.
So I feel that the distinction is useful but only in the right discussion with the right company. Explaining these differences to my mother would be a waste of time, to her it’s all just the Web.
I think the line is fuzzy, but it is there.
Jeremy Keith nailed this several months ago.
http://adactio.com/journal/6246/
“I think there’s a much more fundamental question here than simply “what’s the difference between a website and a web app?” That more fundamental question is…
Why?
Why do you want to make that distinction? What benefit do you gain by arbitrarily dividing the entire web into two classes?”
To be or not to be! That is the question..
While Jeremy’s argument is very well put and I concur to some degree, I have trouble putting Gmail, a Tumblr blog, a retail site, and a local business site (hours/address/etc) all in the same category.
I think the distinction has become narrower in the last years as web browsers advanced to more standard support and to higher performances, but there is a reason for a distinction.
Many web applications are developed for enterprises, which may have an unusual pool of web browsers (older IE above all [sigh], or in some fortunate cases you can count on the latest version of Chrome).
Web sites are open to the great public, and aren’t based on such details.
But, IMO, the main difference is that web sites serve content, while web applications serve data. And no, it’s not the same thing.
He also says:
This is spot on, and is true for both web apps and html5. I was recently shown some work by an agency (by our marketing department) and they were really excited about creating a “html5 webapp”. What they were proposing, was an interactive website like everylastdrop.
The agency was clearly just using the term “html5 webapp” to impress our marketing team. It made me chuckle.
I think there should be a distinction.
From a consulting point of view, if you are putting together a 5 page website the browser is more of a document reader at that point, but if you are putting together something with dynamic data and user input a site becomes ore of an app and should be thought of that way when building it.
I don’t think there is a difference for users. Users visit the site in the browser and accomplish tasks, be it finding info or engaging with an app.
However, I can see the argument made for a difference between the terms when you are dealing with the designing/creation/maintenance.
Web apps created for a particulary porpuse like a videogame, an editing software or whatever.
An interactive map for directions on a website not an app, just an interactive part of the site.
Examples: wunderlist, do.com, mailchimp (with the new interface yes, it’s a web app!)
These softwares run in browsers, use chrome extensions, and the look and feel entirely as the same as offline apps. Or more simple: they took away the traditional site features.
You can see the obvious differences in the structure and in the inner logic.
If it requires JavaScript to work then it is a web app, otherwise it’s a website.
:)
You can make a lame-o app without JS. Slow, but possible.
Unfortunately it usually works the other way round: developers think that if they call it a “web app”, they can forget no JS support.
I’m not saying I think everything should work without JavaScript. It’s a business decision: it limits your user base (very slightly), just as assuming canvas support limits your use base, and your project brief & goals will determine whether or not that’s acceptable.
But in my experience, once a developer decides “it’s a web app”, progressive enhancement and accessibility get thrown out the window at the same time. These things are still important, even if JS is required for core functionality.
Scott said “why does it matter?” and really the answer is “because it lets me be lazy if I can say it’s an app”.
If it doesn’t work for me on my device, I’m going to be pissed off no matter what you called it.
Stu has an excellent point here. Obviously not all developers pull that move, but I’ve seen people call something an “app” and then say that in order to work it requires some modern feature, which leads them to only design for people with all the most modern features.
I guess in some ways this is progressive, encouraging users to get on-board with the new technologies, but I think it brings up why we should worry about creating a divide between “web sites” and “web apps”. If there is a difference, it’s not that web apps are only available to a subset of users and we can just forget about everyone else.
Like I say, this isn’t exclusively the distinction, but we want to be careful not to drive that wedge any harder.
So a button hover/rollover would be considered an app? … hmmm
Only javascript rollovers. CSS-based rollovers don’t count.
I find it useful to differentiate between web sites and web apps when talking to a client or presenting a project in general. The main difference to me it’s the way users access it. There is still some difference in what users expect from an app (action driven, yes, even if it only means reading a list of news items) rather than from a website, more heterogeneous in its content display.
I think another angle to consider is the engagement and time spent on a web app/website.
How many people spend more than 5 minutes in a two-way engagement with a website? Not many.
How many people spend more than 5 minutes in a two-way engagement with a web app? My view, considerably more.
Websites, from my experience tend to advertise something whether its a product, a person, etc. They put a message out there and ask for little interaction. Web apps almost work the other way round. From initial login they seek engagement, they want a two-way interaction with the user.
So with this in mind, what is Amazon? Is it a website or web app, or something new altogether; a Websap.
Amazon is neither. It’s a Web Store.
I think we’ll gradually migrate to words like this to describe web properties. We’re already doing things like web-based IDE, Web-based TV.
Web Store. Web IDE, Web API, Web Portal.
I would say it’s deff a web app and a pretty complex one at that. Check out this link its pretty cool stuff.
Check this out!
I would say it’s deff a web app and a pretty complex one at that. Check out this link its pretty cool stuff.
–> Highscalability.com/amazon-architecture
If I am expected to complete a task & I will return regularly its a web app, if I’m just there to read information and do simple tasks its a website.
It’s a tricky subject. I was thinking about the same thing, but I haven’t spent much time trying to define it, I just pretty much know when I see it. When I hear “web site”, I think of a presentational site, something that’s primarily meant for looking. On the other hand a “web application” would be something like Dropbox, where I can do stuff, alter the database and similar. I guess web applications are usually tools and web sites are usually presentational sites for companies. Both of them can be, and usually are, mixed, but a web site with an app in it is still a web site, and vice-versa.
I’m not sure there is an advantage in making the distinction to the actual client; but I think it can be useful for the web designers and developers building the thing.
To me, “website” implies that the work needing to be done will be primarily on the front-end between web designers and graphic designers. There will be theme design, probably jQuery or light JavaScript and there may even be a database, but it’ll be in something like WordPress where a lot of what we call “web development” is automated or taken care of for us. Here I’m thinking… “What should it look like”?
On the other hand, “Web App” implies that the developers will be a lot more hands on. We’ll still need the designers and front-enders to do their thing, but we’re looking at custom back-end development, maybe some Angular.js/Ember.js/Backbone, maybe even dedicated database engineers. Here I’m thinking… “How should it function”?
The two words start me down two different rabbit trails mentally as far as what tools I’m going to be using/needing to build this thing and where my priorities should be.
But to the end client? It’s all just a website.
I’ve always seen it as a matter of purpose: If its primary use is to perform tasks (Gmail, Dropbox, Remember the Milk), it’s a webapp, and if its primary use is to provide information or content (Restaurant menus, news sites, and even search engines) it’s a website. Obviously some sites will serve both purposes, but generally one is obviously the “main” one. Even something that is entirely interactive, such as Google Maps, is only interactive for the sake of helping to display its own content. Even so, I think it’s more of a spectrum than a solid black-and-white classification. Something like Feedly or Facebook has aspects of both, and it’s not really reasonable to say it’s just one or the other.
That said, it doesn’t really matter in the long run. When you’re building anything for the web, the goal should be to create the product that best serves the goal you have in mind. Once it’s finished, it could be a site or it could be an app, but making that distinction while development is still active simply serves to limit the potential of what you create. Let your webapps/websites speak for themselves, and fall where they may.
I’m not sure I agree completely, it’s that blurry line territory. But this is about where I draw my line. Close enough anyway.
Unlike some of the other commenters I do think there’s a difference in how we present it to the client though. We should be discussing, sensibly, with the client the implications of what they’re asking for and how to deliver it and other ways to deliver near alternatives that may suit them better.
For example, does the restaurant need a fully featured app that does a million mapping things to show directions? Or actually, will something that shows a static map of say a 100m around them, some written directions to major road, bus, underground stations or whatever is appropriate for the city they’re in and offers a facility to download a bookmark to your smart phone so you can your own directions suit them better? (Which clearly puts it back to being a site, not an app.)
Probably the only certain difference is that when you say “web app” it’s presumed to be more javascript involved :)
This is irritatingly abstract, but I think the main difference in my mind is the mental model that you want a visitor to take when using the site/app. There are still design and functionality conventions that differ between desktop apps and in-browser websites. By adopting one of those paradigms to drive a project, you’re helping visitors setup expectations for the site the moment they enter.
I’m not entirely sure there is much difference between the two. The difference seems to get less and less clear as time goes on
Yep. They are different things with different concerns.
The difference, to me, is functionality/requirements. I would not call a marketing website with little to no functionality a web app. But a marketing site could contain a web app. However, it may simply come down to semantics when there is fine line defining what is web app/website.
“Web app” and “web site” are categories. Talking about what they mean requires a quick diversion into category theory.
Classic category theory, which grew out of the work of Plato, held that categories were naturally occurring delineations of entities defined by properties they had, or lacked. However, modern category theories, such as Prototype Theory are more subtle, and recognise that categories don’t really exist outside of the mind, and are much more fuzzily defined. Things can be good examples and bad examples of categories (for example, a robin is usually considered a better example of the category “bird” than a penguin), or can be in the same category despite huge differences (Windows Solitaire and the Football World Cup Final are both in the category “games”)
Most of the work in category theory has been done in relation to cognitive science and linguistics, but it has consequences for computer science as well: Much of programming is attempting to concretely define classes and structures to represent some category of thing, but this is not really an accurate model for human thinking. If you’ve ever tried to gather requirements on a particular business entity, only to be driven mad by the myriad of properties, rules, counter-rules, required properties, optional properties, properties that are always, always required except for these cases where they’re not, etc. then it’s easy to throw your hands up and declare it a failure of the business under examination, but in fact it’s a natural consequence of how people think.
As for web apps and web sites, you’ll never come up with a agreed-upon list of properties than you can use to declare something one or other. There will always be edge cases, and disagreements between people, because you’re not trying to measure something “real”. There’s just matter and energy flying around out there, and the only place categories exist is inside our brains. That doesn’t make them useless though, or mean we should abandon them, as they’re vital part of how we process and filter our environment. They’re a mental shorthand that let us think in an abstract way about the world, instead of seeing every tree, person, car, animal and piece of music as entirely unique.
Fantastic points. I especially like how you finished it. Categories are a mental shorthand that let us think in an abstract way. They’re important, but they are ever changing.
There is definitely a line between the two. Where that line is? Not entirely sure.
But I think most web properties should be both a site and an app. Progressive enhancement. Give me the site, and then layer in appy behaviour/interaction if I can handle it. Twitter is a great example of that.
I believe saying a website and a web app are two different things is accurate, however you can have a web app inside a web site, but can you have a website inside of a web app? To me a web site shows content (dynamic or not) and as soon as there is communication between the user of the site and the owner of the site, or the site allows functionality that makes you productive towards a goal (besides reading it’s contents), that part of the site can be characterized as being a web app. There are absolutely different concerns for both and if it is an internal web application, there are more concerns in one area and less in another.
Just my 2 cents
A web app would be an application that had (or could have had) been running on top of the OS (windows, mac, iOS or Android – you name it), now on a web browser – which kind of become the OS, or running environment, in this case.
Regular websites, even with interactive features, are no more than documents (a powerpoint presentation can be interactive as well).
Bottom line, is what it does that defines an app, IMO, not the environment in which it runs.
In my opinion a web-app would be defined as an interaction on a web-derived platform on which the user receives some tangible output that is directly related to their input. Otherwise, it’s a website.
Therefore:
Online Shop: Web-app (user receives product)
Restaurant Reservation Booking: Web-app (user receives food, eventually)
Online Newspaper: Website
Social Media: Website, until user crosses communication channels to receive products, invitations etc. (hence Web-app)
Online Banking: Web-app (leads to user often buying products, eventually)
Accounting Application: Web-app (same reasoning as Web-app)
etc.
Some of these links are very tenuous and I would like to see something more solid.
I think the main distinction is the audience. What you call it is probably less important. Is this a crawlable resource, or something personalized for your consumption. There are lots of places on the web that service both.
Facebook is very app like, but some of the content there is very clearly for discovery and information.
Dropbox is also app like, but most of the content is for a single user.
“almost every blog ever” looks like a site to inform and be discovered, but are largely diary entries that no one else will ever be interested in.
If you are speaking with a customer, this distinction is mostly helpful in understanding if they are advertising (in the purest sense of the word), or if they are facilitating something. You can do both, but most people wanting web work done are trying to do one or the other from my perspective.
There is one major difference, navigation. One is inside a browser, complete with back button, etc. The other needs to have that taken into account when deciding how to let people move between screens. Also, I think whether to do one or another depends on the state of the technology and your audience. I would prefer websites and have no apps at all if possible. Using a website presents a lot of advantages in terms of keeping up with the latest version, being able to advertise your site, etc. For best possible experience with more complex certain types of interaction, apps are the way to go until browsers catch up.
The fundamental problem here isn’t “Is this a web APP or a web site” the reality is.. what is a site? what is a app? its the same thing.. you are going to a location where there is something presented to you. What people need to start understanding is that a simple portfolio or contact form is a web app. its just a basic webapp with minimal logic and may be broken up into multiple views. web apps are just smarter websites.. thats all. eventually they will all use some MVC, html5 and history states and soon all web apps will be websites and sites will be webapps and we’ll stop breaking things into technological categories and start breaking it into genre’s. Social, eCommerce, Informational, Entertainment.
just like movies. is a black and white movie a movie, is a 3D blueray animated film a movie? they are all movies.. just different genre’s.
Find the difference is important for me and my clients as I charge one amount for website design, updates, and maintenance and a different price for a web app.
I think that the only thing that diffs between web apps and web sites is the audience! So it’s all the same in same way.
*same=some
It’s interesting that we, in web design and development, forget that there is an analog to the internet in the form of paper publishing. For centuries we’ve been pouring information into digestible formats that cater to the needs and uses it is put to.
While the internet has changed almost everything in the way of information dissemination and acquisition it hasn’t changed the nature of discrete information as much as it’s changed our expectations of how it performs.
“Web-app” vs “web-site” is like asking what this information is used for but why those two only? Why not, web-game, web-magazine, web-brochure, web-journal… there is obviously a valuable difference in the classification of intended use but prefixing “web” to anything is a bit of an anachronism at this point. Sure, our clients and employers will speak in this weird vernacular for a decade to come but shouldn’t we be moving on?
The entire “internet” is a “web-app” but more importantly it’s information and that means it has a use and a format. Manuals, magazines, journals, comics, dictionaries, handbooks, pamphlets, brochures, correspondence… The only difference between now and then is we expect these things to know about what they’re filled with and we expect them to point us to what will help us understand them better and if we’re not expecting that now just wait…
A great example for both sides is Pinterest. There seems to be little relevant difference between the mobile site and the App. Except…
Performance:
Since the App would be OS dependent, is there a performance reason to bring it here? Buggy apps are the #1 turn off for users, a buggy media query would be less likely to occur. Mainstream sites seem to push the use of the native app on their mobile sites, however the user usually has a choice. The media query designated for the device’s screen width or download a native app which clearly is optimized for high performance on this specific device.
So,** it seems to me that native performance needs/wants and your business model** are the two factors to making the jump from media query layout to device application.
We humans sure like to put things into their proper category. I see no reason to distinguish the two.
To me, I tend to think of something as an app if it requires a non-trivial amount of code to provide a functionality that is centered around user interaction. Otherwise, if the purpose is to present content without much user interaction I tend to think of that as a site.
I’d say a static page would definitely be a “web page” but not a “web application”.
But a “web page” that actually does something, eg allows you to buy something and has associated services related to that like payment or delivery, is closer to a “web application”
I believe a newspaper is not just about content, but delivering this content on the web. It’s not the same as to say a restaurant that wants to advertise it’s menu or it’s working hours and it’s location. If the same restaurant wants to deliver food online then we would certainty not talking just about pizza advertising anymore.
Nowadays, to me it seems that there is no line at all between those twos, until the day that more and more mediums, accessing those sites/apps will emerge. Would you access a web site on your Google Glass, or on a smartwatch or on your car’s LCD, while driving to check for an address of your favorite restaurant? So until then there is no need to make that comparison.
What do you think?
For the purpose of this definition, let’s assume “primary content” is: the content the majority of people come to you sure for.
With that said, I believe it is easy to to distinguish the two by saying:
it is a web app when the “primary content” is created by users.
it is a web site when the “primary content” is created by a curated set of admins.
Webapps:
One page with client-side routing (history API).
Heavily JavaScript driven.
Backend-less? Can be simple static files, plugged to a web service.
Offline support.
We all Remember old flash days, at the time we had websites with embedded flash parts or even full flash sites, now replace the flash app with web-app. This would make it easier to distinguish between them.
I would say if you have a page with many live components/panels on the page go with the web-app, if you have a site, where users navigate through the page faster then usual or there are a lot of similar pages with the same structure(a quiz or poll site) go web-app …
I think there is a clear difference between an app and a site
A webapp is user content centered : <br/>
this is a place where user can create / edit / put / delete content
A website is owner content centered : <br/>
this is a place where user can consult and maybe interact with content created by someone else.
We built websites in the past.
But now we have harnessed so much power from technology that our websites are now web applications. However, in their core they are alike.
In other words, website / web app… as we say in Spanish: Es la misma puta pero mona.
Both fall under the same category when viewed commonly. Both are sub parts where the decision is made according to the client requirements. whether client need to display his data(content) , or allow some transactions to be carried out.
So http://siteapps.com is a website or a webapp that offer apps for websites (or webapps)?
I agree that there must be a clear line b/w both and it is only helpful for web designers and developers but not for the visitors. I can see no one could explain it well. But you can take an idea after going through chris’s article and comments. Comments are very informative always.
Thanks
I have read quite a bit on this subject, and have heard it come up in conference speeches a few times too.
I feel that there IS a difference.
The vast majority of sites are SITES, but there are some situations where App is a more appropriate description:
In my current role, I develop business applications that are used by companies that have bought our software. They are not accessible via the internet. They are used for a specific purpose, and could work just as well as a desktop application – the browser is just how we get it to the user.
Sites like icomoon.io: uploading SVGs and being able to export them as a font after setting metrics and options is certainly an application. Again, this is something that can be done using Grunt.js on your desktop; the site is just how you get to it.
I think most sites out there are just that, sites, web apps for me are what you visit to do specific stuff, like the accounting software, photo editors and the like you mentioned or iCloud for example…
All the web apps I have worked on in the last 15 years have all been for internal networks not used by the public.
Often this means the apps are designed with the one and only browser, type and version, that is allowed within the company.
Also the functionality is often very bespoke making design very challenging for intuitive interfaces. This also means that one term/word/icon can be understood or define a great amount as it is something understood and used dailiy internally.
These things I think you don’t have/find/use in a website hence the divide. If I am building a website I wear a completely different hat to that when I am building a web app.
My current favourite definition comes from a tweet by Mat Marquis ;) “Webapp is a website where the developers responsible wanted to require JavaScript”: https://twitter.com/wilto/status/372080088898367488
if page-never-scrolls then webapp else website
(80% accurate)
I think anyone who’s built a fully responsive application and a fully responsive marketing site will tell you that, yes, there’s a huge difference between the two.
There is definitely a line, though the gap gets narrower each time. In my experience I find mobile users are more likely to repeatedly go to an app installed on their phone than to enter in a website address or make a bookmark. The benefits of the mobile site being that they don’t have to install the app, and you don’t have to create and market the app for each type of phone.
I think we are still at the point where both have value, I would still create a mobile-first website, as well as an app so that users can choose to install the app or use the website at their own preference.
I think this is like asking if there is a difference between apples and fruit. An apple is a kind of fruit just like a web app is a kind of web site.
I think there is a difference but it’s more like the difference between black cars and white cars than the difference between cars and planes (and just noticed the fruit analogy above). The most common usage of the ‘Web App’ tag that I can think of is as an excuse for not implementing accessibility, which I think is totally wrong. Shops in the UK don’t get away with anything by being a special kind of shop so why should websites?
Actually until recently I would have always said separation, but recently with b00k.it we are attempting to buck the trend just to save on costs and try to ensure application responsiveness and similarity of look and feel…
Still not sure how it will work out, as apps are generally more full-featured and static in purpose, but if it is just an authored view, I can’t see the harm, which is why we are trying…
I think the simplest and crude divide is that if a web thing (or thang) can be printed and still offer the same results is a website. #Sarah’s apple is a fruit a fruit is an apple … a web apps is a website (or part of one).
Of course an app does not start with a simple rollover that can’t be printed, that’s like ink types… shinny vs mate.
Is navigation an app? not really, that’s like saying go to page 15 to contact us.
Animations are like kids popup books or ‘motion cartoons’. [please no comments on printing an animated gif ;)]
Is a form just a fax replacement or is your address saved to a database? “Enter your name here for a quote” or “Register to receive newsletter and promos you have selected”
Apps can be simple and complex. Talk to my co-workers that spend a couple of years building an app vs me building a form that collects comments in a database…
The line can be drawn but it’s long, each situation requires a bit of analyzing.
Generally with web apps the user works with data and on websites users consume data. Because of that you should be more concerned about SEO on a websites. Also, developers don’t need to worry too much about SEO on a web app so they’re free to use stuff like client-side templating and such.
Browser memory leak is a much bigger problem in web apps (especially enterprise) than web sites. Even some of the best JS framework has problems especially with IE.
actually IE can handle JS much faster than Firefox and co … :o
IE8 and 9 are crap!
For me, the biggest clue is printing – if it makes sense to print several pages, and I would expect the print-outs to look the same for everyone, then its probably a web site; whereas if every print-out from the same URL is different, then its an App.
So you’re saying sites with lots of JS that change the page significantly are web apps? I’d disagree since any site can have javascript and it’s not necessarily a web app, though that could be a hint.
Anyone know the earliest mention of “web app”?
Web apps and sites are slightly different, e.g. web apps in Chrome/ium can now be opened by default chromeless (without having to set the option) with new background scripts. And Unity web apps in Ubuntu can be controlled with parts of the OS, for example YouTube vids can be paused through the sound menu, the same place as Rhythmbox music can be paused. There is a lot of confusion between web apps and the web, but there is a thin line.
One clear difference for me is defined by semantics. Website semantics should be similar between all websites: header, followed by a main content section, often a sidebar and footer.
Web app semantics can only make sense to itself as a self contained entity, so the structure doesn’t have to be related to a standard.
That’s my best attempt at a clear distinction between them!
I would say that a web apps are just a type of website. There are certainly principles that apply to all websites, but once you get into a web app classification there are additional things to consider. For example, a marketing website for a company is going to have a very different objective than something like MailChimp. Often times, web apps also have a marketing website associated with them, sometimes not.
A web app, is basically the concept of taking something that previously would have been desktop software, and putting it on the web. It’s software design using HTML, CSS, Javascript and Server Side Languages like PHP, Ruby, Python, etc. Software is definitely a different ballgame then say, a portfolio website.
The term “interactive” premise is kind of a ambiguous. Is a drop down menu not essentially “interactive” ( it shows info based on user actions/events)? What about this comment form ? all the AJAX stuff from 10yrs ago ? Dare I say Flash? Is facebook.com a web app (even w/o the games) ?
I really see the term as as a buzz word ( like ‘web 3.0’). I am also tempted agree with Matt G. I think web apps are just more self absorbed and encapsulated code. That begin said I think we are surrendering to the non techies.. a client can now say: ” I don’t care about semantics… build me an “app” to display my ‘content’ .”
Web apps are also given license to have technology dependencies. IOW, you might not be able to see any content unless you have: HTML5, canvas support, local DB, etc. With a web page, worse come to worse you could get the basic content by actually TURNING OFF everything, which we used to have debacles such as “content first” vs “nav first” and separation of content and style. Web apps are all or nothing.
Web Apps are Web Apps and Web Sites are Web Sites. There’s no reason why a website cannot use a web app to to allow user a wider interaction with their site. So basically there isn’t a clear border, but why should there be? To begine with, the whole idea of a web app is that it’s available in a website.
The following is all how I see it. And the distinction quickly becomes very fuzzy to me.
Web App : The main content is CRUD by the user.
Web site : The main content is R by the visitor.
The usage of user and visitor is deliberate.
Comments, maps, ordering system are “just” a byproduct of the main content.
Here’s where it becomes fuzzy :
But comments are a Web App to Disqus, LiveFyre etc.
Maps are a Web App to Google, Yahoo/Bing etc.
In an ordering system the main content (which you place an order for) is created by the site owner. So to me an ordering system is a byproduct.
The fact that you place them on pages of your site, doesn’t mean the whole site or those specific pages become Web Apps.
To me Web Apps are more like Desktop Apps jailbroken from the Desktop.
Simply, any website that make you created your own data, it should be regarded as web app., while, those you have to get data from, they are websites.
For example: CNN is a website, but Chimply is a web app.
imo every website is a web application
web application is like a category which includes:
– websites that show data (information)
– websites that change/output data (information) only for (custom) you
but anyway imo it’s not worth to discuss it perfectly
Definitely a spectrum – like many of you have said.
_I think we can all agree that something as rich and complex as GMail, Facebook, or GoDaddy lies at the web-application end, whereas something simple and display-only like “Bob’s Restaurant” lies at the web-site end.
Everything in between is categorized as necessary to convey something specific to a specific audience._
I’d also say that everything is implicitly a web-site until explicitly referred to as an app.
And for .NET developers, the difference is technical and very black & white.
It’s fuzzy :), Even though I just entered in this area few years before I can say that there is no difference for sure.
Even though distinguishing the two is kind of pointless, the semantics are interesting. I look at it like this: A website’s purpose is to communicate information, while web app’s purpose is to perform a task. A website could be comparable to a billboard, while a web app is comparable to the system that holds the billboard. But in the end, almost all web properties today are a combination of both, so it’s just kind of ambiguous to discuss.
I wouldn’t say (kind of) pointless.
There is a point. And it’s an important one : Explain a client why they are charged many times over for a bespoke Web App.
I/You/We must distinguish between the two, even though it’s difficult/fuzzy.
Web Apps have far more sophisticated back-ends than regular websites.
(There are more.)
And therefore (most of the time) Web Apps require many more hours to design, plan and build then websites. Even with cookie-cutter Web App bits thrown in.
These are just 2 points to take into account when you have to explain to a client why their Web App is going to cost so much more than the website you designed for them.
Is There a Line Between black and white?
Yes… It’s very large and grey.
Clients pay twice as much for a web app. So I only make web apps.
IMHO, It’s about data. If the site saves/stores/changes your data, then it’s an app. If you’re just reading (and even interacting) then it’s a site.
You read (and interact) with a Web App too.
Yeah, but you don’t save/store/change data on a webSITE.
For the record, I agree with most people here, we’re arguing semantics. But if I were required to define the difference. I’d say it’s data manipulation.
I’d say it’s not about data manipulation. Technically, even setting and fetching cookie data in a browser is data manipulation, and that’s been done for a long, long time. There were some websites back in the late ’90s and early 2000s that did some pretty heavy data manipulation (CRUD), but they weren’t web apps. Web apps, to me, are all about the client-side experience, and have nothing to do with what’s on the back-end (indeed, you can technically have a web app with no dynamic backend whatsoever, just localstorage, offline app manifests, etc.).
@Michael Chang
Not by the user/visitor, but by the Site/App owner.
You took the “Web” out of “Web App”.
@Robert
By that logic, no user ever sets data themselves (meaning no user ever issues, say, their own SQL to do CRUD). Take the example of a button which, when clicked, sets a site’s color scheme (light/dark). I can click on it and have some JS set the preference inside a cookie. Yes, the app owner wrote the code, but the user invoked it.
I don’t think so. Is an offline web app no longer a web app? A web app or website doesn’t have to have lots of back-and-forth HTTP requests to be called an app or site. It’s about HTML and a user agent capable of rendering said HTML, as I see it. HTTP is merely a transport to facilitate the shuttling of HTML; it’s not required.
@Michael Chang But to me, for an App to be called a Web App, the user creates the data.
To me settings cookies, or changing the color of whatever, has nothing to do with Web Apps.
(Also, the colors are most likely pre-determined by the site-owner to protect the design of the Web Site or App. Same goes for the data which is collected through cookies. You do not determine what gets stored, nor create it.
With a Web App the user creates/maintains the content.
An App that gives you all functionality off-line is not a Web App (even if it lets you upload/deploy your off-line created/changed data/artwork later). Then it’s just a typical Desktop App with a web interface. Like a typical IDE with DVC/FTP. (Yes there are IDEs implemented as real Web Apps. But then it’s : no Web, no IDE.)
One of the characteristics of a Web App is to store and keep business logic, and data centrally on-line, instead off decentrally off-line (on anyone’s local HDD/SSD).
We are probably never going to agree. It’s also not important that we do. Peace man.
It’s not useful to distinguish the both, but in my eyes a website is a “normal” site, where you click, wait, and something happens, while a web-app is a AJAX-powered site where everything is done through JS.
While the first is also supposed to work, when JS is off, the second isn’t. At the second I also see problems for accessibility. More and more clients may demand a web-app these days, but the choice is a normal website. It may not be this responsive and “flashy”, but it works across a greater wealth of devices.
For me, a web app, in contrast to a website, is like a desktop application that uses a client-server model. In addition, a web app is typically a private space (in the sense that one must authenticate in order to access it) that is often customizable by, or personalized to, the user. A web app distinguishes itself from a website because it throws away the concept of a “page”; the closest thing to a “page” in a web app might be called a “view.” Why is this? Because in a web app, the DOM is never reloaded. Instead, certain elements inside the viewport are contextually replaced. A web app, at least in 2013, makes more aggressive use of modern or bleeding-edge technologies (CSS3, HTML5, and other technologies out there that may not yet have specifications behind them).
To use an example: I’m currently in the process of writing an e-commerce engine. Said engine makes available both an administrative side and a public side. The private, administrative side is a web app. It’s all AJAX-driven (and may eventually make use of Websockets). It looks and feels like a desktop app, and it was designed from the start to be so. The public side, where customers shop, is mostly a website that borrows certain concepts from web apps. It borrows too sparingly to be called a web app.
Okay, last try: a website is like a corkboard in an office setting where announcements, ride shares, lost+found notes, and other such things are posted for all to see and respond to. Whereas each private office is like the customized, personal space that you often encounter when you login to a web app.
There are so many angles from which one could view this comparison. I’ve offered a few, but each person has his/her own.
Some example web apps: Basecamp, Google Docs, iCloud.com, HTML-based point-of-sale systems, HTML-based healthcare/EMR systems.
I’d say that web apps are a type of website. Interactivity is nothing that NEW. I mean, even flash back in the day provided some level of interactivity above and beyond most other websites.
So I’d say anything in a browser is a website, and a website designed to function as software is a web app.
And a piece of software, an application, downloaded to a mobile device is an app.
I definitely think that web apps are becoming more and more standard, though. Maybe one day all websites will be web apps.
I think the idea of web-apps derived from web-services and somewhere along the lines, it got blurred by somebody trying to defend their skill-set and still be relative!
A web-app should provide a specific service or data set, like a weather stream whereas a web site provides much more information…sort of like a site is an Encyclopedia and a web-app is one chapter or entry……so a site can include web-apps, but there is no reason to make ones resume a self-contained ‘app’ that retrieves static information just to be an app.
The short answer is “Yes Of curse”
“Yep. They are different things with different concerns.
Nope. It’s all just the web.”
Aren’t we just talking about marketing in the end ?
The real problem being the ultimately heterogeneous nature of the tools in my opinion : if it is dificult to define for developpers, how is it then for any outsiders ?
That sums it up… an ios/android app being more accurately marketable for the only fact that the enironment is defined
Web Site – does not necessarily require interaction from anyone. For the most part a website is for consumption and dissemination of data, content information. The interaction is one way – website to consumer. Where the lines become blurred is in the referencing the web application on a website. When a website that was build for consummation also has an added element that requires interaction from the consummator; that small subsection embedded into the web site is the application and therefore called a web app.
These days’ entire web sections (for lack of a better term) are dedicated to the application, the interaction between the application and the consumer and vis verse. The ability for us to access these web sections use the same protocols as regular websites causing even more confusion between the two. If I use https://www to access yahoo.com and https://www to access the yahoo mail application, to the consumer what is the difference. One is the direction of the content dissemination and the other requires me to do something to get a desired result, i.e. input something.
If the entire websites focus is to get interaction from the consumer, i.e to login, to add content, to gather data or receive data results via inputs, then the entire website is considered a web application regardless of how you access it.
I believe they are different just for that one reason. The question now is for industry professionals knowing the difference inherently in order to develop either, how do we make the distinctions more clear in order to reduce or eliminating confusion.
If it needs a bug tracker, it’s a web app. If it doesn’t, it’s a website.