We've done a couple of largish Enterprise Angular apps for customers back-ending on to ASP.NET/SQL Server. I can't say I share the sentiment around bloat that is in this thread. At the end of the day you can do good engineering in almost any platform - as you can do crappy engineering in almost any platform.
The end users LOVE the responsiveness of single page apps. If you stay diligent to using a responsive theme then they work really well on desktop, tablet, and mobile. I am not sure it would be my choice if I was developing a site for a mass consumption by end users, but by the same token I am not sure it wouldn't be. If the last decade has taught us anything, nothing is certain but change. What is technically optimal or desirable might not be what is adopted. Also, even if substandard / ridiculous technology is adopted (node.js, Android) then it still might produce excellent results. Android is a great case in point ... if you told me 5 years ago I would love highly responsive, smoothly animated and beautiful java apps written to run on my linux phone from LG or Motorola then I would have laughed at you. On Mon, 10 Aug 2015 at 11:31 Scott Barnes <scott.bar...@gmail.com> wrote: > When we were making Silverlight we looked at the 800lb gorilla that which > is JS/HTML and wondered what that competitive scenario would look like. The > research that came back from Gartner/Forrester etc kept pointing out to the > fact that folks would adopt AJAX under the sugar rush of open-ness and > uniform simplicity but would later bloat and impact post-delivery > optimisation / refactoring etc due to the nature of at the time both > tooling and developer skills. > > I'm not sure how relevant that is today but that for me always left the > mark of a root cause less about the symptoms thereafter. > > Netflix is still experimenting here, so i'd not rush out and declare "oh > they did it so should we" as these scenarios have a habit of playing > themselves out into "oh yeah here's what we actually learned" post the > adoption. That or when you look at the level of engineering that went into > making these happen and the point where adoptions of frameworks no longer > fit the "just use the as-is and don't pioneer outside the framework" hidden > clauses that's when you truly the potential positive/negative gains of an > adoption here. > > I'm still not convinced we've settled on a javascript works model ehre, it > still feels clumsy and i suspect as more and more developers pile on, test > the ideas / hypothesis on a multitude of scenarios & contexts its when the > cracks emerg, it's then we see how we react collectively. If the cracks can > be patched up and progress is retained, there's gold in those hills but if > it means abandonment or pick a similar approach but coded differently then > I suspect its less the framework of choice and more the language set that > holds back. > > Lastly, i'm also quite curious to see how Google absorbs the adoption of > RIA solutions like AngularJS, inline JS has perks for developer hearts & > minds but when you want a search engine like Google/Bing to index and > absorb the existing search protocols we have today, this is also a problem. > Google has tried and failed over the years to keep some sense of > containment in deep linking solutions like this and it's not been easy road > to travel for both devs and them (Flash for example opened up its SWF > borders to Google and it had weak success and that's with a fairly strongly > typed language set). Today its open season on this, so for apps inline is > great for external apps or sites... meh your milage could easily vary on > this one. > > > > > --- > Regards, > Scott Barnes > http://www.riagenic.com > > On Mon, Aug 10, 2015 at 11:10 AM, Dave Walker <rangitat...@gmail.com> > wrote: > >> I think some of the pain they are discussing in that article is the same >> pain that caused Netflix to look to adopt JS on the server as well e.g. >> http://techblog.netflix.com/2015/08/making-netflixcom-faster.html >> >> Some of the benefits that they spell out are also probably just a direct >> result at looking at everything holistically and making improvements. You >> rewrite anything and there is a good chance that you can optimise alot of >> it out. >> >> On 10 August 2015 at 12:18, Michael Ridland <rid...@gmail.com> wrote: >> >>> >>> *'writing monolithic client-side apps in JavaScript frameworks is an >>> evolutionary dead-end, and I pray that the future history books will prove >>> me right.'* >>> >>> FYI, this has already begun with companies like Shopify >>> <http://www.shopify.com/technology/15646068-rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript> >>> dumping rich clientside js and Basecamp never going that path. >>> >>> Thanks >>> >>> *Michael Ridland | Technical Director | Xamarin MVP* >>> >>> XAM Consulting - Mobile Technology Specialists >>> >>> www.xam-consulting.com >>> >>> Blog: www.michaelridland.com >>> >>> >>> >>> On Mon, Aug 10, 2015 at 9:46 AM, DotNet Dude <adotnetd...@gmail.com> >>> wrote: >>> >>>> AngularJS feels the same as Silverlight version 1.0/1.1 to me, I feel >>>> dirty just thinking about it >>>> >>>> >>>> On Sun, Aug 9, 2015 at 9:02 PM, Scott Barnes <scott.bar...@gmail.com> >>>> wrote: >>>> >>>>> Adobe Flex, Silverlight and WPF all have the same techniques described >>>>> and issues with AngularJS. The issue in question is more around the >>>>> ability >>>>> to load/unload views in an elegant fashion that leaves you with a sense of >>>>> simplicity or cleanliness in memory collection as well. >>>>> >>>>> Binding is also a huge issue, it was never really rectified as cleanly >>>>> as I had hoped over the years as i still see binding a problem similiar to >>>>> how I guess Entity Framework started out "I want to visualise how that >>>>> field gets its values and trace its origins back through the rest api's >>>>> down to the metal if need be.." >>>>> >>>>> As that's where profiling and stuff comes back to the forefront and >>>>> helps steal some of the sting out of exceptions. >>>>> >>>>> I think you're on the same hunt we've always been on since 2005-2009 >>>>> whereby we want to create inline apps that have deep linking style loading >>>>> but without the complexity and code management overheads. >>>>> >>>>> AngluarJS or whatever isn't really meant to last beyond maybe a year >>>>> or two. Anyone who's still shooting for an app that gets designed in 2015 >>>>> and still useable and manageable in 2020 is on a fools errand as today, >>>>> the >>>>> modernizing of apps is constantly going to push your comfort levels. >>>>> Microsoft is also quite hungry to regrow its grass roots so i'd expect a >>>>> bit more of healthy chaos from them here as well. >>>>> >>>>> That all being said, the JS route is steps backwards not forwards as >>>>> its still trying to pickup from lost ground that tech like Winforms, >>>>> Silverlight, WPF and Adobe Flash/Flex (yeah even these had it better) and >>>>> it's still a bit of a hacky approach to obsfucating as much of free >>>>> thinking JS from the devs as possible. >>>>> >>>>> I think you're feeling the inertia though of the wild js-west, in that >>>>> there are really no rules here or compiler feedback loops.. you write it, >>>>> it does something visually and you can't see any obvious signs of memory >>>>> profilers going out of shape...hey...ship it... and that's the part that >>>>> leaves me a bit personally nervous ;) ..as in the hands of a "mature" dev >>>>> it could work great and longevity intact...but...in my experience not all >>>>> teams are "mature" and you have a variety of styles of thinking / code >>>>> here >>>>> so it's now back to some serious code-reviews to maybe act as the last >>>>> safeguard in thinking here? >>>>> >>>>> *if* i had to pick i'd say AngularJS is probably the closest to the >>>>> previous styles of thinking and that's probably the first red flag ;) >>>>> >>>>> --- >>>>> Regards, >>>>> Scott Barnes >>>>> http://www.riagenic.com >>>>> >>>>> On Sun, Aug 9, 2015 at 7:35 PM, Greg Keogh <gfke...@gmail.com> wrote: >>>>> >>>>>> We're you using RequireJS? >>>>>>> RequireJS is something you can use to bring in common and worker >>>>>>> viewmodels. >>>>>>> It may be your missing link! >>>>>>> >>>>>> >>>>>> I just had a glance over the main web pages. In a rush I get >>>>>> impression that this is library that simulates dependencies between >>>>>> JavaScript files (because there is no such native concept). I can't >>>>>> picture >>>>>> in my head how this would boost productivity or enhance the development >>>>>> experience, it looks like just something else to clutter and confuse what >>>>>> you're doing. But it's late, so I might be missing the point and I need >>>>>> to >>>>>> read more -- *GK* >>>>>> >>>>> >>>>> >>>> >>> >> > -- David Connors da...@connors.com | @davidconnors | LinkedIn | +61 417 189 363
