131–140 of 168 posts
We've transitioned from Angular to ReactJS with great success. Much smaller learning curve. Using Backbone to handle the models and React for the view is a great combination.
All these arguments seem like lowly excuses to not do proper work and instead blame the framework you are using. If you have any kind of interactiveness the feel of a fat client is so much better then template rendering. Look at the site: https://sourcegraph.com/github.com/tomchristie/django-rest-f... ? Is that the best interface you can get? In 2014 everything I click reloads the page? a tabbed interface that doesn'…
Earlier quoted context omitted.
Wait, Wait, WAIT. No to angular, but you then casually throw in that instead you went "plain Jquery+Knockout", as if Knockout is commonplace? How is that plain ? Knockout is not commonplace. They're just alternatives. One is Microsoft's, one Google's. They're both client-side frameworks. Your post makes no sense at all. All it sounds like is that you're familiar with knockout but not angular and managed to convince t…
>How is that plain? Knockout is not commonplace. Knockout is a common data binding library in the JS world. It does one thing and only one thing very well - databinding. Sure it might have (little) features here and there that allow you to do other things, but it's core feature is data binding. >They're just alternatives. One is Microsoft's, one Google's. They're both client-side frameworks. No, they're not. Knockout…
I had the opportunity to work for a million dollar budget client project, about a year ago. (Obviously I'm bound by an NDA, so I won't go into specifics). You can think of this site like an oDesk/Freelancer competitor, but with some social features. We also had another team from California working on this project, who consistently insisted that we go with Angular for a project of such complexity. Back then, on HN, ev…
I find Angular really helps when you have a fairly complex single-page app that has non-trivial interactions. The complexity tradeoff you make using it is not worth it when you don't have those needs, especially when you have a team of people that need to be up to speed working on it.
Knockout's simplicity is hard to beat.
Earlier quoted context omitted.
And some people still use IE6, but that doesn't mean you should continue to support IE6.
So based on that logic, you can abandon all standards of usability and interoperability?
I love AngularJS for internal desktop tools I write, but I would never use it or any other client rendering script in the wild where my applications could be consumed by unknown form factors. Specifically, you have absolutely no idea how much memory allocation you are getting when you are dealing with mobile devices, and any assumption on the developer's part is asinine.
AngularJS was not the problem in this case; and I'd wager we are going to continue to see articles like this as developers go through growing pains of learning that you should optimize for the end user first, not yourself.
This mayaswell be titled: "Why we're paying for re-discovering client-heavy apps are hard or bad." Angular, or doesn't particularly matter. Twitter learned it[1]. Lots of us learned it when we were experimenting as Web 2.0 was being born. Things were far more obvious, far more quickly then, as bandwidth and resources weren't anywhere near what they are today. Back then, we quickly realized that just a couple of delay…
To answer that question -- for the same reason you'd prefer mobile apps on a smartphone. Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time. Now, do people really thin…
Semantic nitpicking. It's obvious that the grandparent speaks about templating, which can be done both on client and server side.
Honestly, I'm really tired of people who pretend there is no difference between serving up HTML and serving a program that constructs that HTML. The difference is that in the second case you cannot get the content without executing the program written by someone else with all the relevant implications.
Also, people often miss another important fact: server-side rendering can be cached and shared across clients. Client-side templates must to be executed by every client separately.
Server side generated stuff would've been just great here or on the project I did!
For example, how often do your users go to their settings page? Does that need to be part of the SPA? Have a complex Settings pages that's composed of 5 or six tabs and 20 different user interactions? Maybe the settings page is itself it's own mini-SPA
How does a user flow through your app, do they really need every screen bundled under a single SPA?
Routing issues, complexity, code dependencies, etc...are all good reasons to not make one monolithic application, even if it's behind a login.
Likely your SPA should really be an app composed of a bunch of smaller SPAs. You search functionality...mini app, your separate workflows...a mini app, your timeline...mini app. history view...mini app, etc...
Breaking your app down into a bunch of smaller SPAs has a lot of advantages and implicit modularization, as well as productivity gains when working on bigger projects with bigger teams.
Earlier quoted context omitted.
"node.js + express + jade" is a fairly common stack, you can even try to move an existing complex angular.js code there because it's written in the same language
Is node really a good choice for static non-real time sites? I'm thinking something like Django or Ruby on Rails is better.
In most cases Node.js is just faster than Rails or Django.