This is exactly the same problem with other client side javascript frameworks
Why we left AngularJS
111–120 of 168 posts
Re: Why we left AngularJS
#112I, am/was a big fan of Angular, but on a recent project decided we didn't have the right team composition for a lot of the coding styles and complexities angular introduces. We went with a JQuery/Knockout solution, too. Some of the devs still struggle to keep the viewmodels clean, but being able to integrate from knockout to existing JQuery plugins has been a big win. Writing custom angular directives, adding another layer to existing Jquery is a pain for a lot of front end developers, and likely overkill for many projects.
(to give scope size, we're replacing a several hundred screen Adobe Flex app with our new KO/JQuery app)
Re: Why we left AngularJS
#113I 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…
Although angular is aimed at Wide/SinglePage Apps I find it perfectly suited for small scale stuff. It's like a sedan if you wish but with all the safety airbags and comfort of an mvc and the possibility to mount a canon if you move out in the jungle. It gives you a level of confidence I'd find difficult to abandon.
Also I don't see how jquery + knockout is so different from taking the angular/ember road ? (edit: I see why from a legacy point of vue)
Finally the comparison with mongodb is misleading : angular & cie brings your code from procedural mess to a well known structured area, whereas moving away from sql didn't improve any of your architecture it just proposed another one
Re: Why we left AngularJS
#114I used AngularJS + Express for a reasonably sized custom news app for a client. It does everything form payments, to security, ya know, all the shebang.
I agree with is the first but only if you're still in the days of SEO trolling. Frankly it's just not as important if you're doing your other marketing aspects right.
For #2, I think there are plenty of ways to build in analytics. We use angularlytics and it works pretty well. Took me like 5 minutes to setup.
#3 - Yeoman. Generator Angular. Here's how I do it:
1. Make a client dir, and yeoman up your project with generator angular. 2. Make a server dir and setup an express server. 3. Grunt serve your client dir 4. Make it so express watches your .tmp and app folders for local dev 5. Run your express server 6. When your ready to serve it, Grunt build to a dist folder in your server folder 7. For production, have express serve the dist folder
Yeah kind of dirty (since you're running two local servers for dev), but hell, it's fast as can be to setup and a pleasure.
#4 Tests? If you're doing tests of any sort, they're bound to slow you down to an extent.
#5 Isn't this applicable to all web apps? Mistakes and mismanagement of loading resources is a problem for anything.
Sure it has it's problems, but there's just far too much productivity to be gained from using it. For example, Ajax animations are beyond time saving.
The real problem with angular is the terrible docs ;)
Re: Why we left AngularJS
#115I 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…
Don't be afraid of a downvote from me. Personal opinion, with content, like yours is the main reason why I read Hacker News.
Re: Why we left AngularJS
#116I 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've had a primarily positive experience criticising it and the whole javascript-mandatory mentality in general. Perhaps comparing it to early-2000s Flash sites helps.
Re: Why we left AngularJS
#117A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side renderi…
They don't belong there either.
Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
Re: Why we left AngularJS
#118Earlier quoted context omitted.
It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their intera…
" I'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation m…
There's a difference.
Photoshop wouldn't work as a website, and HN wouldn't work as a program.
Different forms for different use cases.
Re: Why we left AngularJS
#119A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side renderi…
They don't belong there either. Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
And some people still use IE6, but that doesn't mean you should continue to support IE6.
Re: Why we left AngularJS
#120Earlier quoted context omitted.
They don't belong there either. Some people use screen readers, text-mode browsers, IE due to stupid work/school policies, etc. Some people like automating their workflow, which can involve scripted browser interactions. Some people actually care about security and privacy, and so run NoScript, etc.
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?