tag:blogger.com,1999:blog-393540894130950585.post7186754085925588445..comments2024-03-22T00:23:29.865-07:00Comments on Never In Doubt: Build business apps in .NET - not HTML & JavaScriptWard Bellhttp://www.blogger.com/profile/10977457957771020146noreply@blogger.comBlogger45125tag:blogger.com,1999:blog-393540894130950585.post-60163715516178025492011-12-28T08:10:58.780-08:002011-12-28T08:10:58.780-08:00For now, I think Ward pretty much has a handle on ...For now, I think Ward pretty much has a handle on it. If you are writing a business application today .NET is a solid choice. (I would say that JAVA is also a reasonable choice in some areas of the country.)<br /><br />The thing that gets me about the whole HTML5 + JS hype is the way everyone likes to ignore the back end. They act like it doesn't exist. And without some shift beyond HTML5, these apps will continue to require a back end written in something else. (Well perhaps one could use NodeJS.)<br /><br />As for the being upset at the (alleged) demise of .NET. Get over it. First, it hasn't happened and won't happen in the next couple of years. Second, it will eventually happen so pay attention as new stuff comes out. If you have a career in IT and plan to stay in the game, you will learn new stuff at fast clip. Compare .NET 4.0 to .NET 2.0. Huge changes, and more is already in preview stage.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-21884630838792533652011-12-13T02:15:10.118-08:002011-12-13T02:15:10.118-08:00Great post ! I so appreciate this site. This is th...Great post ! I so appreciate this site. This is the information I was looking for.Thomas Gamblehttp://www.wagnermeters.com/largelumber.phpnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-4344613309387595982011-12-05T11:56:48.676-08:002011-12-05T11:56:48.676-08:00It's actually kind of fun seeing all the Micro...It's actually kind of fun seeing all the Microsoft people backpeddling. I've been working on an IBM ISeries for over 10 years, using RPGLE programs to generate HTML and Javascript (utilizaing CGIDEV2), post it to an Apache server and listen for a response and process accordingly. It gives the user a wonderful and fast experience. Now that HTML5 is out, I can't wait to use the new features.TomGhttps://www.blogger.com/profile/01565227882303986981noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-32873043637109383342011-12-05T11:52:46.452-08:002011-12-05T11:52:46.452-08:00I have been using HTML and Javascript on an IBM IS...I have been using HTML and Javascript on an IBM ISeries using CGIDev2, running Apache for almost a decade to create business applications. They meet all your criteria, plus are actively debuggable, access services running on the the ISeries which are also actively debugable. Since HTML 5 is just HTML on steroids (new tags), I don't see anything wrong with developing the front end in HTML5 + Javascript and the back end in anything you like, be it RPGLE, Cobol, C, Java or a .net language.TomGhttps://www.blogger.com/profile/01565227882303986981noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-18983317264204876082011-12-04T12:10:58.389-08:002011-12-04T12:10:58.389-08:00Ward .. always on the button .. well done.
Quite s...Ward .. always on the button .. well done.<br />Quite simply if HTML5 'cut it' then there would be no need for iPhone apps or Android apps. But it only 'cuts it' in some arenas .. so other more sophistcated solutions are required .. enter iPhone apps, Android apps and 'hey presto' Silverlight.<br />I have had a 30 year career developing Microsoft solutions for the business world. We need .Net and Silverlight.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-46913380114617864842011-12-01T19:45:55.887-08:002011-12-01T19:45:55.887-08:00as far as i know HTML5 to search engines will pay ...as far as i know HTML5 to search engines will pay more attention to HTML5, therefore there a lots of internet marketing used it.Singapore Company Incorporationhttp://www.a1-online.net/business-services/private-limited-company-setupnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-31020866692130785662011-11-25T07:35:40.242-08:002011-11-25T07:35:40.242-08:00Yes, JavaScript is still in an immature state righ...Yes, JavaScript is still in an immature state right now where there are a small portion of people that _know_ exactly how to write good JS and there are a large amount of people that just sprinkle jQuery. <br /><br />Not to mention that the language itself has more warts than any other languages out there.<br /><br />It is growing however, to the right direction nonetheless. Therefore, it is _maturing_ (who would've thought eh?)<br /><br />Having said that, there are tons of crappy .NET developers as well. I don't see a lot of .NET developers that write automation test. Plenty Windows based shops are still living in the past where they would hire tons of QA to do manual testing (that doesn't scale).<br /><br />The sad part of this ecosystem is that the QA skills aren't increasing either. The whole thing held everybody back. Very sad. <br /><br />Here's another problem with .NET ecosystems: too many friggin frameworks that MS try to push to the developers' throat. <br /><br />I met enough developers that keep pushing the latest greatest frameworks from Microsoft (WF, .NET Remoting then WCF, WinForms, Silverlight, WPF, etc) to know that Microsoft .NET is just as immature as JS. <br /><br />It took them a long time to bow down and start preaching best practices in regards on writing testable application. Even after that, they still provide less optimal support when it comes to automation test (MSTests relies heavily on internal of .NET). Makes you wonder why MS hires tons of SDET (Software Design Engineer in Test) to test their systems. <br /><br />In 2010, MS (or someone else) releases NuGet. That is very very sad. Maven was out there long time ago and solve plenty problems that .NET ecosystem is still lacking. <br /><br />Ok, enough of these whole comparisons stuff. <br /><br />I've been watching BUILD videos lately and it's a bit strange to see that most of them are pushing this Metro Style Apps in JS/HTML. <br /><br />You know what Gretzky says? "skate where the puck's going, not where it's been"<br /><br />Last but not least, I have not met a user that loves to use LOB app. Never ever ever. <br /><br />Most of them don't want Web Apps. They don't want WPF apps. They don't want Silverlight with immerse experience. <br /><br />They want console apps like this: http://www.codeproject.com/KB/dialog/FFCA/FFCA01.png<br /><br />Why? keyboard shortcuts. No mouse.Tedhttp://ted.comnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-87295346684512767302011-11-24T22:53:02.457-08:002011-11-24T22:53:02.457-08:00.Net really very powerful and protected language. ....Net really very powerful and protected language. And easy to use any hardware.Blackout curtainshttp://www.sunbusterblind.co.uk/noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-23919650788877731622011-11-23T03:35:17.157-08:002011-11-23T03:35:17.157-08:00Have you guys ever heard of C++ Builder? THAT was ...Have you guys ever heard of C++ Builder? THAT was a tool to design massive LOB in no time. The .net IDE is still a big joke when it comes to RAD. C++ Builder was full C++, had a quick compiler/linker and a very slim runtime. It had tons of extensions available... but it was not from MSFT. <br /><br />However, MSFT had WTL, which allowed to create close to API, native Win32 apps and MSFT used it internally a lot but never promoted it in public much.<br /><br />I recently looked at XAML and as a C++ programmer I will probably go with HTML5+JS any time before my eyes start to bleed from XAML+C#. Take the namespace madness which clutters up the whole markup. The non CSS styling...<br /><br />Data binding is dead simple in WinJS and in one year, when Windows 8 hits the streets, we will see how much WinJS business apps there will be.philknoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-10542376011096942942011-11-16T06:44:32.573-08:002011-11-16T06:44:32.573-08:00"...there is a relatively new breed of HTML/J..."...there is a relatively new breed of HTML/JS app that competes well with SL on UX responsiveness and ability to work in partially connected scenarios: the HTML/JS SPA"<br /><br />Ward, could you please provide an example? <br /><br />I am very interested in this scenario myself, and what comes to my mind is some sort of knockout/backbone client with server provides data/metadata in json.<br /><br />I would really like to see a real-world example of that approachAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-65160824005320787712011-11-15T17:57:39.102-08:002011-11-15T17:57:39.102-08:00A lot of "statements" since I last check...A lot of "statements" since I last checked in here. I don't feel the need to comment on them one way or the other at this point.<br /><br />But MARKO asks a question and it is an interesting one, reflecting the experience of someone whose career is all server-side app programming and no-or-little client-side programming.<br /><br />The Silverlight programmer tries to do the "heavy lifting" Marko describes ON THE CLIENT, not on the server. Trips to the server communicate mostly requests for data and requests to save (change-set of entities attached). The volume of traffic is governed mostly by these kinds of requests. <br /><br />It is also true that the server should revalidate save requests and all other commands. But that's it. And these activities do not interfere with the user's experience.<br /><br />In Silverlight, presentation, navigation, application state and workflow is all handled client-side in plug-in hosted in a Web page. From a web perspective, there is only ONE PAGE; this is a "Single Page Application" (SPA).<br /><br />Most MVC apps don't work this way. They serve pages back to the client based on requests. Yes, you can ajax-ify to minimize page churing. But that tends to be more the exception, especially in apps with many pages (let's say, >30). Such apps cannot compete with SL for UX responsiveness nor ability to survive connection disruptions.<br /><br />If your entire experience is with apps that serve pages, it is difficult to explain how much different and better SL is. How do I compare a car to a horse if you've never seen a car? You <i>think</i> you have the same capabilities with JS UI controls. But (a) you don't and (b) it's not really about the controls! It's <b>the programming model</b> that makes SL superior for LOB apps.<br /><br />Let me be clear. I am saying SL is superior to a comparatively stateless HTML app that serves pages to the browser.<br /><br />BUT ... and the following point is incredibly important ... there is a relatively new breed of HTML/JS app that competes well with SL on UX responsiveness and ability to work in partially connected scenarios: <b>the HTML/JS SPA!</b><br /><br />H5JS SPAs look very promising to me. They can handle rich state management, validation, presentation, etc. on the client with no less efficiency than an SL app. They can minimize server trips as an SL app would do. They can go offline and even launch offline if the browser supports the requisite local storage.<br /><br />This kind of HTML/JS app is suitable for LOB app development. I think the eco-system around it needs to mature ... but it is coming.Ward Bellhttps://www.blogger.com/profile/10977457957771020146noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-49876994732289339412011-11-15T03:11:41.881-08:002011-11-15T03:11:41.881-08:00I've worked with silverlight very little, some...I've worked with silverlight very little, some client resizing of images before upload and that's it...didn't have oportunity to code business application, I am asp.net mvc guy...So I have half statement half question...<br /><br />When your team code silverlight application I suppose "the heavy lifting" in terms of complex business validation, tests, business logic, all done on server and in app you have manipulations with data through silverlight controls...we now have js controls for this and that and it works fairly nice and good...could you explain it to me/us here, what is in client side developments with c# knows as silverlight so advanced comparing to js tools/frameworks?<br /><br />thank you :)Markohttps://www.blogger.com/profile/11244009315325041090noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-9842749169312271512011-11-14T12:06:59.359-08:002011-11-14T12:06:59.359-08:00@Arcadia
"..VB programmer had to move on to C...@Arcadia<br />"..VB programmer had to move on to CLR 10". <br />Totally not the same. VB.NET promised better technology and everyone understood that. The problem was MS did not provide the way to migrate, or backward compatibility and that made a lot of devs cry.<br /><br />Currently we are pushed to the technology that it is not better. It's on par at best. In future. Maybe.<br /><br />It has only one advantage - it's cross-platform (provided you use right subset) which is not much of advantage for business development.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-79013629089251881042011-11-14T11:44:19.765-08:002011-11-14T11:44:19.765-08:00Just stress the point, a worth read of how the fut...Just stress the point, a worth read of how the future LOB will be shaped, http://www.thephoenixprinciple.com/blog/2011/11/how-best-practices-kill-productivity-innovation-and-growth.html that explains why Microsoft has to make such a dramatic turn while there is no immediate threat from anywhere, much less to LOB, but the clock is ticking.Arcadiahttps://www.blogger.com/profile/16523181393818991150noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-21480017274446881572011-11-14T10:08:49.895-08:002011-11-14T10:08:49.895-08:00This comment "Embrace, Extend & Lock-in t...This comment "Embrace, Extend & Lock-in tactic" nails it, speaking to the fact technology is now more of a market moniker than it was 10,20 years ago. As long as both consumers and developers buy in the hype of html5/js it sells, which is really what matters to the "business" decision, not truly a developer's yet heavily influenced by developer community. The concerns of .net community is more related to career and less about the right tool to create solution. LOB will continue to be developed in .net knowingly UX is driven by the consumer demands and soon by business too will enjoy most of future proof progress in html5/js than SL or .net. That is a fact and history just kept on repeating itself for anyone hang around long enough such as those who used to be a VB programmer had to move on to CLR 10 years ago. For that matter, VB6 LOB did last for a few years until recent time. So Microsoft is simply pulling the same trick again and you'd have no choice but carry on, unless of course one learnt from history and willingly spent own time (or business time) for self-training of anything outside of Microsoft's domain so prepared. The current game in town is mobile, html5, even mighty Microsoft has to watch it. Both Windows shell and office are moving towards it is the proof, so will be LOB soon or later.Arcadiahttps://www.blogger.com/profile/16523181393818991150noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-76395187647574930002011-11-13T17:39:37.724-08:002011-11-13T17:39:37.724-08:00What's going on here is not about HTML5/JS. MS...What's going on here is not about HTML5/JS. MSFT could care less about it other than this vast # of JS developers could turn into potential Win8 buyers. What's really going on is that Windows team wants to kill SilverLight. They wanna do it really bad. As if it were not bad enough, Office team wants to terminate it as well.<br /><br />Win8's attitude toward HTML/JS is nothing but a classic <b>Embrace, Extend & Lock-in tactic</b>. If you could get those JS people love Metro then you could sell lots of Win8 and Win8 tablets so there MSFT goes to show HTML/JS folks love - <b>embrace</b> - while tying their HTML/JS support to a proprietary WinRT - <b>extend</b> - that way these JS guys could get stuck with Win8 from now on - <b>lockin</b>. It might not be the smartest strategy but it would not hurt much trying either.<br /><br />The real story is the public execution of SilverLight. Windows and Office teams could not sleep well knowing SL is out there. Not only SL does not make money on its own it threatens both Windows and Office teams if it keeps getting better and becoming a real rich internet platform. People might not need to buy Windows any more with SL. Google could re-write their current laughable Google Apps in SL to finally hurt Office team's market share.<br /><br /><b>ABSOLUTELY UNACCEPTABLE TO THE WINDOWS AND OFFICE TEAM!!! CANNOT ALLOW THAT TO HAPPEN!!!</b><br /><br />This is MSFT. You know what's gonna happen when you mess with those two teams. The rest is history.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-90946591862499447702011-11-12T13:35:58.805-08:002011-11-12T13:35:58.805-08:00The problem with all this "shift" for me...The problem with all this "shift" for me is that it is the first time I have a feeling I am pushed to inferior (yet, maybe) technology from the technology that fits my development's needs perfectly. I just see gaps where I do not have them now. I see advantages too but there are not so many to justify that shift.<br /><br />It's like I am pushed from all my languages I use in .NET back to VB6 with an argument that it is a most abundant language in the world. (It's incorrect comparison, strictly speaking, but same emotions) <br /><br />On the bright sight - I know, from the previous experience, that this will never happen. Trend will change exactly the moment HTML5 will succeed:)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-23476980125437208602011-11-12T11:13:49.565-08:002011-11-12T11:13:49.565-08:00This html5+js IS NOT cross platform! it's tied...This html5+js IS NOT cross platform! it's tied to the WinRT API.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-5658394186647464322011-11-12T08:53:09.148-08:002011-11-12T08:53:09.148-08:00One of the problems with developers today is that ...One of the problems with developers today is that they are often not very seasoned in the industry. I don't mean they aren't smart, what I mean is that they haven't been around long enough to understand that there will always be yet another tool or technique, and that there never is a "one size fits all". This is why the ecosystem is so diverse, and for anyone who believes that a single technology will rule them all just hasn't been around long enough to have experienced the cycle this industry goes through. I've seen the waves of structured design, rapid application development, object oriented, client server, web, and the the list goes on and on. The point is that this industry is about change. If you can't take the experience you have from one platform and learn to apply it to another, then you really aren't prepared to be successful in the long term. <br /><br />The second problem to me is that many developers haven't gained the wisdom and experience to understand that developing software is less about tool set as it is about how to properly gather requirements, understand user needs, design delightful experiences, and many other factors that have little to do with the tools that you end up using. Our tools are light years ahead of what we had even 20 years ago, yet I still see developers struggling to deliver great software. Not because of tools, but because the biggest challenges in software aren't technical, they are human. But most new developers want to take the tools they are most familiar with and apply them to everything, not understanding that to a user the technology you used to build an application isn't relevant, they don't care. Users do care about the experience, capabilities, and costs involved. <br /><br />As for the anonymous post that claims that "when you bank on a specific proprietary technology..." you become obsolete. I'd have to disagree as I have developed now for almost 30 years with many proprietary technologies and am still completely relevant in the market. The difference is that I can apply my learning forward to the next wave. I'm currently employed in a great position with a solid 6 figure salary, work with pretty exciting technology on a daily basis (phone apps recently), and continually have offers for new opportunities. But that is less because of the technologies I've used but the proven success I have in using them. You'll find that a smart employer, and I personally prefer to work for smart employers, are looking for people who can adapt and be successful with any technology, not just one. So if you think that because you've chosen open technologies you will be relevant longer, let's swap stories in about a decade and see how well it worked out for you.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-3104460038309843102011-11-12T06:54:21.502-08:002011-11-12T06:54:21.502-08:00There is no easy way to write business application...There is no easy way to write business applications in. Net or Html5/JS. Regardless of the technology must continually improve, when to start, if not nowMilanCHEhttp://milanche.blog.comnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-72841936663560128062011-11-12T06:42:40.799-08:002011-11-12T06:42:40.799-08:00I am posting this because I have wrote - WinFoms, ...I am posting this because I have wrote - WinFoms, WPF and Silverlight apps. Period. ;)<br /><br />I am not sure about your point on "minimal trips to server". Because as you said LOBs are data centric - so they must access database = server round trips. Unless you are suggesting local storage.<br /><br />Also as simple thing as event handling should be thought well before writing LOB in any of client app in .net - this answer your claim on - "hence the need for Crockford's "JavaScript - The Good Parts"<br /><br />Finally no one has heard bad XAML project because they have already invested so much in it - they can't afford it to say "it failed".Ashish Agrawalhttps://www.blogger.com/profile/12900400454491787183noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-44073302646890651772011-11-12T06:30:03.155-08:002011-11-12T06:30:03.155-08:00This comment has been removed by the author.Ashish Agrawalhttps://www.blogger.com/profile/12900400454491787183noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-79797510308437439372011-11-12T06:19:49.109-08:002011-11-12T06:19:49.109-08:00I agree with Ward. If it is MY business I am going...I agree with Ward. If it is MY business I am going to use LightSwitch. The reason is that if it is MY business and I am burning through MY money then I want the 98%+ savings in development.<br /><br />I also agree with the people who posted about the job market. My landlord could care less about Silverlight vs HTML5. <br /><br />You will find me in my cubicle during the day programming a lot of JavaScript...Michael Washingtonhttp://lightswitchhelpwebsite.comnoreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-78881548400200205172011-11-12T04:53:05.666-08:002011-11-12T04:53:05.666-08:00Hi Ward, your article tastes like honey to me! I h...Hi Ward, your article tastes like honey to me! I hate JavaScript - and i seriously think, that it is not made for real world business applications - at least - I would't use it to create REAL business applications. Storytelling from the marketing department...@awsomedevisgerhttps://www.blogger.com/profile/03459202875696842013noreply@blogger.comtag:blogger.com,1999:blog-393540894130950585.post-62158313535869492352011-11-12T02:54:51.244-08:002011-11-12T02:54:51.244-08:00This comment has been removed by the author.Adriaanhttps://www.blogger.com/profile/12103291600899387404noreply@blogger.com