06:33:50 AM
3FJ0E2KLN
The number of .NET developers has declined.. There are plenty of .NET jobs out there though. Go on Google and type "Shortage of .NET developers" We use many technologies at my company.. When a young programmer asks me what he/she should put effort into learning, I dont tell them foxpro or C#.. I tell them put your effort into Javascript.. Thats where it's all heading.. Like you said in one of your earlier posts -> most phone apps in the future will be javascript apps..
In my opinion Microsoft thought they would guide the world "lemming developers" in their direction. I laughed when many vendors wouldn't allow flash and silverlight in their browsers.. Now MS wont even allow Silverlight in their own IE 10 browser.. MS goes where the money is.. even if they put billions of dollars into something, dragging lemming developers along the way.. then MS drops the project and the lemming developers go over the cliff.. Many developers have switched to ruby - python - php - java and other techs so they're bound by MS..
The above creates json faster than all the other ways I've done it in vfp... unless I just need 1 or 2 records.. then I do a SEEK ... SCAN WHILE.. generate the json in the loop.....
Of course it's faster, because you're not checking for valid json so you're not parsing the string as any other parser has to do. The perf difference will be significant. However, if you have special characters, your JSON breaks, which is even less cool :-) The bottom line with this IMHO: If it hasn't broken your client code yet, you're lucky that it hasn't or you're not testing edge cases hard enough.
I'm sure other people have better.. faster ways... I was just saying that in the past this was faster at creating json than C# in .NET.. but it looks like MVC had many improvements added to it in the ajax/json area.
Actually JSON production can be done in a lot of different ways and MVC is not even necessary to make that work especially if you're building an SPA app. A service is the way to go for this actually (and I'd argue that for any platform including VFP). Separation of concerns. OTOH, none of the native .NET JSON parsers support ADO.NET objects natively (you can build your own converters) but various third party parsers and tools do.
So I'm sure Rick is right about C# .NET is faster... I just want to see for myself...
My point wasn't that .NET is faster or better - frankly for 90% of the apps people build performance of language/runtime has become mostly inconsequential due to faster hardware and optimization.
Instead I'm trying to point out that a lot of things that die-hard FoxPro people keep clinging to are not always true - they're based on hear-say and second hand knowledge. There are things that VFP *does* do better, but honestly there are not that many of them. The main differentiator of VFP and other languages/tools IMHO is that:
While that's powerful and nice it also isn't necessary in most scenarios and even undesirable if you're using a SQL backend (which also then works different in VFP natively).
What else is there that you can't do in other languages? Not much...
I've been using ExtJS 3/4 for 2 years now... works like a charm... If I take just the json produced and run it through jslint... I'ts valid... no trailing comma "that IE doesnt like"
No argument there. Client side libraries don't require Microsoft or any other big company to back them and there are lots of choices most of which mix and match just fine. But also realize that this is also not a one size fits all. ExtJS is for LOB/Form UIs and doesn't work so well for free form, document centric UIs. Heck even ExtJs is in flux with the move to Sencha which uses a completely different mechanism from the ExtJs UI framework even though it's the same team doing the work.
There's no right or wrong with anything. If you have something that works for you you should stick to it as long as it makes sense politically. I have no interest on selling anybody on any other technology, but I get really miffed when people misrepresent tools to do things 'better' when that's often not the case.
I also want to make it clear that I still support FoxPro with the tools I sell and I love doing it and continue to evolve them even though the financial incentive to do so has long since dried up...
+++ Rick ---
