My Theory on why Javascript is winning
-
I'm in a situation where I need to replicate client side and server side code. I wish I could just write the code once (in C#) and reuse it client side. The Great Dream. Javascript has been on the client (browser) side forever. For a time it competed with VBScript in Microsoft's attempt to dominate. VBScript on the client failed for all the usual Microsoft reasons, leaving the client side to Javascript (we won't mention Flash). Java had a crack at the client side but Microsoft sabotaged that (those were bad days in Microsoft). Then Microsoft promised that WebForms would have hooks available through IE that would allow your C# code to execute on the browser. That went exactly nowhere. Then we had JScript.NET, an attempt to bring Javascript to the server, Microsoft style. That died, again for the usual Microsoft reasons. So the only client-side language left was Javascript. It was "C" enough that people could use it easily. It was a translated language so super easy to get up and running. It tolerated errors, it didn't care about types, it never, ever argued or got into a fight. It was becoming more and more a necessity and less a nice-to-have, and it threatened no one, really, so it was left on the client to be its own thing. Then Google got serious with the V8 Javascript engine which then went server-side and we had a situation where a horrible, stunted play language that was all that was left of the client-side wars made the leap, virus-like, to the server, and like a virus it spread. Node.js, then HTML5 native applications, TypeScript, and suddenly it wasn't about bringing excellent languages to the client-side and fighting to see which won. It was about Javascript invading the server-side of things and being the one language that didn't inspire a tribal backlash. No one really loved it, yet no one really felt it was being thrust down their throats by any of the big players. It was allowed to stay. And so by default we have the one ubiquitous language that works on the client and the server. And the meek shall inherit them both. :sigh:
cheers Chris Maunder
JavaScript is the new "dBase" / FoxPro of this decade... type less; dynamic; a perception that it is "next-generation" ... spending all your time getting fringe cases working / performing / looking good. Improvements in bandwidth will make the whole perceived "client-server" debate redundant; while one continues to try and master the "web stack" of choice. Those that "don't know any better", are already running Windows apps, connected to devices (IOT?), over the net, using the likes of TeamViewer ... successfully.
-
I'm in a situation where I need to replicate client side and server side code. I wish I could just write the code once (in C#) and reuse it client side. The Great Dream. Javascript has been on the client (browser) side forever. For a time it competed with VBScript in Microsoft's attempt to dominate. VBScript on the client failed for all the usual Microsoft reasons, leaving the client side to Javascript (we won't mention Flash). Java had a crack at the client side but Microsoft sabotaged that (those were bad days in Microsoft). Then Microsoft promised that WebForms would have hooks available through IE that would allow your C# code to execute on the browser. That went exactly nowhere. Then we had JScript.NET, an attempt to bring Javascript to the server, Microsoft style. That died, again for the usual Microsoft reasons. So the only client-side language left was Javascript. It was "C" enough that people could use it easily. It was a translated language so super easy to get up and running. It tolerated errors, it didn't care about types, it never, ever argued or got into a fight. It was becoming more and more a necessity and less a nice-to-have, and it threatened no one, really, so it was left on the client to be its own thing. Then Google got serious with the V8 Javascript engine which then went server-side and we had a situation where a horrible, stunted play language that was all that was left of the client-side wars made the leap, virus-like, to the server, and like a virus it spread. Node.js, then HTML5 native applications, TypeScript, and suddenly it wasn't about bringing excellent languages to the client-side and fighting to see which won. It was about Javascript invading the server-side of things and being the one language that didn't inspire a tribal backlash. No one really loved it, yet no one really felt it was being thrust down their throats by any of the big players. It was allowed to stay. And so by default we have the one ubiquitous language that works on the client and the server. And the meek shall inherit them both. :sigh:
cheers Chris Maunder
I agree. It might sound a bit strange, but for myself personally, I tend to find languages that would seem to be very similar as very different in terms of "fun to program". I hated Pascal, yet liked C, and then later C++, once I got the hang of it. I liked BASIC but not quite as much FORTRAN (and really began to hate FORTRAN once I learned C). I didn't care much for Java, but like C#. Oh, and the little I've seen of Javascript makes me want to puke. As for stacks, I liked the non-.NET Visual C++, except for the hokey MAP macros and the inability to recolor the background of a TextBox via a simple function :mad:, but never liked the ASP.NET (I could never figure out how to map the messages properly :mad: :confused:, so I used the same message handler, which I have even forgotten the name of, for all events. X|) I really liked the .NET WinForms stack, especially the way that the message handling was done (even though the Delegate class seemed to be a bit hokey), other than the fact that I couldn't find a gig with it. ;P
-
I'm in a situation where I need to replicate client side and server side code. I wish I could just write the code once (in C#) and reuse it client side. The Great Dream. Javascript has been on the client (browser) side forever. For a time it competed with VBScript in Microsoft's attempt to dominate. VBScript on the client failed for all the usual Microsoft reasons, leaving the client side to Javascript (we won't mention Flash). Java had a crack at the client side but Microsoft sabotaged that (those were bad days in Microsoft). Then Microsoft promised that WebForms would have hooks available through IE that would allow your C# code to execute on the browser. That went exactly nowhere. Then we had JScript.NET, an attempt to bring Javascript to the server, Microsoft style. That died, again for the usual Microsoft reasons. So the only client-side language left was Javascript. It was "C" enough that people could use it easily. It was a translated language so super easy to get up and running. It tolerated errors, it didn't care about types, it never, ever argued or got into a fight. It was becoming more and more a necessity and less a nice-to-have, and it threatened no one, really, so it was left on the client to be its own thing. Then Google got serious with the V8 Javascript engine which then went server-side and we had a situation where a horrible, stunted play language that was all that was left of the client-side wars made the leap, virus-like, to the server, and like a virus it spread. Node.js, then HTML5 native applications, TypeScript, and suddenly it wasn't about bringing excellent languages to the client-side and fighting to see which won. It was about Javascript invading the server-side of things and being the one language that didn't inspire a tribal backlash. No one really loved it, yet no one really felt it was being thrust down their throats by any of the big players. It was allowed to stay. And so by default we have the one ubiquitous language that works on the client and the server. And the meek shall inherit them both. :sigh:
cheers Chris Maunder
Chris: I find your post amusing, but flawed. JavaScript is not a horrible, stunted play language, but a new paradigm in the making. Remember delegates? Those were imported from JavaScript, not C, as most people think. Remember lambas? Again from functional programming. Asynchronous? JavaScript again, from day one, with the setTimeout() routine. JavaScript has been sort of a playground for new technologies, and JSON is the most exciting of them. Imagine embedding data, algorithms and references in one simple format. Today, with Express you can create extremely complex data extraction without the burden of Entities, JDO, Code-first and all those "wonderful" things that went awry when implemented. JavaScript and fellows have never gone south. They have kept clean and real. My two bitcoins.