5 ms·

I built http://www.5by.com http://www.5by.com on AngularJS in about 3 months, and just a few thousand lines of code. The same thing in Backbone would have likel

I built http://www.5by.com http://www.5by.com on AngularJS in about 3 months, and just a few thousand lines of code. The same thing in Backbone would have likely taken a lot more time and a lot more code. It was my first AngularJS app, and I was learning it on the job, which is why it took that long. Overall, Angular is a joy to work with and its conventions force you to write clean, readable, decoupled code.

romaniv 13y ago
I find it highly annoying that people who promote client-side MVC and one-page apps always claim that it's trivial to make pages linkable and make browser navigation work, yet the wast majority of real-life single-page apps are missing those features.
- manmal 13y ago
  If you use Ember correctly, you get a URL for each application state and can use the back button to your liking. The only downside that I can see here is that after going back, the site might take a while until it has fetched all the data (which is not the case for common web apps). Discourse suffers from that.
- marknutter 13y ago
  That's because it's not generally a requirement for single-page applications. The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable (which is why it was stupid for Twitter and Gawker to go the single-app route). But yes, it is incredibly trivial to support it using these frameworks.
  - romaniv 13y ago
    That's because it's not generally a requirement Is that a new way of saying "I just don't care about it"? The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable I've heard that before... from ASP.NET WebForms developers. Incidentally, I've seen quite a few ASP.NET WebForms applications that were literally a single page with changing panels and hidden controls. Needless to say, they were a bloody mess. Thing that normally could be achieved by linking required code changes. Integrations that could be performed via a simple HTTP post were done using complicated web services. Links are the essence of the web platform. Calling something an "app" doesn't change that.
    - marknutter 13y ago
      > Is that a new way of saying "I just don't care about it"? It's one way of saying it, I suppose, yes. We don't worry about linking to states in desktop apps so why would we care about linking to states in desktop-like javascript apps? > Links are the essence of the web platform. Calling something an "app" doesn't change that. I agree. But when you make a desktop-like app that lives on the web, then linking isn't as important. I take it your issue is with desktop-like apps on the web?
      - romaniv 13y ago
        My overall problem is that a lot of modern web development trends undermine the reasons web became so popular in the first place. Linking is an easy example. Something that didn't require any "extra" effort now requires "correct" usage of some framework and extra effort. But there are many other things as well.
        marknutter 13y ago
        Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data. Take google docs. During any given session there could be thousands of different states the app is in at any one time, such as certain formatting options being selected, different popover or dropdown menus shown, or the content in the document itself changing. There'd be no point in providing a different URL for each one of those states.
        romaniv 13y ago
        Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data. For example, to save some kind of setup you often use as a bookmark. This is especially valuable in case there are multiple setups you often alternate between. To make it more concrete, imagine a table with multiple columns you can sort by and a bunch of search filters at the top. Your users from accounting always sort by date. Your users from HR always filter by a particular status and last name. Your CEO wants to be able to see both views. If the application supports proper URLs, all of this can be done via bookmarks with no extra coding. Moreover, if someone suddenly develops the need for a new weird workflow, they can service themselves simply by bookmarking the URL.
corresation 13y ago
I've spend the last 40 minutes watching various videos brought to me by your app. Fantastic.
hkhanna 13y ago
I like your app. Big fan of the 'timed' time-wasters! Great for short breaks. Thanks for introducing me to it!
k3n 13y ago
> The same thing in Backbone would have likely taken a lot more time and a lot more code. I think that's an unfounded (not to mention unfair) statement, unless you've actually attempted to do so and can provide some objective data points. Otherwise, it's nothing but opinion. Aside from that, the app does look interesting; I'll have to check it out later.
- MaybiusStrip 13y ago
  Unless we get a large number of developers to build the same application twice using each framework, all evidence related to this is going to be speculative or anecdotal at best. Having written a lot of both backbone and angular, I can confidently say that I am _much_ more productive with angular, so much that I get incredibly frustrated and resentful when I have to work on a backbone project. I think if you do a little bit of research you'll find a sizeable amount of similar testimony from people who have switched from backbone to a more comprehensive framework.
- ulisesrmzroche 13y ago
  Once you start supporting persistence and keeping things reliably in sync, things start to get very complicated. You'd still have to write that out in Backbone, when ember or angular provide it out of the box.
matt__ring 13y ago
5by is very nice -- great work

romaniv 13y ago

I find it highly annoying that people who promote client-side MVC and one-page apps always claim that it's trivial to make pages linkable and make browser navigation work, yet the wast majority of real-life single-page apps are missing those features.

manmal 13y ago
If you use Ember correctly, you get a URL for each application state and can use the back button to your liking. The only downside that I can see here is that after going back, the site might take a while until it has fetched all the data (which is not the case for common web apps). Discourse suffers from that.
marknutter 13y ago
That's because it's not generally a requirement for single-page applications. The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable (which is why it was stupid for Twitter and Gawker to go the single-app route). But yes, it is incredibly trivial to support it using these frameworks.
- romaniv 13y ago
  That's because it's not generally a requirement Is that a new way of saying "I just don't care about it"? The idea of a single-page app is to make it feel like a desktop application, not to make it highly linkable I've heard that before... from ASP.NET WebForms developers. Incidentally, I've seen quite a few ASP.NET WebForms applications that were literally a single page with changing panels and hidden controls. Needless to say, they were a bloody mess. Thing that normally could be achieved by linking required code changes. Integrations that could be performed via a simple HTTP post were done using complicated web services. Links are the essence of the web platform. Calling something an "app" doesn't change that.
  - marknutter 13y ago
    > Is that a new way of saying "I just don't care about it"? It's one way of saying it, I suppose, yes. We don't worry about linking to states in desktop apps so why would we care about linking to states in desktop-like javascript apps? > Links are the essence of the web platform. Calling something an "app" doesn't change that. I agree. But when you make a desktop-like app that lives on the web, then linking isn't as important. I take it your issue is with desktop-like apps on the web?
    - romaniv 13y ago
      My overall problem is that a lot of modern web development trends undermine the reasons web became so popular in the first place. Linking is an easy example. Something that didn't require any "extra" effort now requires "correct" usage of some framework and extra effort. But there are many other things as well.
      - marknutter 13y ago
        Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data. Take google docs. During any given session there could be thousands of different states the app is in at any one time, such as certain formatting options being selected, different popover or dropdown menus shown, or the content in the document itself changing. There'd be no point in providing a different URL for each one of those states.
        romaniv 13y ago
        Yeah, but seriously, why would you want to link to a particular state in a desktop-style application? Especially if the intent of the app is to be used by a single user working with private data. For example, to save some kind of setup you often use as a bookmark. This is especially valuable in case there are multiple setups you often alternate between. To make it more concrete, imagine a table with multiple columns you can sort by and a bunch of search filters at the top. Your users from accounting always sort by date. Your users from HR always filter by a particular status and last name. Your CEO wants to be able to see both views. If the application supports proper URLs, all of this can be done via bookmarks with no extra coding. Moreover, if someone suddenly develops the need for a new weird workflow, they can service themselves simply by bookmarking the URL.

corresation 13y ago

I've spend the last 40 minutes watching various videos brought to me by your app. Fantastic.

hkhanna 13y ago

I like your app. Big fan of the 'timed' time-wasters! Great for short breaks. Thanks for introducing me to it!

k3n 13y ago

> The same thing in Backbone would have likely taken a lot more time and a lot more code. I think that's an unfounded (not to mention unfair) statement, unless you've actually attempted to do so and can provide some objective data points. Otherwise, it's nothing but opinion. Aside from that, the app does look interesting; I'll have to check it out later.

MaybiusStrip 13y ago
Unless we get a large number of developers to build the same application twice using each framework, all evidence related to this is going to be speculative or anecdotal at best. Having written a lot of both backbone and angular, I can confidently say that I am _much_ more productive with angular, so much that I get incredibly frustrated and resentful when I have to work on a backbone project. I think if you do a little bit of research you'll find a sizeable amount of similar testimony from people who have switched from backbone to a more comprehensive framework.
ulisesrmzroche 13y ago
Once you start supporting persistence and keeping things reliably in sync, things start to get very complicated. You'd still have to write that out in Backbone, when ember or angular provide it out of the box.

matt__ring 13y ago

5by is very nice -- great work