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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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* >>>> >>> >>> >> >
