8 ms·

Web apps are dead, long live web apps

52 points by joshowens 15y ago

evanwalsh 15y ago
I was prepared for a link bait blog post and I ended up getting a quality piece of writing. Pretty good.
- iqster 15y ago
  What a horrible title for an article! The first time someone used ... X is dead, long live X ... it had meaning. It is completely cliche now.
- AdamTReineke 15y ago
  I disagree. Basically he says he loves Backbone and CoffeeScript because they remove the headaches of Javascript and "chatty web-apps", but doesn't get any farther than that, instead plugging his company's training class.
- wavephorm 15y ago
  Blah blah... coffeescript. Web development fashion is a giant echo chamber.
MarkTraceur 15y ago
Good points--but it looks from my limited knowledge of web frameworks like most people aren't even using AJAX, much less to its full potential. Maybe I'm wrong, but it seems like Flask/web2py and other MVC frameworks are more interested in keeping track of things on the server, not pushing things to the client. Admittedly, that helps with security, but when you're making something trivial, it's not necessary to push all of the traffic back to the server to get session variables, templates, and the like.
ebiester 15y ago
I thought the biggest complaint was still the endless checking on platforms (IE 6, 7, 8, 9, Firefox, lynx...) and the difficulty in layout (negative widths, anyone?) Try three resizable columns sometime! (I'm still trying to figure out a solution to this one. Even the new layouts of CSS3 break in funny ways.)
- joshowens 15y ago
  Only if you are a designer, which I am not. I am guessing the article writing isn't either.
  - deleted 15y ago
    [deleted]
  - ebiester 15y ago
    How many web designers are exclusive front or back end anymore?
- randomdata 15y ago
  difficulty in layout It doesn't have to be hard. I'm currently using Backbone in a project. I added OpenStep/Cocoa's autoresizing masks to Backbone.View and now layout is a breeze. The CSS layout model actually lends itself really well to this if you're willing to use JS to do the calculations.
- Joeri 15y ago
  I used to struggle similarly. The DOM always seemed to get in the way of building dynamic user interfaces, and CSS's layout primitives made it hard to do the border and anchor layouts that I was aiming for. Then it dawned on me: the DOM and CSS API's simply aren't meant to be used directly. They're like the X11 API. You need to wrap them into something saner to make sense of them. After that I adopted ExtJS. It puts a cross-browser wrapper around the browser API's, with its own component and layout system. Way easier to program with.
  - ebiester 15y ago
    ExtJS was a bear, at least to me, to debug. And modifications required a lot of digging. It was great for the 80%, but the 20% was painful.
scarmig 15y ago
tldr: "Client side code is awesome with backbone.js and CoffeeScript! Come to our seminar!"
- alperakgun 15y ago
  tldr: if you miss vb6, ajax will help.
- ams6110 15y ago
  ... until 6 months when two or three other new frameworks will be the next greatest thing to hit web development and people will be scoffing at your "legacy" backbone and coffeescript apps...
- merijnv 15y ago
  tl;dr: Let's all reinvent an even less standardised X11 in JavaScript and HTTP!
  - scarmig 15y ago
    Heh, is that that terrible? An article I'd love to see is something expounding on that analogy.
snorkel 15y ago
There's only so much business logic you can push off the client. If the app is mostly in the client seems like that'd be adding a whole new level of complexity to how to seamlessly deploy new versions, model changes, etc.
grayrest 15y ago
> Backbone.js is the best client side MVC framework I’ve used, but there are certainly others. Sproutcore is much more powerful. If you haven't checked out 2.0, you really should. I've been following it for years and always thought they had the best KVO system but avoided it due to the js-based layout and enormous size. The 2.0 version binds to handlebars--slightly extended mustache--templates instead of relatively opaque widgets and reduces the wire size to right around the size of jQuery. It's larger than backbone and you have to wade through more concepts but you add an object to an array and the dom updates without any further input. Eliminates the majority of dom manipulation code in your app.
- msy 15y ago
  Seconding this - Sproutcore 2 is such a different beast to 1.0 it's a pity they share a name. There's a number of concepts, particularly around handling cascades of DOM updates in there that are far more advanced that you'd have to write yourself in backbone.
- swannodette 15y ago
  And I would argue ClojureScript brings even more to the table than SproutCore or CoffeeScript for clientside development. Having done MVC in all shapes and sizes, I'm not convinced that traditional MVC is a good model given the realities of the DOM.
  - grayrest 15y ago
    I've been following ClojureScript with mild interest but letting the clojure enthusiasts make the cowpaths. What I haven't seen is how clojurescript significantly improves DOM interaction. I agree that the core problem of client side development is controlling state, which the DOM frustrates. Sproutcore works around this by essentially binding to the DOM and preferably building a nested state machine on top (statecharts) which doesn't solve mutable state but confines it to smaller pieces. Obviously clojurescript deals well with controlling state in memory but the clojurescript sample stuff I've seen has all deferred actual DOM manipulation to Closure. What's the deal?
- gaslightchris 15y ago
romaniv 15y ago
Does the article's author realize that the HTTP's request-response model wasn't some technology limitation of old times, but conscious and pretty sensible design that led to current popularity of the web? Here is what it allowed: - URIs, i.e. ability to connect all the documents on the Web. - Standardized UIs that are easy to create. - Security. You don't need to execute unknown code to load a page, yet you can use web interfaces to do a lot of different things. - Control an transparency for the users. Browser is your software, you decide what it will and won't do. With the increased used of heavy JS clients, most of these benefits are fading away.
- joshowens 15y ago
  I would disagree, the article never said do away with server side security or anything like that. I don't think it said anything about ditching URIs either.
  - icebraining 15y ago
    Security is for the client. And ditching URIs is often a direct consequence of using AJAX to load the document dynamically, since the current URL doesn't represent the current document anymore.
NY_Entrepreneur 15y ago
'Web apps' have had a fantastically valuable feature nearly never mentioned. If we make big changes in how a Web browser client interacts with a Web server, then we risk getting rid of this fantastically valuable feature and seriously hurting our Web apps and the growth of the Web. I believe that if we don't recognize the fantastically valuable feature, then the rush for 'richer' 'user interfaces' (UIs) and 'better' 'user experiences' (UXs) will get rid of this fantastically valuable feature. Yes, UI/UX are IMPORTANT. Okay, I accept that. BUT here's the fantastically valuable feature we just MUST retain: I explain the feature with two examples. First Example -- Microsoft Word While I can't speak for anyone else, I work hard to avoid using Microsoft Word. Several times I've used it, learned its UI well enough to get my work done, and rushed to f'get about Word and its UI. Instead, for my high quality word whacking, I use D. Knuth's TeX that I find MUCH easier to use. Why easier? The documentation is rock solid, a jewel of software documentation. The software has a 'conceptual model' well explained in the documentation; with this conceptual model, it is fairly easy to understand what is going on. What TeX does is actually quite reliable and predictable and as explained in the documentation. Word is DIFFERENT. I hate the Word UI/UX. For me, for each significant new usage, the UX is sometimes yelling and screaming in frustration. When I want to do something new to me, there's no solid documentation and no good 'conceptual model' for how Word works. So, I don't really know how it works. So, when I want to do something, I go around on the screen and left click, right click, double left click, double right click on everything in sight and see what happens. Commonly I type in something, get it as I want it, and then for no reason Word just throws away what I did. After a dozen times of such efforts throwing my work against the wall of Word to see what will stick, I start screaming. I HATE Word and all of its intended UI/UX. Maybe if I got and read the documentation for how to write macros for Word it would make more sense, but as far as I know I would have to pay for that documentation. Besides, did I mention, I HATE, deeply, profoundly, bitterly hate and despise, Word? My view is that it takes at least two weeks of full time work for someone to get good facility with Word. Second Example -- 100 Million Web Sites and One Billion Users As we all now know very well, there are something over 100 million Web sites on the Internet and about 1 billion users. And, nearly any user can use nearly any Web site in their language right away. So, somehow Web apps save the two weeks of full time effort for each of 1 billion users for each of some hundreds of Web sites they might visit. That is, HTML is SIMPLE, DIRT simple. Nearly all Web apps built with just dirt simple HTML have a fantastically valuable feature: Nearly any one of 1 billion users can use the Web app right away. The Web app UI/UX has this feature, and Word does not. Why do Web apps have this feature? Because HTML is DIRT simple. Yes, commonly there is a round trip to the server for each little step in the user's work. Right. So, there's a minimum of subtle, dynamic, pop ups, pull-downs, roll-overs, drag and drops, hidden 'side effects', and big changes in the state of the user's work from small actions. Not much is hidden or mysterious. There is minimal need for documentation. The UI/UX is NOT 'rich' -- thankfully. To layout a page, mostly use just tables and/or divisions and nothing more complicated. So, the screen presented to the user is relatively simple, easy to understand, and much the same from one Web site to another. E.g., the designers of Word may have spent some thousands of person-hours designing each little part of each screen. The resulting complexity is forbidding -- huge BUMMER. With just simple HTML, it's just not practical to implement such complexity -- THANKFULLY. With just simple HTML, for what we could let a user do, about all we got was (1) to follow a link, click on an image, (2) click on a button, (3) click on some radio buttons, (4) type into a text box, (4) move text to/from the system clipboard, (6) use the key TAB to move the cursor to the next text box, (7) hit the key ENTER in a text box. SIMPLE. Over 100 million Web sites have the 'controls' links, buttons, text boxes, etc.; all of these controls work very much the same on all the sites -- TERRIFIC. When a user clicked on some button, say, "Submit" or hit the key ENTER, the data the user entered was sent to the server, and the server responded. SIMPLE. Any user with any browser can use nearly any Web app right away. FANTASTIC. Now, if we work at it, say, with much more powerful client side programming tools, then we will be able to build Web apps with a 'rich' UI/UX. We can have dynamic this, subtle that, automatic these other things, asynchronous who knows what, guess and anticipate what the user wants and do it for them as a 'favor', drag and drop, overlays, full motion, and on and on. We can have rivers of functionality that are subtle, bug ridden, undocumented, not obvious, and, at each site, unique on all of the Web. BUMMER. E.g., I'm still screaming bloody murder at the whole theme of 'icons' because those little images are not English or any natural language, can't be spelled, pronounced, or looked up in a dictionary, and are documented usually at best poorly. Sickening. I HATE 'icons'. Then, sorry guys, in practice, nearly all Web apps will (1) be much more expensive to develop, (2) will have many more security problems, (3) will be much less compatible with all the common browsers, (4) will usually become a total pain in the neck to learn to use, and (5) will lose the fantastically valuable feature of ease of use, right away, for any of one billion users. Here's the truth: The UI should be simple, stay simple, dirt simple. The work on the server side might be fantastically complicated, but for the user the concepts of what they want, what data they enter, and what data they get back should remain SIMPLE. As it is, HTML is so simple it's tough to mess up the UI. With much more powerful client side software tools, it will be tough NOT to mess up the UI. Be careful about what you wish for because you might get it. At least be very aware and careful with the fantastically valuable feature of Web apps built with simple HTML.
EGreg 15y ago
Disagree. Web apps can be cached locally. Web apps can run in PhoneGap or Prism and have access to your desktop. Sure, they aren't for everything. But having a common platform of HTML and Javascript and CSS is actually pretty great, especially for hiring purposes! The native bindings can be extended either using drop-in plugins or by hiring native developers to do really well defined tasks. Which once again is good news for both stability, speed of development, and hiring.
kristopolous 15y ago
Hype: A clever marketing strategy which a product is advertized as the thing everyone must have, to the point where people begin to feel they need to consume it. Substance: the actual matter of a thing, as opposed to the appearance or shadow; reality. This piece is hype. Those that push off hype as substance are swindling your valuable time and are basically saying "come on everyone, let's hope on board the train and base our infrastructure off of unproven, new shit." Which is fine; but only because most of these people are just writing the same social shopping website over and over again; and will do so until the next hyped idea makes its way into the business world.
- joshowens 15y ago
  I am glad you were around to debunk the "hype" and steer us straight for all our social shopping website coding needs!
abrenzel 15y ago
Some things from this article just don't make sense to me. Like, why is AJAX/client-side MVC pointed out as something that overcomes the HTTP request/response cycle? No, it doesn't. It just means you don't have to refresh the entire screen every time a request is made. Whether the server now sends back "a wad of HTML/javascript" or some JSON to be parsed by the Javascript MVC framework du jour, nothing you are doing is transcending the HTTP protocol either way. AJAX changed the way users interact with web applications, but it did not change anything really fundamental about their architecture. Second, Coffeescript does not liberate you from Javascript. It IS Javascript. It makes it easier to control some of Javascript's difficult areas, like the meaning of "this" as execution context changes as one example, but it doesn't suddenly give you license to write browser code the way you would write Python or C++. In any case, let's not confuse convenience with paradigm shifting.
- gaslightchris 15y ago
  The important difference I see in the approach used by backbone is it gets us away from having the server be in control of navigation and UI events. After the initial page load, I'm exchanging simple data as json with the server. It wasn't HTTP I was arguing with, it is having a server side framework managing the UI navigation. The best way I've heard coffeescript described is as a better syntax for javascript. Though at first this may not seem like a big deal, in my experience it's been a huge deal in the effect it has on how I approach client side code. Now that I can write code I really love on the client, it's greatly lowered the barrier for me to do so.
  - abrenzel 15y ago
    I just see this as an incremental development, rather than a revolutionary one. As I mentioned above, the server is still very involved with UI events and navigation. If the user causes a UI event that saves data to the server, even if there is client-side validation it will often be the server that responds with an error and forces the page to do something with that. The nice thing is that we now get to encapsulate the server's influence on the application into definable actions, rather than by a single request. That's a rather good thing for us developers, but it is still well within the bounds of the traditional HTTP model. As for Coffeescript, anything that tames some of the nasty bits of Javascript is fine by me. I don't dispute Coffeescript's usefulness. My point was just that Coffeescript is like syntactic sugar for Javascript, not a paradigm shift in client side coding.
alexholehouse 15y ago
Content irrespective, that's some difficult to read text...

52 points by joshowens 15y ago

evanwalsh 15y ago

I was prepared for a link bait blog post and I ended up getting a quality piece of writing. Pretty good.

iqster 15y ago
What a horrible title for an article! The first time someone used ... X is dead, long live X ... it had meaning. It is completely cliche now.
AdamTReineke 15y ago
I disagree. Basically he says he loves Backbone and CoffeeScript because they remove the headaches of Javascript and "chatty web-apps", but doesn't get any farther than that, instead plugging his company's training class.
wavephorm 15y ago
Blah blah... coffeescript. Web development fashion is a giant echo chamber.

MarkTraceur 15y ago

Good points--but it looks from my limited knowledge of web frameworks like most people aren't even using AJAX, much less to its full potential. Maybe I'm wrong, but it seems like Flask/web2py and other MVC frameworks are more interested in keeping track of things on the server, not pushing things to the client. Admittedly, that helps with security, but when you're making something trivial, it's not necessary to push all of the traffic back to the server to get session variables, templates, and the like.

ebiester 15y ago

I thought the biggest complaint was still the endless checking on platforms (IE 6, 7, 8, 9, Firefox, lynx...) and the difficulty in layout (negative widths, anyone?) Try three resizable columns sometime! (I'm still trying to figure out a solution to this one. Even the new layouts of CSS3 break in funny ways.)

joshowens 15y ago
Only if you are a designer, which I am not. I am guessing the article writing isn't either.
- deleted 15y ago
  [deleted]
- ebiester 15y ago
  How many web designers are exclusive front or back end anymore?
randomdata 15y ago
difficulty in layout It doesn't have to be hard. I'm currently using Backbone in a project. I added OpenStep/Cocoa's autoresizing masks to Backbone.View and now layout is a breeze. The CSS layout model actually lends itself really well to this if you're willing to use JS to do the calculations.
Joeri 15y ago
I used to struggle similarly. The DOM always seemed to get in the way of building dynamic user interfaces, and CSS's layout primitives made it hard to do the border and anchor layouts that I was aiming for. Then it dawned on me: the DOM and CSS API's simply aren't meant to be used directly. They're like the X11 API. You need to wrap them into something saner to make sense of them. After that I adopted ExtJS. It puts a cross-browser wrapper around the browser API's, with its own component and layout system. Way easier to program with.
- ebiester 15y ago
  ExtJS was a bear, at least to me, to debug. And modifications required a lot of digging. It was great for the 80%, but the 20% was painful.

scarmig 15y ago

tldr: "Client side code is awesome with backbone.js and CoffeeScript! Come to our seminar!"

alperakgun 15y ago
tldr: if you miss vb6, ajax will help.
ams6110 15y ago
... until 6 months when two or three other new frameworks will be the next greatest thing to hit web development and people will be scoffing at your "legacy" backbone and coffeescript apps...
merijnv 15y ago
tl;dr: Let's all reinvent an even less standardised X11 in JavaScript and HTTP!
- scarmig 15y ago
  Heh, is that that terrible? An article I'd love to see is something expounding on that analogy.

snorkel 15y ago

There's only so much business logic you can push off the client. If the app is mostly in the client seems like that'd be adding a whole new level of complexity to how to seamlessly deploy new versions, model changes, etc.

grayrest 15y ago

> Backbone.js is the best client side MVC framework I’ve used, but there are certainly others. Sproutcore is much more powerful. If you haven't checked out 2.0, you really should. I've been following it for years and always thought they had the best KVO system but avoided it due to the js-based layout and enormous size. The 2.0 version binds to handlebars--slightly extended mustache--templates instead of relatively opaque widgets and reduces the wire size to right around the size of jQuery. It's larger than backbone and you have to wade through more concepts but you add an object to an array and the dom updates without any further input. Eliminates the majority of dom manipulation code in your app.

msy 15y ago
Seconding this - Sproutcore 2 is such a different beast to 1.0 it's a pity they share a name. There's a number of concepts, particularly around handling cascades of DOM updates in there that are far more advanced that you'd have to write yourself in backbone.
swannodette 15y ago
And I would argue ClojureScript brings even more to the table than SproutCore or CoffeeScript for clientside development. Having done MVC in all shapes and sizes, I'm not convinced that traditional MVC is a good model given the realities of the DOM.
- grayrest 15y ago
  I've been following ClojureScript with mild interest but letting the clojure enthusiasts make the cowpaths. What I haven't seen is how clojurescript significantly improves DOM interaction. I agree that the core problem of client side development is controlling state, which the DOM frustrates. Sproutcore works around this by essentially binding to the DOM and preferably building a nested state machine on top (statecharts) which doesn't solve mutable state but confines it to smaller pieces. Obviously clojurescript deals well with controlling state in memory but the clojurescript sample stuff I've seen has all deferred actual DOM manipulation to Closure. What's the deal?
gaslightchris 15y ago

romaniv 15y ago

Does the article's author realize that the HTTP's request-response model wasn't some technology limitation of old times, but conscious and pretty sensible design that led to current popularity of the web? Here is what it allowed: - URIs, i.e. ability to connect all the documents on the Web. - Standardized UIs that are easy to create. - Security. You don't need to execute unknown code to load a page, yet you can use web interfaces to do a lot of different things. - Control an transparency for the users. Browser is your software, you decide what it will and won't do. With the increased used of heavy JS clients, most of these benefits are fading away.

joshowens 15y ago
I would disagree, the article never said do away with server side security or anything like that. I don't think it said anything about ditching URIs either.
- icebraining 15y ago
  Security is for the client. And ditching URIs is often a direct consequence of using AJAX to load the document dynamically, since the current URL doesn't represent the current document anymore.

NY_Entrepreneur 15y ago

'Web apps' have had a fantastically valuable feature nearly never mentioned. If we make big changes in how a Web browser client interacts with a Web server, then we risk getting rid of this fantastically valuable feature and seriously hurting our Web apps and the growth of the Web. I believe that if we don't recognize the fantastically valuable feature, then the rush for 'richer' 'user interfaces' (UIs) and 'better' 'user experiences' (UXs) will get rid of this fantastically valuable feature. Yes, UI/UX are IMPORTANT. Okay, I accept that. BUT here's the fantastically valuable feature we just MUST retain: I explain the feature with two examples. First Example -- Microsoft Word While I can't speak for anyone else, I work hard to avoid using Microsoft Word. Several times I've used it, learned its UI well enough to get my work done, and rushed to f'get about Word and its UI. Instead, for my high quality word whacking, I use D. Knuth's TeX that I find MUCH easier to use. Why easier? The documentation is rock solid, a jewel of software documentation. The software has a 'conceptual model' well explained in the documentation; with this conceptual model, it is fairly easy to understand what is going on. What TeX does is actually quite reliable and predictable and as explained in the documentation. Word is DIFFERENT. I hate the Word UI/UX. For me, for each significant new usage, the UX is sometimes yelling and screaming in frustration. When I want to do something new to me, there's no solid documentation and no good 'conceptual model' for how Word works. So, I don't really know how it works. So, when I want to do something, I go around on the screen and left click, right click, double left click, double right click on everything in sight and see what happens. Commonly I type in something, get it as I want it, and then for no reason Word just throws away what I did. After a dozen times of such efforts throwing my work against the wall of Word to see what will stick, I start screaming. I HATE Word and all of its intended UI/UX. Maybe if I got and read the documentation for how to write macros for Word it would make more sense, but as far as I know I would have to pay for that documentation. Besides, did I mention, I HATE, deeply, profoundly, bitterly hate and despise, Word? My view is that it takes at least two weeks of full time work for someone to get good facility with Word. Second Example -- 100 Million Web Sites and One Billion Users As we all now know very well, there are something over 100 million Web sites on the Internet and about 1 billion users. And, nearly any user can use nearly any Web site in their language right away. So, somehow Web apps save the two weeks of full time effort for each of 1 billion users for each of some hundreds of Web sites they might visit. That is, HTML is SIMPLE, DIRT simple. Nearly all Web apps built with just dirt simple HTML have a fantastically valuable feature: Nearly any one of 1 billion users can use the Web app right away. The Web app UI/UX has this feature, and Word does not. Why do Web apps have this feature? Because HTML is DIRT simple. Yes, commonly there is a round trip to the server for each little step in the user's work. Right. So, there's a minimum of subtle, dynamic, pop ups, pull-downs, roll-overs, drag and drops, hidden 'side effects', and big changes in the state of the user's work from small actions. Not much is hidden or mysterious. There is minimal need for documentation. The UI/UX is NOT 'rich' -- thankfully. To layout a page, mostly use just tables and/or divisions and nothing more complicated. So, the screen presented to the user is relatively simple, easy to understand, and much the same from one Web site to another. E.g., the designers of Word may have spent some thousands of person-hours designing each little part of each screen. The resulting complexity is forbidding -- huge BUMMER. With just simple HTML, it's just not practical to implement such complexity -- THANKFULLY. With just simple HTML, for what we could let a user do, about all we got was (1) to follow a link, click on an image, (2) click on a button, (3) click on some radio buttons, (4) type into a text box, (4) move text to/from the system clipboard, (6) use the key TAB to move the cursor to the next text box, (7) hit the key ENTER in a text box. SIMPLE. Over 100 million Web sites have the 'controls' links, buttons, text boxes, etc.; all of these controls work very much the same on all the sites -- TERRIFIC. When a user clicked on some button, say, "Submit" or hit the key ENTER, the data the user entered was sent to the server, and the server responded. SIMPLE. Any user with any browser can use nearly any Web app right away. FANTASTIC. Now, if we work at it, say, with much more powerful client side programming tools, then we will be able to build Web apps with a 'rich' UI/UX. We can have dynamic this, subtle that, automatic these other things, asynchronous who knows what, guess and anticipate what the user wants and do it for them as a 'favor', drag and drop, overlays, full motion, and on and on. We can have rivers of functionality that are subtle, bug ridden, undocumented, not obvious, and, at each site, unique on all of the Web. BUMMER. E.g., I'm still screaming bloody murder at the whole theme of 'icons' because those little images are not English or any natural language, can't be spelled, pronounced, or looked up in a dictionary, and are documented usually at best poorly. Sickening. I HATE 'icons'. Then, sorry guys, in practice, nearly all Web apps will (1) be much more expensive to develop, (2) will have many more security problems, (3) will be much less compatible with all the common browsers, (4) will usually become a total pain in the neck to learn to use, and (5) will lose the fantastically valuable feature of ease of use, right away, for any of one billion users. Here's the truth: The UI should be simple, stay simple, dirt simple. The work on the server side might be fantastically complicated, but for the user the concepts of what they want, what data they enter, and what data they get back should remain SIMPLE. As it is, HTML is so simple it's tough to mess up the UI. With much more powerful client side software tools, it will be tough NOT to mess up the UI. Be careful about what you wish for because you might get it. At least be very aware and careful with the fantastically valuable feature of Web apps built with simple HTML.

EGreg 15y ago

Disagree. Web apps can be cached locally. Web apps can run in PhoneGap or Prism and have access to your desktop. Sure, they aren't for everything. But having a common platform of HTML and Javascript and CSS is actually pretty great, especially for hiring purposes! The native bindings can be extended either using drop-in plugins or by hiring native developers to do really well defined tasks. Which once again is good news for both stability, speed of development, and hiring.

kristopolous 15y ago

Hype: A clever marketing strategy which a product is advertized as the thing everyone must have, to the point where people begin to feel they need to consume it. Substance: the actual matter of a thing, as opposed to the appearance or shadow; reality. This piece is hype. Those that push off hype as substance are swindling your valuable time and are basically saying "come on everyone, let's hope on board the train and base our infrastructure off of unproven, new shit." Which is fine; but only because most of these people are just writing the same social shopping website over and over again; and will do so until the next hyped idea makes its way into the business world.

joshowens 15y ago
I am glad you were around to debunk the "hype" and steer us straight for all our social shopping website coding needs!

abrenzel 15y ago

Some things from this article just don't make sense to me. Like, why is AJAX/client-side MVC pointed out as something that overcomes the HTTP request/response cycle? No, it doesn't. It just means you don't have to refresh the entire screen every time a request is made. Whether the server now sends back "a wad of HTML/javascript" or some JSON to be parsed by the Javascript MVC framework du jour, nothing you are doing is transcending the HTTP protocol either way. AJAX changed the way users interact with web applications, but it did not change anything really fundamental about their architecture. Second, Coffeescript does not liberate you from Javascript. It IS Javascript. It makes it easier to control some of Javascript's difficult areas, like the meaning of "this" as execution context changes as one example, but it doesn't suddenly give you license to write browser code the way you would write Python or C++. In any case, let's not confuse convenience with paradigm shifting.

gaslightchris 15y ago
The important difference I see in the approach used by backbone is it gets us away from having the server be in control of navigation and UI events. After the initial page load, I'm exchanging simple data as json with the server. It wasn't HTTP I was arguing with, it is having a server side framework managing the UI navigation. The best way I've heard coffeescript described is as a better syntax for javascript. Though at first this may not seem like a big deal, in my experience it's been a huge deal in the effect it has on how I approach client side code. Now that I can write code I really love on the client, it's greatly lowered the barrier for me to do so.
- abrenzel 15y ago
  I just see this as an incremental development, rather than a revolutionary one. As I mentioned above, the server is still very involved with UI events and navigation. If the user causes a UI event that saves data to the server, even if there is client-side validation it will often be the server that responds with an error and forces the page to do something with that. The nice thing is that we now get to encapsulate the server's influence on the application into definable actions, rather than by a single request. That's a rather good thing for us developers, but it is still well within the bounds of the traditional HTTP model. As for Coffeescript, anything that tames some of the nasty bits of Javascript is fine by me. I don't dispute Coffeescript's usefulness. My point was just that Coffeescript is like syntactic sugar for Javascript, not a paradigm shift in client side coding.

alexholehouse 15y ago

Content irrespective, that's some difficult to read text...