Well as I said, context.
What you have listed are options. Assess, then make a call. However, my dependency chain is calling. Need to make it longer…. :) - Glav From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Wednesday, 30 November 2016 9:26 AM To: ozDotNet <ozdotnet@ozdotnet.com> Subject: Re: [OT] node.js and express ES6 Typescript AngularJS 1.5 Angular2 Aurelia Polymer YARN NPM react grunt gulp This list extracted from Glav's message should be a hint that JS is on the fritz, and it's the tip of the iceberg -- Greg K On 30 November 2016 at 09:13, Paul Glavich <subscripti...@theglavs.com <mailto:subscripti...@theglavs.com> > wrote: It depends :) However in an attempt to answer, which usually requires a lot more context and thought, here we go: * I’d choose ES6/Typescript at a minimum. ES6 imports/modules/classes are pretty handy and good to separate out your logic. Typescript is also good for structure/”pretend static-ness” and helps with catching errors but is not to everyones flavour. * I would then consider the following: o AngularJS 1.5 * I’d consider this because it is well known (not bleeding edge) and can be easily packaged with no dependencies, thus reducing risk. o After consultation with whatever team is working on and assessment of their JS skillset, I would also consider: * Angular2/Aurelia/Polymer (I personally like Aurelia but that is purely personal) * This would be dependent on the teams skill level and application requirements. A proficient javascript team can overcome any JS limitation or issue, irrespective of framework * In addition, I’d look at using something like YARN (vs NPM) as a package manager to reduce issues with package inconsistency. * Note: I didn’t mention react simply because I don’t like it. No technical reason – it just is fugly :). In addition, it went from v0.14.8 to v15.0.0 in one release. Not sure what versioning world it came from, but that is not sequential, semantic or anything in between. * As a caveat to this, in a current engagement I recommended the team use Angular 1.5 because o The team was familiar with it. o Team had no idea about grunt/gulp/ES6/Angular2 etc. o Had tight timeframes with no leeway to ramp up time. o I am only on the engagement 2 days a week and cannot effectively on ramp it in addition to working on CI/CD, architecture, team process etc. o So far, this is working very well and has been a good decision. Hope that clarifies my thinking somewhat. - Glav From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> ] On Behalf Of Adrian Halid Sent: Monday, 28 November 2016 10:17 AM To: 'ozDotNet' <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> > Subject: RE: [OT] node.js and express If you were to start a new Enterprise Web Project which has the potential to be continually developed and enhanced over 5 to 10 years what web technology frameworks would you choose? Regards Adrian Halid From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Paul Glavich Sent: Monday, 28 November 2016 6:18 AM To: 'ozDotNet' <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> > Subject: RE: [OT] node.js and express Yeah pretty much :) I am a web guy through and through and I don’t mean to hack on people specifically, but as an industry it still manifests as real immaturity. I also don’t mean to suggest we don’t use and play with the new stuff either but the level of acceptance, particularly from people way smarter than me, is puzzling. It is real easy to be critical (like I have here…. ) so providing feedback on progress is pretty important. Doesn’t always work as momentum can carry it through (I am looking at you Angular2). My rather rambling and opinionated point is that on a few engagements, I have recommended to not use the shiny new stuff, in favour of older but well known, and easier to maintain frameworks (after assessment of timeframes, people’s skillsets etc). Not using the latest in those cases has proven to be a boon, rather than an impediment. Sure it is lower on the coolness scale, and could be replaced with newer stuff later (obviously with a little rework) but it is working very well. It kind of suggests we perhaps invented part of the problem to solve in the first place. So I think play and assess the new stuff (like Greg has), but don’t blindly accept. Then engage and provide some form of influence or feedback so we don’t re-introduce the same mess in another 10 years. - Glav From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Scott Barnes Sent: Sunday, 27 November 2016 9:40 PM To: ozDotNet <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> > Subject: Re: [OT] node.js and express So Paul, you're basically saying "The standard we walk past, is the standard we accept" hehe :) --- Regards, Scott Barnes http://www.riagenic.com On Sun, Nov 27, 2016 at 8:31 PM, Paul Glavich <subscripti...@theglavs.com <mailto:subscripti...@theglavs.com> > wrote: Ahh the recurring thread about how immature the JS/Web dev community is and how hard it is to do anything “right”. All I will say is we asked for it. If we didn’t ask for it, we accepted it. If we didn’t accept it, we assumed that the new was good and ran with it. We make a whole lot of assumptions on server side tech and place a whole deal of constraints and measures on it. Not so on client dev. Massive external dependencies are abhorrent on server side. On client side, they are celebrated (to cite an example). We built it and promoted it. It is on us, not the vendors. I *think* Greg Keogh started with this with some investigations on how hard it was to implement something using framework/technique X. Cool. You have learnt what not to do, not how to do something with the latest tech just because Scott Hanselmann mentioned it. Caveat: I am an old bastard. This argument is not new, but it is compounded by an increase in velocity in general. - Glav From: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com [mailto: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com] On Behalf Of Nathan Schultz Sent: Friday, 25 November 2016 4:13 PM To: ozDotNet < <mailto:ozdotnet@ozdotnet.com> ozdotnet@ozdotnet.com> Subject: Re: [OT] node.js and express @Greg, the last version of LightSwitch you could choose either HTML5 or SilverLight on the client. But you're right... it's no longer an option. On 25 November 2016 at 11:25, Greg Low (罗格雷格博士) < <mailto:g...@greglow.com> g...@greglow.com> wrote: Yep, Lightswitch is dead. It was Silverlight based. Regards, Greg Dr Greg Low 1300SQLSQL <tel:%281300%20775%20775> (1300 775 775) office | <tel:%2B61%20419201410> +61 419201410 mobile│ <tel:%2B61%203%208676%204913> +61 3 8676 4913 fax SQL Down Under | Web: <http://www.sqldownunder.com/> www.sqldownunder.com | <http://greglow.me/> http://greglow.me From: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com [mailto: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com] On Behalf Of Nathan Schultz Sent: Friday, 25 November 2016 2:20 PM To: ozDotNet <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> > Subject: Re: [OT] node.js and express Arguably, a productive web-based RAD tool is exactly the sort of niche that Microsoft LightSwitch was trying to fill (although I'm pretty certain it's now dead). As I said earlier, we use OutSystems here, and I believe it's an area that Aurelia.IO and other vendors are growing into as well. On 25 November 2016 at 11:00, Greg Low (罗格雷格博士) <g...@greglow.com <mailto:g...@greglow.com> > wrote: But that's exactly the point Scott. Why have we gone so far backwards in productivity? Regards, Greg Dr Greg Low 1300SQLSQL (1300 775 775 <tel:%281300%20775%20775> ) office | +61 419201410 <tel:%2B61%20419201410> mobile│ +61 3 8676 4913 <tel:%2B61%203%208676%204913> fax SQL Down Under | Web: www.sqldownunder.com <http://www.sqldownunder.com> _____ From: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com < <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com> on behalf of Scott Barnes < <mailto:scott.bar...@gmail.com> scott.bar...@gmail.com> Sent: Friday, November 25, 2016 12:09:38 PM To: ozDotNet Subject: Re: [OT] node.js and express "It Depends" on what tool you're looking at. If all you're doing is staring at Visual Studio and that's it and wondering why the world is so hard to develop for then that's not a realistic outcome, as despite all the OSS rhetoric, Microsoft is still preoccupied with Windows first class citizen approach to roadmaps. They'll dip their toes in other platforms but until revenue models change, tool -> windows. The rest will just be additive biproduct / bonus rounds outside that. Products like Unity3D and Xamarin were the answer to that question but not as "drag-n-drop tab dot ship" as Winforms of old.. those days are well behind us now. --- Regards, Scott Barnes http://www.riagenic.com On Fri, Nov 25, 2016 at 9:54 AM, Greg Low (罗格雷格博士) <g...@greglow.com <mailto:g...@greglow.com> > wrote: So it then comes back to tooling again. Why can’t I build an app with the ease of a winform app and have it deployed in the current environments? Surely the app framework should fix the underlying mess and let me code to a uniform clean model. Regards, Greg Dr Greg Low 1300SQLSQL <tel:%281300%20775%20775> (1300 775 775) office | <tel:%2B61%20419201410> +61 419201410 mobile│ <tel:%2B61%203%208676%204913> +61 3 8676 4913 fax SQL Down Under | Web: <http://www.sqldownunder.com/> www.sqldownunder.com | <http://greglow.me/> http://greglow.me From: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com [mailto: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com] On Behalf Of Ken Schaefer Sent: Thursday, 24 November 2016 9:41 PM To: ozDotNet < <mailto:ozdotnet@ozdotnet.com> ozdotnet@ozdotnet.com> Subject: RE: [OT] node.js and express I guess the conclusion I would draw from that is not so much that the “web world is so much worse because we have to cater for all these clients” as “the web world is the only feasible answer to catering for all these clients – it’s simply not financially feasible to do it via thick clients” From: <mailto:ozdotnet-boun...@ozdotnet.com> ozdotnet-boun...@ozdotnet.com [ <mailto:ozdotnet-boun...@ozdotnet.com> mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Nathan Schultz Sent: Wednesday, 23 November 2016 5:40 PM To: ozDotNet < <mailto:ozdotnet@ozdotnet.com> ozdotnet@ozdotnet.com> Subject: Re: [OT] node.js and express As I said in my first e-mail, (when Greg was wondering what the key drivers were for web-development), I said "accessibility". Thick clients are simply not transportable. So the simple answer is, you don't. On 23 November 2016 at 14:21, Ken Schaefer <k...@adopenstatic.com <mailto:k...@adopenstatic.com> > wrote: From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> [mailto:ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com> ] On Behalf Of Nathan Schultz Sent: Wednesday, 23 November 2016 5:10 PM To: ozDotNet <ozdotnet@ozdotnet.com <mailto:ozdotnet@ozdotnet.com> > Subject: Re: [OT] node.js and express @Ken, your definition of Technical Debt isn't that different from that of Martin Fowler's. Although I'd say (with some seriousness) that JavaScript is Technical Debt ;-) I've found many of the things you mention far worse in the web-world (where you sometimes have to cater for everything from a mobile phone to a quadruple monitor desk-top, and everything in-between, all with different OS's, software, plug-ins, versions, and incompatibilities). I’m curious to know how you’d cater for this variety of consumers if you were to do thick-client development? Wouldn’t that be even more of a dog’s breakfast of OSes, development environments/languages, pre-requisites you’d need to ship etc?