Yeh but is it the best use of time to have the same dev do it all? We have dedicated front end people here that knock amazing stuff up in a day that would take me at least a week and even then my stuff wouldn't be even remotely as well structured as theirs. It's the old jack of all trades master of none argument. Whatever happened to "separation of concerns"?
On Tue, Aug 25, 2015 at 9:00 AM, Stephen Price <step...@perthprojects.com> wrote: > Yeah, I've heard it said that .Net (ie Microsoft) had for a long time > tried to shield you from having to learn Javascript. Webforms and Asp.Net > protects you from having to learn all that horrible web stuff. MCV took a > step to get you closer to the browser, and I think it's a good thing. > So given everything is moving towards the Web (for now) and away from the > desktop it's something (for good or bad) that you need to learn. I love > working with Javascript and have not mastered it. I can find my way > eventually. > I love the learning part of development and often find how things don't > work how you expect to be frustrating. Unfortunately its usually due to a > lack of proper understanding that makes it not work how you expect. > Anyway, once you do figure something out that's where you get > satisfaction. But yeah, totally get why if feels like a dogs breakfast > along the way. Probably because it is! > Its like finding out the aircraft you are flying in is held together by > gaffa tape and coathangers! (most of the web is!) > > > On Tue, Aug 25, 2015 at 6:28 AM, Bec C <bec.usern...@gmail.com> wrote: > >> IMO most .net devs won't really be happy doing any JS, via a library or >> not. We just want to do the .net code and leave the front end to someone >> else. Just like the Silverlight evangelists promised. Don't see that >> happening though. Everyone seems to want a full stack developer now...and >> I'm struggling. >> >> >> On Tuesday, 25 August 2015, Paul Glavich <subscripti...@theglavs.com> >> wrote: >> >>> Greg and others, >>> >>> >>> >>> One of Javascript’s strength is also it’s weakness. You can do literally >>> anything with it. It is one of the most flexible and adaptable languages >>> there is. This (IMHO) is one of the reasons it is popular. With that, many >>> people twist and change it to what they think is best, and there are plenty >>> of differing opinions, so here we are. >>> >>> >>> >>> As industry experts/veterans, it is always a challenge to look at the >>> good parts of a framework/approach and: >>> >>> a) Accept the bad bits and use it >>> >>> b) Accept only the good bits and augment so that the bad bits are >>> mitigated >>> >>> c) Watch and provide input to try and steer >>> communities/frameworks/languages in the desired direction >>> >>> d) Do it all using the basic accepted tools currently available. >>> This means things like just plain js/ jQuery/ES6(maybe using things like >>> babel) etc. >>> >>> >>> >>> It is all in flux right now hence my call to wait it out for a bit >>> (which libraries gain community momentum). To expect a strict guidance on >>> how to do things in a particular framework for a large application is >>> always going to be contentious in our field because of the “it depends” >>> clause. There is no one way. The fact that you have had to research >>> something quite a bit should at the very last have helped you form a much >>> leaner and clearer picture of what you want, which can feed into the >>> constant decision process as well as design. >>> >>> >>> >>> It is not easy but do not get too hung up on getting the perfect way via >>> a particular tool (analysis paralysis). Pick the best possible that you >>> think applies to you, weigh the risks and commit. The rest you can tailor >>> to what you want. Final note: On a current project we are using Angular, >>> however there are legacy elements still working fine but using >>> prototype.js. Point being, at the end of the day, if you are just using >>> plan old JS (whether via a particular library) it will continue to work for >>> a long long time. >>> >>> >>> >>> - Glav >>> >>> >>> >>> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >>> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Adrian Halid >>> *Sent:* Monday, 24 August 2015 9:23 PM >>> *To:* 'ozDotNet' <ozdotnet@ozdotnet.com> >>> *Subject:* RE: Last words on AngularJS >>> >>> >>> >>> In the world according to Github Javascript is now the number 1 popular >>> programming language used in their repositories. Might be due to all the >>> Javascript frameworks out thereJ. >>> >>> It is also interesting to see the climb of Java from 7th to 2nd over >>> the last 7 years. >>> >>> >>> >>> https://github.com/blog/2047-language-trends-on-github >>> >>> >>> >>> >>> >>> >>> >>> *Regards* >>> >>> >>> >>> *Adrian Halid* >>> >>> >>> >>> *From:* ozdotnet-boun...@ozdotnet.com [ >>> mailto:ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Greg Keogh >>> *Sent:* Monday, 24 August 2015 6:26 PM >>> *To:* ozDotNet <ozdotnet@ozdotnet.com> >>> *Subject:* Re: Last words on AngularJS >>> >>> >>> >>> Paul, most of what you said actually supports my anguish over the >>> "lottery" of kits, tools, packages and "standards" (ha!) and fads in the >>> JavaScript ecosystem. >>> >>> >>> >>> Over the last week or more since I expressed my dismay, I've been >>> reading more and more about the zoo of frameworks that decorate JavaScript >>> and attempt to hoist it up into the world of "real languages". It's getting >>> so stupid that the AngularJS seems to have decided to completely rewrite it >>> for v2 using TypeScript, and someone got upset and split off to make >>> Aurelia because it was more "pure", but apparently they're friends again >>> now, I think. It's worse than a zoo, it's like a steaming compost bin. >>> >>> >>> >>> I got all excited about TypeScript last weekend and I spent an afternoon >>> reading about it and fiddling to see if it has promise. So I create a new >>> HTML project and I get one small source file that shows the time. The >>> sample code is raw JS from the 90s and I have to go looking for a way to >>> integrate jQuery and/or AngularJS into the project. So dozens of >>> opinionated pages later I discover I just about have to reinvent the steam >>> engine to try an integrate them, and there are literally dozens of experts >>> all claiming they know they best way to do it, with all sorts of cryptic >>> pseudo-functional coding tricks. I simply want to know how to structure a >>> large TS project, but there is no reliable guidance anywhere, it's just a >>> dogs breakfast. >>> >>> >>> >>> This is what happens when a script becomes accidentally promoted to >>> become the new fangled language to drive LOB apps in the web without proper >>> planning by industry experts and academics. There are no conventions for >>> code or project structure, references, dependencies, building, testing ... >>> anything! ... it's just a bottomless kludge of more tools made in >>> JavaScript to try and make itself look and behave sensibly. >>> >>> >>> >>> I am now overwhelmed by despair at what damage JavaScript has done to >>> software development in the 21st century. I know there are lots of younger >>> developers out there who shrug and think "what's so bad, it's working", but >>> I think they're just used to suffering and take it for granted. >>> >>> >>> >>> *Greg* >>> >>> >>> >>> List of JavaScript Libraries >>> <https://en.wikipedia.org/wiki/List_of_JavaScript_libraries> >>> >>> >>> >> >
