> Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.

That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.

This is also going to vary depending on the domain problem. If you're aiming to make something large and comprehensive, it helps to start "a bit too crude" so that every assumption you make at the start is grounded in the understanding of where you want to go later. But if you're pumping out microsites, a framework automates the process and makes it easier to maintain a large body of them.

> The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago.

I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.

Actually, I wrote a pretty complex browser-based app in 2002. It ran on Microsoft Explorer as it was the only capable browser at the time, and it used Javascript, XML and XSLT to construct a Windows-like UI environment within the browser -- you may check the code at https://bitbucket.org/BerislavLopac/waexplorer

I used the web 10 years ago, along with a lot of those flash and java applets, and I use the web now, along with a lot of these richly interactive javascript applications, and comparing then with now strikes me as truly ridiculous. The web is hugely more usable now.

There were but probably in-house non public ones. I had a course where the teacher explained how its company was building portable asynchronous desktop-like applications in JS since early 2Ks. Maybe the exception though.

A few examples would come in handy. The only place I can remember using flash and enjoying it was youtube. (And then only because there wasn't a better/standard way of playing videos.)

There were some pretty good multi-user flash games around 1999/2000, when things were just getting going. I can't remember the names though at the moment.

It's only recently that graphics / audio / video / networking in javascript is almost as good as flash/java was 15 years ago!

Sometimes it's easy to think we're on the cutting edge. But we're really not.

I'm sorry but the UX on Flash and Java plugin-based apps was horseshit. They were sluggish and encapsulated clumsily within the plugin sandbox so the integration to the browser was terrible.

Yeah people did some amazing work on those proprietary platform when they were the only game in town, but it really doesn't hold a candle to what we have today in terms of a fully open and native web tech stack. If you want to be reductionist why not just say we haven't been on the bleeding edge since Lisp was invented and declare everything else derivative tripe.

They were faster than browsers were at the time, that's for sure. Especially Flash. At one point no serious design-focussed website worth its salt bothered with HTML because Flash was so much better and easier to author. Heck it's probably still easier to author.

The "open and native web tech stack" is something that evolved messily over a long period of time in a piecemeal fashion with little overall design vision. It's hardly something to be proud of.

And yet the sites that succeeded long-term (Google, Amazon, etc.) didn't use it, while all the sites that consisted of a zillion MB of Flash and Java all went by the wayside.

Maybe design snobbery isn't as important as designers think it is.

And yes, the web is definitely something to be proud of.

There has never been a cross-platform, cross-media, accessible platform like the web in the history of computing or humanity for that matter. It is very much indeed something to be proud of.

I've been seeing the term "web app" a lot lately. Not exactly sure why. Is a web app different from a website? I guess so probably maybe? I'm not really sure.

In my understanding, a webapp is essentially a "desktop-like" application for the browser, i.e. something like gmail or an online paint program, something that is interaction driven, will probably use websockets for giving a realtime feeling, etc. A website is the traditional static content, like a blog or a news site. Obviously, these are just relative and its a scale so there cross-over and sometimes its hard to define in exactly which category an app/site falls.

quite different-- Web app, think Google Docs/Sheets.

Web site, think blog, information landing page, or even web store product page(s).

Web app is highly interactive (may or may not be an SPA single page app), relying heavily on javascript for UI events, saving/fetching application state, remote datasets, and sometimes making use of modern HTML5 browser features.

Web site is displaying information and is just augmented with some javascript mostly for improving the UX or attaching analytics/social plugins etc.

Given that this distinction is entirely subjective (no-one will be able agree on what a test that pigeonholes pages as a 'site' or 'app'), how is it a useful distinction?

It may not be a useful distinction, but it's useful to have a sense for where on the continuum the thing you're building sits, in order to make technology and architecture decisions. If you're building something more "website-y", it should probably have an architecture that optimizes for search-ability and static caching, whereas if you're building something more "webapp-y", the architecture should probably optimize interactivity and dynamic updates. Most things end up somewhere in the middle, but leaning one way or the other.

I don't think anyone is trying to partition projects into disjunct sets. It's more of a continuum. I think the idea of "app-iness" just captures the interactivity and statefullness of an experience. Incidentally, that additional complexity is exactly what the Web technologies were initially ill-suited for and what frameworks were built to help manage.

Is a "simple website" and a "complex website" a better distinction in your opinion?

Thus I am a complex website engineer. It sounds ridiculous. The webapp developer is domain knowledge wise closer to traditional "application development" than to traditional "website development".

Are sites like vox or gawker considered websites or web apps? Their custom CMS is quite expansive. How bout NYTimes? Is YouTube a web app or a web site? I'd be curious to know some examples on either side. Preferably several closer to the line but on one side or the other rather than far away.

I think you answered your own questions.

I totally agree web site and web app are used interchangeably sometimes -- I was just answering the op as to how I and many people I know classify them and their differences as they relate to the topic of the article, javascript.

For me a web app is an HTML5 web page, that has its interaction logic coded in JS and presentation is done by altering HTML5 DOM and where JS uses REST to send/receive data.

In other words as someone else noted, it is a sandboxed application with

sandbox execution environment == browser IO == REST UI = HTML5 DOM manipulation of the same page

A website (or server app) is a series of HTML5 web apps or HTML5 static pages (JS-less web apps) with navigation logic and inter-app state living in a server app.

Why the emphasis on REST? Websockets tend to be easier for complex applications.

It's not entirely subjective.

I'd say

web sites are content centric and made for consuming it.

web apps are interaction centric and made to "do" something.

I agree. Consumption v. production is a good way of looking at it.

Note that this definition means that certain pieces of software could be considered either "sites" or "apps", depending on how they're being used.

For instance, blog software like Wordpress would be a "site" for the readers, but an "app" for the person who writes the posts.

A "product" can consist of different parts.

One part is an editing software/gui and one part is a reading software/gui. Both working on the same data.

Since both are used by different kind of users, I would design them as different programs (one a site and one an app).

It's been around for a long time now actually.

Web App are application like website.

So instead of traditional application/program such as Quicken we got Mint.com now. It makes application OS agnostic now too.

Web sites are bunch of pages that are hot link or connected via URL. Think of the old days of geocities, xoom, tripod, etc..

A while back there was a lot of chat about "single page web applications" - I suspect people have simply condensed that mouthful into "web app".