My Theory on why Javascript is winning
-
I'll see your XML, and raise you a JSON. We don't need to schema validation for the web. It's a dangerous place and we like it that way.
Jeremy Falcon
You kill me.
cheers Chris Maunder
-
You kill me.
cheers Chris Maunder
:thumbsup:
Jeremy Falcon
-
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 really liked the idea of Silverlight, but Microsoft decided that HTML 5 would be such a great silver bullet. What else is new: HTML 5 is just as much a write once, debug everywhere and rewrite as the previous versions. Obviously Silverlight was never going to be the Silver bullet, but it you would willing to limit your browsers to those it was implemented for, it would have worked. For many people that would have been good enough. I was even hoping that Silverlight applications could look like desktop applications. Another Balmer mistake.
-
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
Ah, so the same as every other theory. Basically, if you're doing client-side web dev, you have no real choice.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I agree that javascript is doing well, and I like it(I use it on the client & in Node.js), but it isn't the #1 language used in development, so I'm not sure what you mean by winning. It's also a holy mess unless you're writing a lot of small programs, which most people do. When you get bigger, you need Typescript to keep the code clean. Finally, we will be able to use other languages in the browser, it's just taking a bit longer than I like. Take a look at Webassembly to see where this is going.
In VS 2015 your can use the Bookmarks window and then rename your bookmarks as you like. It can't remember if it is in lower versions, but I am sure it is - to lazy to check right now. I use this often.
-
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 Maunder wrote:
And the meek script kiddies shall inherit them both.
:sigh: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project! Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
-
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
have you seen the bridge.net C# -> JS converter? Looks pretty neat to me Bridge.NET - Open Source C# to JavaScript Compiler[^]
-
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
Mmm... this certainly is interesting. I have been thinking for a while now that I would like to port my service bus from C# to node. I have some elementary node experience but ample JavaScript. Then I thought to myself: "What would be the point in having a C# alternative when anyone can run the node version?" I'll have to see where I end up :)
-
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
Things like Emscripten[^] and Fable[^] give some hope that writing directly in Javascript isn't the only option, but I suspect the masses are probably heading for JS...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*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
The reason javascript succeeded as much as it has is for one reason: It was non-Microsoft. All of the reason we say the Microsoft approach failed are only applicable to Microsoft. When someone else tries to bring about a closed, proprietary, and poor-performing system that only works on limited platforms, suddenly it's the host OS that needs to adapt. The real breakthrough will occur when a sizeable-enough contingent of developers realizes the folly of writing any kind of serious application code for a browser. I think it will happen when someone finally tires of having to spend 95% of the coding effort just to get the code to work normally in a browser. It takes time to mover the heard, though. But hey, there's hope. Now that Microsoft gives away its OS, there's no need to cripple ourselves in a browser anymore, right? Moooo.... Baaahhhhhh.... The herd is stirring...
-
The reason javascript succeeded as much as it has is for one reason: It was non-Microsoft. All of the reason we say the Microsoft approach failed are only applicable to Microsoft. When someone else tries to bring about a closed, proprietary, and poor-performing system that only works on limited platforms, suddenly it's the host OS that needs to adapt. The real breakthrough will occur when a sizeable-enough contingent of developers realizes the folly of writing any kind of serious application code for a browser. I think it will happen when someone finally tires of having to spend 95% of the coding effort just to get the code to work normally in a browser. It takes time to mover the heard, though. But hey, there's hope. Now that Microsoft gives away its OS, there's no need to cripple ourselves in a browser anymore, right? Moooo.... Baaahhhhhh.... The herd is stirring...
Actually, I disagree. The browser has become an OS-Neutral platform of its own. It has sucked a lot, until recently, and is SLOWLY getting better. I would prefer to write desktop apps, in general. But I see the where this is going. We are getting close to the right experience of a desktop app in a browser, and the server gets lots of real-time information. The server can be anywhere. Needing code on the client side ONLY makes sense, and javascript fits the bill. Now, we have limitations abound, and holes and bugs everywhere. But I am already looking at one page web apps using Node as a replacement for some desktop apps, and they are going to be OS Neutral. Even able to work fine and scale to mobile. Something that was really really hard for me before this.
-
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.