Coffeehouse Thread

24 posts

JavaScript antiFUD, take it from someone who transitioned from C# to JS

Back to Forum: Coffeehouse
  • fanbaby
  • brian.​shapiro

    His argument is that javscript is everywhere, though. Not really a compelling argument for me. I use js when I do web work, but I prefer to use c# for desktop/winrt apps.

    I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

  • JoshRoss

    , brian.​shapiro wrote

    I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

    The whole world!

  • kettch

    I just went through some Pluralsight materials that involve heavy use of client side scripting using jQuery, Knockout, HTML5, etc. I have to say that John Papa is a pretty good instructor. He did an excellent job of convincing me to stay as far away from JavaScript as possible. I use jQuery and a couple of other things, but I see no reason to jump on this rush to push everything into the client.

  • Bass

    It's true, JavaScript is everywhere and that is the #1 reason I gravitate to it. As far as technical purity and niceness it's not the best, but there are worse languages that are widely used. I use CoffeeScript instead of JavaScript whenever possible, and this makes it very nice and almost Ruby-like.

    Using it on the server side is the ideal situation for web apps, IMO, since you can share a lot of code between the layers. It's also quite fast for a dynamic language, because of all the focus JS performance has gotten over the years and servers benefit from that too. With MongoDB you can have JS in the data layer as well. It's great stuff really, I'd like to see more JS on the server over time.

  • fanbaby

    , brian.​shapiro wrote

    I'm not sure why you're referring to it as antiFUD, who is the FUD coming from?

    Good question! As JoshRoss says, it might really come from all over, but I cannot help but feel it's mostly Microsoft developers who lead the "HTML5 will be ready in 2022" charge. After dreaming of a C# future, they pray for Bill G to come back and show the world what E^3 (you know, embrace etc.) should look like Wink

  • evildictait​or

    Pah. I used to program in Javascript but moved to C#, primarilly because C# is more powerful and because the IDE is frikken awesome.

    I also utterly don't understand why anyone would want to program in dynamic languages and lose the static type system. I mistype stuff all the time, and I really like the fact that my compiler will tell me I made a dumb mistake rather than finding out later during testing, or worse, via customer support.

  • exoteric

    This choice is more about a platform choice than a language choice. At the "lowest" level Javascript is still unavoidable (until multiple run-times are incorporated into browsers) but the programmer does not need to concern himself with it, if it does not want to.

  • evildictait​or

    , exoteric wrote

    This choice is more about a platform choice than a language choice. At the "lowest" level Javascript is still unavoidable (until multiple run-times are incorporated into browsers) but the programmer does not need to concern himself with it, if it does not want to.

    On what planet is Javascript anywhere near to the "lowest level"?

  • exoteric

    @evildictaitor: The browser planet (also, note the quotes used in my post)

  • blowdart

    , evildictait​or wrote

    *snip*

    On what planet is Javascript anywhere near to the "lowest level"?

    One where people who hide javascript behind libraries think they're doing javascript, rather than jquery Big Smile

  • warren

    , evildictait​or wrote

    On what planet is Javascript anywhere near to the "lowest level"?

    Earth.  People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web. 

    If you haven't watched his presentation from build, you owe it yourself to do so.  Probably the best level-setting presentation about how things actually are in the 2010s I've seen. 

    http://channel9.msdn.com/Events/Build/2012/3-027

     

  • Ray7

    , evildictait​or wrote

    I also utterly don't understand why anyone would want to program in dynamic languages and lose the static type system. I mistype stuff all the time, and I really like the fact that my compiler will tell me I made a dumb mistake rather than finding out later during testing, or worse, via customer support.

    I think what may have happened is that developers and tools got much better: developers got much better at designing and testing robust dynamic code (through working with server-side languages like Groovy and Ruby) and IDEs (I'm talking about Eclipse, NetBeans and IntelliJ) got much better at working with and debugging dynamic code. Overall this means that typos are less than they used to be and are much less likely to make it into customer hands.

    The other reason is something that Warren touched on:

    , warren wrote

    *snip*

    People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web.  

    Javascript has evolved into some sort of JVM, which means languages are being developed that compile into Javascript for running on clients and servers. As well as the 'thin veneer' add-ons like Coffeescript, you've also got your full-on languages like Fantom and Kotlin, both of which are statically typed.

  • exoteric

    It still feels wrong to build cities on sand. Maybe some day something like NaCl (but not tied to x86 or ARM) will become the basis.

  • evildictait​or

    I think what may have happened is that developers and tools got much better: developers got much better at designing and testing robust dynamic code (through working with server-side languages like Groovy and Ruby) and IDEs (I'm talking about Eclipse, NetBeans and IntelliJ) got much better at working with and debugging dynamic code. Overall this means that typos are less than they used to be and are much less likely to make it into customer hands.

    As someone who visits companies to tell them how to fix their software before releasing it, I can tell you categorically that this is not true.

    Companies that produce code in dynamic languages like PHP, Ruby, Python compared with languages like C#, Java or even C++ tend to have lower quality formalized testing and lower quality overall software.

    Even worse is the fact that languages where the distinction between code and data becomes blurry (such as whoever thought you should upload files and put source code to be executed both on the filesystem should be shot - as should the person who thought SQL ever being a string that you can glue together at runtime, or the guy who thought HTML should be uncompressed, unencrypted, human readable and have badly defined parsing rules) are vastly more likely to have critical security bugs.

    I hate to say it, but when I review sites by equally crappy developers written in C#/.NET versus PHP, the ones written in dynamic languages tend to fall faster and harder with less effort on my part.

  • Ray7

    , evildictait​or wrote

    *snip*

    As someone who visits companies to tell them how to fix their software before releasing it, I can tell you categorically that this is not true.

    Companies that produce code in dynamic languages like PHP, Ruby, Python compared with languages like C#, Java or even C++ tend to have lower quality formalized testing and lower quality overall software.

    Then we clearly don't work for the same companies. The outfits I'm familiar use Groovy and Ruby based frameworks for front/back end testing and are dab hands with all kinds of mocking frameworks. They also use continuous integration and are pretty formal in much of the stuff they do. Bad practice is bad practice and has nothing to do whether the language is dynamic or not.

    For me, it's a question of discipline.

    Even worse is the fact that languages where the distinction between code and data becomes blurry (such as whoever thought you should upload files and put source code to be executed both on the filesystem should be shot - as should the person who thought SQL ever being a string that you can glue together at runtime, or the guy who thought HTML should be uncompressed, unencrypted, human readable and have badly defined parsing rules) are vastly more likely to have critical security bugs.

    Not sure what any of that has to do with the price of bottled air to be honest.

    Again, bad practice and nothing to do with the language itself. There's nothing to stop anyone doing the same sort of nonsense in statically typed languages. No one I know builds SQL strings on the fly; we've had ORM frameworks to do that kind of lifting for quite some time.

    I hate to say it, but when I review sites by equally crappy developers written in C#/.NET versus PHP, the ones written in dynamic languages tend to fall faster and harder with less effort on my part.

    Well that's where our experiences differ. Most website crashes I see are .NET related, usually database errors that haven't been caught. 

  • evildictait​or

    , warren wrote

    Earth.  People are building x86 emulators and Linux kernels written in JavaScript.  As Scott Hanselman has repeatedly pointed out in the last year or so, JavaScript is the assembly language of the web. 

    I've written x86 emulators in Haskell, but that doesn't make that a low level language by any stretch of the imagination.

  • evildictait​or

    @Ray7:

    I don't particularly want to get into a game of ideologues. I understand that it is possible to write insecure code in both. What I'm saying is that in my experience of working a security professional, companies that write dynamic code write code that is worse.

    I don't even really care why they write worse code. The simple fact is just that they do.

    Seriously - find me a pentester who will argue that websites written in PHP are generally more secure than those written in C#/.NET and I'll eat my hat. Or find me an industry leader who thinks that their next big product will be written in Python instead of Java.

    If your company does use PHP and other dynamic languages and is very proud of their record of "no bugs - everything is safe", I would strongly encourage you to get an independent security test done. You have seriously no idea how many PHP programmers with "secure" and "thoroughly tested" websites I upset in any given week by showing them their client's data sitting in my database rather than theirs.

    Let me put it this way. If SQL were precompiled, nobody would even think to glue attacker controlled strings and pass them to SQL and so SQLi wouldn't exist (when was the last time you wanted to glue LINQ expressions with a "+"?). If HTML wasn't a string, XSSes would be hard to introduce, not easy (when was the last time an XSS-type bug was found in a Silverlight pre-compiled app or a WinForms program?).

    If eval() wasn't there, code injections in PHP would take really really dumb code to produce (like how it's deliberately hard to write an eval in C# - and it's pretty obvious your Doing It Wrong when you do), not just a half-assed attempt at a filter and a prayer next to that code injection bug. And if people didn't put their code on the filesystem next to their upload directory, they probably would have fewer code execution bugs on their website.

    So anyway, I think the answer is just that it "just being a matter of discipline" is just wishful thinking. Developers don't have discipline, they have deadlines. And languages that make it easy to write critical bugs (say, by allowing you to glue strings together and call them SQL statements, or by including an eval function in your language) makes it easy to turned stressed out developers into critical bugs.

    That's probably why languages where writing bad code takes longer than writing good code tend to do better in security reviews.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.