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
-
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 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.
-
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 blame John Ressig. Before JQuery, javascript was... not exactly rare, but not exactly ubiquitous, either. After all, pre-JQ, if you wanted to use JS, you had to know all the foibles of individual browser differences, and there were lots of differences back in those days. That damn dollar sign changed all that. JS exploded on the client side, which made the Goog take notice and create V8.
-
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
As Scar* would say: "Awww, we scripties aint all that bad..." *Scar (The Lion King) - Wikipedia, the free encyclopedia[^]
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
-
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
Cue Rush's overture.
-
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.
Dewey wrote:
When you get bigger, you need Typescript to keep the code clean.
Or use Babel and some fashion of module loading if you don't want to go the TypeScript route.
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
Well that's just it. It *is* the language of the web. JavaScript has always dominated that. That hasn't changed, it just snuck its way into the server world, and now we have a whole new world opened up, such as prepossessing and transpiling, running scripts instead of shell or batch scripts, etc. I don't think it'll ever replace a hardcore server language until it fully compiles, but it's nice to have one that can do so much now, less crap to remember in our older age. Oddly enough, Java wanted to be one language to rule them all. And now look, JavaScript, the kid sister is at it too. But all of this will change when WASM is the new kid on the block. Just think about it, you open up your favorite IDE. Have a C++ project going, and when you compile, instead of choosing Win32 or Win64 as a compile target, you choose WASM. It's like MSIL, but for the web. Things are gonna change man. The future is bright for the web. This whole Node.js is just a stepping stone into blurring the lines between desktops and web apps.
Jeremy Falcon
-
Well that's just it. It *is* the language of the web. JavaScript has always dominated that. That hasn't changed, it just snuck its way into the server world, and now we have a whole new world opened up, such as prepossessing and transpiling, running scripts instead of shell or batch scripts, etc. I don't think it'll ever replace a hardcore server language until it fully compiles, but it's nice to have one that can do so much now, less crap to remember in our older age. Oddly enough, Java wanted to be one language to rule them all. And now look, JavaScript, the kid sister is at it too. But all of this will change when WASM is the new kid on the block. Just think about it, you open up your favorite IDE. Have a C++ project going, and when you compile, instead of choosing Win32 or Win64 as a compile target, you choose WASM. It's like MSIL, but for the web. Things are gonna change man. The future is bright for the web. This whole Node.js is just a stepping stone into blurring the lines between desktops and web apps.
Jeremy Falcon
Sprinkle a little XML in there too and we'll be set.
cheers Chris Maunder
-
Sprinkle a little XML in there too and we'll be set.
cheers Chris Maunder
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
-
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.