Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming Software

JavaScript Is Eating The World (dev.to) 349

An anonymous reader shares a report: In case you haven't heard the news, JavaScript and NodeJS are single handedly eating the world of software. NodeJS is an Open Source server-side JavaScript environment based on the V8 JS rendering engine found in Google Chrome. Once only thought of as a "hipster" framework, NodeJS is fastly becoming one of the most commonly used languages in building web applications and is beginning to find its way into the Enterprise. Netflix, Microsoft, PayPal, Uber, and IBM have adopted the popular "hipster" server-side JavaScript engine for use inside high traffic, high profile production projects. Java still powers the backend of Netflix, but all the stuff that the user sees comes from Node. In addition to Node, Netflix is also using ReactJS in their stack. PayPal too is moving away from Java and onto JavaScript and NodeJS for use in their web application platform. Uber has built its massive driver / rider matching system on Node.js Distributed Web Architecture. IBM has also embraced NodeJS as well. Even Microsoft has embraced NodeJS, offering direct integrations into their Azure Platform, releasing a wealth of tutorials targeted at Node and they have even announced plans to fork the project and build their own version of Node powered by their Edge Javascript engine instead of Chrome's V8.
This discussion has been archived. No new comments can be posted.

JavaScript Is Eating The World

Comments Filter:
  • by Anonymous Coward

    JavaScript has greatly improved the internet. Unlike true hipster languages like Rust, it has stood the test of time and is widely supported. Security has greatly improved over the years. We should consider replacing much of the C code in existence with JavaScript to improve security and reliability.

    • Re: (Score:2, Insightful)

      WTF does Rust have to do with Javascript? Rust is supposed to be a memory-safe compiled language meant for system development. It's like comparing Algol to Logo.

      • Re: (Score:2, Informative)

        by shaitand ( 626655 )
        Rust is actually a decent language that can be used for serious coding for one. Also, wake up grandpa, efforts are being made to bring http closer and closer to the system, even so far as pushing the websocket model so that the current realm of java and now javascript programming is more and more the system level.

        It's a sad world, granted, but more and more it is the real world.
      • by ShanghaiBill ( 739463 ) on Thursday August 24, 2017 @12:21PM (#55076415)

        WTF does Rust have to do with Javascript?

        Everything, because people are using JavaScript in place of Rust and C++. When my wife writes an app, she does 1% in C, just enough to pop up a WebView, and then does the other 99% in embedded JavaScript. This makes it 10 times slower, and 100 times harder to debug. Now she wants me to switch the backend to Node.js. She has even started teaching our kids to write non-web code in JavaScript, since "That is what Khan Academy uses!" (which is true).

        The only good thing about the JavaScript takeover is that we no longer have to worry about Judgement Day. If the T-1000 is running JavaScript it will be too slow and buggy to harm anyone.

        • Have her watch this video? [youtube.com] Yes, it is from the same guy who did the hilarious nosql == webscale video that was popularly posted here.

    • by matushorvath ( 972424 ) on Thursday August 24, 2017 @11:38AM (#55076005)

      The only reason everyone uses JavaScript in the browser is that it is the only language supported by major browsers. If browsers supported Visual Basic instead, everyone would be using Visual Basic. There is no choice. The popularity of JavaScript under these circumstances is no measure of the quality of the language. There was no "test of time", since there was no competition.

      • by shaitand ( 626655 ) on Thursday August 24, 2017 @11:50AM (#55076101) Journal
        It was a troll, surely you must have caught that when he suggested replacing C code with JavaScript... It's bad enough that people have wedged Java code into the domain of C. A scripted language like Perl or Ruby can actually be used to achieve similar performance for some use cases by someone who has a little understanding of how those languages are actually implemented and gain some advantages in terms of development speed and easier integration with the systems side scripting and applications that tend to be developed in house. Java is just a POS that corporations bought into because it was backed by a large commercial effort and JavaScript is just nasty.
      • Exactly right. It is the most bandwidth intensive way possible to do anything. If browsers had supported something more lightweight, say a compiled language instead of a cruddy interpreter, then perhaps we'd have something, but as it is, NO, I don't want to download 6 GB of javacript to my phone to see your cat video.

      • by TheDarkMaster ( 1292526 ) on Thursday August 24, 2017 @02:28PM (#55077477)
        This. Javascript as a programming language is a piece of shit, but is installed by default on all browsers so everyone will use javascript for client-side code. Nobody uses javascript for being the best option, everyone uses javascript because they have no other choice for the job (code running in the browser)
    • We should consider replacing much of the C code in existence with JavaScript

      Spoken like a true Javascript "programmer" :D People who can't program and those talentless late 90s scabs that seem to hang onto the market like a venereal disease are jumping into this craze like a methed up wannabe chef into a box of Velveeta Shells and Cheese

      • by HiThere ( 15173 ) <`ten.knilhtrae' `ta' `nsxihselrahc'> on Thursday August 24, 2017 @01:21PM (#55076963)

        Javascript *is* the wrong way to go, but C really needs to be replaced with a language that can check for fence-post errors, and where you can tell when a value is a pointer rather than an integer. (Note I said "can'. This should be a compiler switch so that you can optimze the check away after everything is debugged.)

        Somehow every new language seems to try to be an improved C++ rather than an improved C. This is a mistake. And improved C is just as needed as an improved C++...and would be a lot easier to do. You could even have it be almost the same as C, with most programs being identical between the two, and with the same meaning. But you can't call it C, because it would severely break many standard C idioms. And D's been used for a reasonable C++ replacement. Perhaps concentrate on making it easily debuggable and call it "ecstaCy". (That should be searchable for on the web.)

        • by tuffy ( 10202 ) on Thursday August 24, 2017 @02:46PM (#55077611) Homepage Journal

          That's pretty much what Rust is: a low-level language that can be slotted into the same places C is used now, but without all the undefined behavior and memory leaks. And since it's a new language, it can have features people expect in a new language these days (like type inference, an intelligent build system, etc.).

        • by HuguesT ( 84078 )

          Why replace C/C++? Compilers do optional bounds checking it already, at least since 2012.

          Come on, man, keep up with the times! check out Adress Sanitizer [github.com] and all the other Sanitizer goodies. Enabled by default in recent versions of GCC/G++ (since 4.8) *and* Clang (with LLVM 3.1). Contributed by your friendly Google developers.

  • Ruby (Score:5, Insightful)

    by Luthair ( 847766 ) on Thursday August 24, 2017 @11:04AM (#55075723)
    Ruby was in the same position not that long ago, I wonder how many now legacy ruby apps people regret writing.
    • Re: Ruby (Score:2, Insightful)

      by Anonymous Coward

      There's a huge difference between Ruby and node. Ruby is slow as fuck and writing async code with it is very difficult. Node is ridiculously fast and writing async code is easy. Ruby lasted me about 6 years. Node is already upto 5 years and I can easily see it lasting another 5. And if it does get replaced by soemthing better later on. So be it... that's the life of a programmer

      • Re: Ruby (Score:5, Interesting)

        by s_p_oneil ( 795792 ) on Thursday August 24, 2017 @11:54AM (#55076149) Homepage

        Very true. Ruby was (and still is) an awesome language at a conceptual level. Even though Ruby's runtime engine is slower and behind more established/popular scripting language engines like Python, I still strongly prefer using Ruby over any other language for writing utility scripts. It never made much sense for web server logic though (unless it's a small internal web server intended for very light traffic). IMO Rails was the worst thing to come from Ruby, but most developers using it were too wrapped up in the hype to notice.

        JavaScript+Node seems like the opposite (e.g. a crappy language with a superior runtime engine). I like the async nature of it, though it drove me nuts when I needed to chain together multiple queries to respond to a single page request. That probably means I was "doing it wrong", but I was just getting my feet wet with it. ;-) It also bugged me how easy it was to make the Node.js engine lock up and crash. Maybe it's just the specific version I tried (which was about a year ago), or maybe it's only when Node.js is compiled for Windows, but a single Ruby script with 20-30 threads performing a speed test on a Node.js "Hello World" page brought it down in 30-60 seconds (though it did run impressively fast until it crashed ;-).

        • by HiThere ( 15173 )

          I don't know Javascript, but Ruby is deficient in error checking. When I use it sometimes all I can be sure of is "somewhere in that program I didn't properly close a parenthesis, or left out an 'end'". This can be annoying when the program is several pages long. Recently I ran into a problem with some code I had written in Ruby a month ago, and the easiest way to solve it was to translate the code into Python...which didn't, in the end, turn out to be any longer than the original Ruby. (Well, the actua

          • When I first tried both Ruby and Python, to me they seemed damn close to 100% equivalent in terms of features and ease-of-use, but to me the minor differences feel more elegant in Ruby and more irksome in Python. Maybe I'm just a bit more more old-school, maybe I just like the {} more than indentation for code blocks, or maybe it's just that I tried Ruby first.

            Anyway, most of the languages I've worked with in the past 25 years have used C-style curly braces for code blocks, and once you get used to the {},

      • Re: Ruby (Score:5, Interesting)

        by shaitand ( 626655 ) on Thursday August 24, 2017 @12:00PM (#55076229) Journal
        It's too bad Perl 5 has fallen on the popularity scale. Node was better for async code about five years ago but now Perl has some amazing modern async systems and if written properly is lightning fast. Every time one of these new upstart languages has a feature or advantage Perl just absorbs it. Sadly, most of the Perl code you actually see is written because it is the lowest common denominator which means not using any new functionality and sometimes not even having access to CPAN. Non-blocking async code with websockets scaling to tens or even hundreds of thousands of connections, no problem for actual modern perl. Perl has been around for so long though that someone trying to pick up Perl is going to find a lot of old cruft out there showing old ways. Hell there is even a book called "Modern Perl" that is hopelessly ridiculously outdated.

        JavaScript isn't even a real language. Sounds like you've written in other languages... be honest, if written without a style convention Perl can look ugly but JavaScript actually IS ugly. You might get the job done in JS but you feel a little dirty afterwards.
        • if mod_perl didn't suck then perl would be a lot more popular, and php a lot less so.

        • by narcc ( 412956 )

          JavaScript isn't even a real language.

          What an odd thing to say. I'm guessing you're not very familiar with the language.

          See, everyone hates JavaScript when they first use it. I suspect it's because they're trying to use the language like they'd use Java or C#. That's not a good idea. Once you learn the language, you'll find it's has very simple design that allows for a lot of depth. The biggest "warts" in the language come from where it's been unnaturally extended to make it look more like Java (the new keyword, for example).

          It's unusual in

          • Come here and see the Stockholm syndrome...

            What you are experiencing is 'my pigfuck', it's just human nature. Once you know a mess, it becomes your mess, you've invested the time.

            • by narcc ( 412956 )

              "Stockholm syndrome"? Ridiculous.

              I've used Java for more than 20 years. I loved it at first, I even advocated it. I can't stand it today, and hate it more the longer I use it.

              Javascript, I've used for a little over 10 years or so. I hated it at first, but now I think it's a pretty nice language. The exact opposite of my experience with Java.

              C, which I've used longer than either language, I'm still pretty neutral about. I feel about the same way about it now that I did when I first started using it.

              If

          • by Jaime2 ( 824950 )

            JavaScript is only a good language if you know which 60% of it is horrible and never use that part. It also helps to know that it's not a variant of Java; it's a variant of Forth made to resemble Java. That help to reduce the temptation to try to use it like Java.

            If you're wondering what the horrible parts are, my personal top five are; variable scope, type coersion, undefined, this, and global.

            Back to what you said - so much of it is horrible that it really is worth hating. Sure, it can be used effectively

      • Re: Ruby (Score:4, Interesting)

        by Anonymous Coward on Thursday August 24, 2017 @12:02PM (#55076251)

        It's comical to see JavaScript fanatics go on about how great JavaScript is because it supports limited support for asynchronous programming.

        They really don't have any idea how limited JavaScript is in this respect compared to pretty much every other modern and quasi-modern programming language out there.

        Ask them what "multithreading" is and they'll give you a blank stare!

        C, C++, Java, C#, Python, Perl and even Ruby programmers can't believe how naive and ignorant JavaScript programmers are about this matter. It's like these JavaScript fanatics really don't understand how limited their preferred language is.

        • These people usually do not understand because they have never known anything different in life. I seriously doubt they have ever had to ensure that the application works even in adverse situations (check your inputs! expects failures!) and where it can cost lives if it fails in an unexpected way.
    • Re:Ruby (Score:5, Informative)

      by Tablizer ( 95088 ) on Thursday August 24, 2017 @11:27AM (#55075925) Journal

      Ruby was in the same position not that long ago, I wonder how many now legacy ruby apps people regret writing.

      Fad sniffers, that's why. I'm going into my get-off-my-lawn mode here, if you don't mind.

      Tech companies and consultants profit off of change, and so encourage it, whether it's the right decision or not for a particular project. When technology stagnates (becomes stable), people figure everything out, and fixing and changing becomes routine and commoditized such that orgs no longer buy expensive new stuff and don't rent consultants for $100 an hour.

      The vast majority of companies don't need "web scale", but many end up copying big-co stacks anyhow in fear of being left behind. They end up acquiring NFL-level equipment for little-league.

      Sometimes these fads do actually either pay off or trigger similar good ideas elsewhere such that they do have a use in aggregate, but it's usually not good for a typical company to be the guinea-pig. Let some somebody else be the guinea-pig and benefit from THEIR lessons. You won't be hip, but you also won't be burned.

    • Re: (Score:2, Interesting)

      by jellomizer ( 103300 )

      JavaScript is the main programming language for the browser.

      Normally making a Web Application you often need to program in many languages.
      SQL for the Data Layer
      PHP/Java/C# for the Business/Logic layer
      JavaScript for the Interface Layer
      HTML for the interface

      NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer n

      • By the same argument, butt sex is better because everybody can participate...

        Javascript is a shitty language that only exists because it is (was anyhow) the only somewhat safe game in the browser.

        The only parts of your list not needed by Javascript purist is the business logic code. Using Javascript to access data still requires SQL (for reasonable efficiency) and the DOM is still a reflection of HTML.

        Languages are easy, libraries are hard.

      • NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer needs this to keep people from keying in stupid stuff) then use the same code on the Logic Side, to double validate the data in case someone disables javascript on their browser.

        If you use a different language on the server side, then you are probably more likely to catch errors in your logic - you're forced to think twice about the problem, and come at it from a slightly different perspective each time.

        Regardless... if you're using the exact same code on both the client and the server, you are not "double validating" anything - you're just running a single check, either one or two times.

        • you are not "double validating" anything - you're just running a single check, either one or two times.

          Was it really that hard to read 10 more words?

          You validate once on the browser do that you don't need to do a return trip to the server and can present the user with a validation error message at a conveniant time.

          You validate again on the server because you assume the user is malicious.

          You aren't trying to do anything more than use a single validation algorithm, you just do it twice (you know what the wor

      • GWT was supposed to solve the same problem (by replacing JS with Java at the Interface Layer.) Was it too limited or was it just people don't like Java very much?

        Still amazed, unfortunately, at the popularity of PHP. I hope the article's right, at least in that some of the PHP is slowly being replaced with JS.

        • by narcc ( 412956 )

          PHP is and was popular, because it was better than the alternatives. Imagine a world where JSP or ColdFusion came out on top...

          Whatever warts the language might have, it's trivial to write, debug, and deploy. Those three things are more important than ideological purity or whatever it is that informs your opinion on the language when it comes to adoption and longevity.

          To replace PHP, you need a language that is at least as trivial to write, debug, and deploy.

          NodeJS, while it's the hot new trend, isn't lik

          • NodeJS, while it's the hot new trend, isn't likely to replace PHP as it's more difficult to write, debug, and deploy

            I gotta tell you, I find that hard to believe. What about JS is harder to write, debug, and deploy? JS is easier to write, it still has the same free form nature but has far fewer gotchas, and virtually all PHP programmers are already familiar with it. It's easier to debug, again, with fewer gotchas; and deployment seems to be more or less identical, just copy the file where you need it.

            JS

        • GWT had a lot to be desired. WAY too slow. (IMO). While it did remove some of the burden from writing code to run on the client, to me, it seems like it was just a server side applet framework. I think Wicket does a better job than GWT. Once you get used to it's behavior, it does seems to run faster than any GWT code I have had to write to perform the same functionality.

          What I would be curious about, "Does Node.js have a security model?" Since it is Javascript, I am only guessing, but JS never really p

      • NodeJS is JavaScript, so you can cut down on the number of languages you are using for a Multi-Tier Application. This can allowed shared libraries across both sides Say your complex data validation check that you put on the Browser Side (as the UI layer needs this to keep people from keying in stupid stuff) then use the same code on the Logic Side, to double validate the data in case someone disables javascript on their browser.

        This might have made sense 5 years ago but this doesn't seem very useful today. You could use the same argument for java and android phones. As most places now have to develop for web(js) and android(java) and ios(obj c), I don't see what the advantage is for having the same language on the server as the web. I'm assuming that most companies developing for web,android, and ios use a single language on their server to serve endpoints to the 3 current main platforms.

        • Re:Ruby (Score:4, Informative)

          by DuckDodgers ( 541817 ) <keeper_of_the_wo ... m ['yah' in gap]> on Thursday August 24, 2017 @12:35PM (#55076563)
          I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

          Granted, you can get that with Perl, Python, and Ruby too and if you restrict yourself to certain Java and C# features you can also have it there. But in practice I think a lot of server side programmers first saw the instant feedback loop of Node.js first, and fell in love with it.
          • How's that debugging working for you?

            Javascript is hardly the first interpreted language. When will Javascript catch up with pre .net VB?

          • by Luthair ( 847766 )

            I suspect the real killer feature of Node.js for people coming from Java and C# is the development cycle. Edit, save, hit F5 in the browser. Despite everything ugly about Javascript, that's handy.

            Java has had hot code swapping for as long as I can remember. Since C# was meant to compete with Java I would assume they did too. C/C++ didn't

    • by Anonymous Coward on Thursday August 24, 2017 @11:36AM (#55075993)

      This is a good point. Ruby, and especially Ruby on Rails, did fall out of favor quite quickly. I think that many people and organizations regret falling for the hype. Ruby and Ruby on Rails both gained a pretty bad reputation for being slow and bloated, and software written using them was often found to be difficult to maintain. Dynamically typed scripting languages might work well for quickly throwing together a prototype, but they often aren't so good for writing large software systems that must be maintained for many years or even decades.

      It is also important to note that some prominent members of the Ruby and/or Ruby on Rails communities jumped ship to Rust when it started to become obvious that the Ruby and Ruby on Rails hype was wearing very thin, and the Rust hype was just starting to build.

      For example, look at the Rust Core Team [rust-lang.org]. We see Yehuda Katz listed, who is apparently a former member of the Ruby on Rails Core Team [rubyonrails.org]. We also see Steve Klabnik listed. He apparently wrote a book about Ruby on Rails with Katz [manning.com]. Alex Crichton [rubygems.org] appears to maintain some Ruby gems.

      So over 30% of Rust's Core Team was involved with Ruby at some point. It might even be more than that. This has made me very suspicious and weary of Rust. I personally have had bad experiences with Ruby and Ruby on Rails, and I fear that I might be subjected to the same hype-driven nonsense if I get anywhere near Rust, due to the same people being involved with both.

      • I've never had any problem with the Ruby language itself. If you look at what high-level scripting languages like Perl/Python/Ruby are good for (small-to-medium utility scripts, not large systems), I prefer Ruby over the others. The whole concept of the Rails framework was always more hype than substance. IMO Ruby's biggest problem was that most developers never considered it until the Rails hype (probably because there was a much bigger need for web development than for utility scripts).

  • And then......... (Score:5, Interesting)

    by phantomfive ( 622387 ) on Thursday August 24, 2017 @11:05AM (#55075735) Journal
    When Webassembly gets access to the dom, the Javascript craze will begin its decline.
    There are some aspects of Node that are really nice though, mainly the ease of use of the CLI. If that were combined with a better security system and less feature churn, it would be great.
    • Please no. In my opinion the best part of the WWW is that I can look at the source (even if it has been obfuscated) in plain text in my browser. Moving to binary formats is a terrible idea.

  • by __aaclcg7560 ( 824291 ) on Thursday August 24, 2017 @11:05AM (#55075737)
    The Node Package Manager (NPM) is probably why Node.js is being used with every new JavaScript framework out there.
  • by davecb ( 6526 ) <davec-b@rogers.com> on Thursday August 24, 2017 @11:15AM (#55075817) Homepage Journal

    It's easier and cheaper to staff with relatively junior .js people than pay for so-called "back end" or "full stack" programmers who know C++/Java/whatever.

    In a previous life it was very important that management could hire .js people, as the new budget required they get rid of anyone expensive. Like the chief architect (;-))

    • In a previous life it was very important that management could hire .js people, as the new budget required they get rid of anyone expensive. Like the chief architect (;-))

      Our management tells us that "Agile Development" means that anyone can develop anything. Why would we need expensive chief architects anymore?

      • by davecb ( 6526 )
        In part to say "No Dave, don't add to the main codebase, let's try a microservice instead for that component" (:-))
    • Javascript has been driving most of the functional programming and high level architectures in those languages. It's possible to create crappy/toy code in any language.
  • by L'Ange Oliver ( 1521251 ) on Thursday August 24, 2017 @11:23AM (#55075889) Homepage
    Its a great framework. Development is fast. Deployments are even faster. Testing is easy... Sure, Javascript is far from the fastest language, but in our context we delivered many more tools and services than we would have in Java, Php or .NET. Its not perfect of course, but for us the benefits far outweighs the disadvantages. Long live NodeJS.
  • ...there's probably still more electric toothbrushes than webservers. And those don't run Javscript but tiny Assembler programs.

    If you use a programming language simply because it's popular, there is a big chance you are using one that's unsuitable to solve your problem.

    • Electric toothbrushes have processors? Next thing, you will tell me they run NetBSD!
      • No netbsd, but there's a bunch of electric toothbrushes with lcd displays for battery voltage these days, and it's probably cheaper to use a microcontroller than not in that case.

        • The Braun ones with no display that just pulse the brush after 2 minutes use a 4 bit uC.

          • The Braun ones with no display that just pulse the brush after 2 minutes use a 4 bit uC.

            That makes sense. If you compare the cost of a timer module and the discrete circuitry needed to implement that, charge cutoff, and also shutoff-during-charging, it's got to be cheaper to slap the microcontroller on there just because of the number of components it replaces.

  • by Kjella ( 173770 ) on Thursday August 24, 2017 @11:28AM (#55075939) Homepage

    I worked with Javascript in the 90s... if you had come in a time machine and showed me this article from 2017, I'd say if you were bat shit crazy. If you gave me next week's lottery numbers and I won the jackpot I'd say "Well I believe you're from the future... but you're still pulling my leg about this Javascript thing, right?"

    • by SendBot ( 29932 )

      Ha! This is exactly how I feel about it too. Every time I start advocating how nicely it solves all my problems, I preface it by saying how surprised I am that this is the language doing it.

  • Ah, JavaScript. The Visual Basic of our time.
    Using a language that everyone can program in just means you will have to deal with a lot of code written by people who don't completely understand how a 'while' cycle works.

    • by narcc ( 412956 )

      Because being easy to use is a bad thing?

      If harder is better, why don't we all switch to whitespace or brainfuck? All systems development will be in raw machine code and we'll use base 3 for added complexity.

      We'll also start calling loops 'cycles' in honor of your great insight...

  • Homophobia! (Score:3, Funny)

    by mi ( 197448 ) <slashdot-2016q1@virtual-estates.net> on Thursday August 24, 2017 @11:40AM (#55076023) Homepage Journal

    Incase you haven't heard the news, JavaScript and NodeJS are single handedly eating the world of software.

    Creator of JavaScript is a homophobe [slate.com], who opposed gay marriage. It is immoral to use it.

    Similarly, because the US Constituion and the Pythagoras' Theorem were thought up by slave-owners, it is immoral (and should be illegal!) to use them too!

  • > based on the V8 JS rendering engine found in Google Chrome What's a "JS rendering engine". You don't "render" JavaScript.
    • You don't "render" JavaScript.

      So what is it called when the CIA illegally drag JS, kicking and screaming, into another country, in the middle of the night?

    • Maybe you want to render it so you can print out the source? Does a2ps do syntax highlighting for JavaScript, it'd be especially handy if it could do a little extra for jQuery-like APIs.

  • by ErichTheRed ( 39327 ) on Thursday August 24, 2017 @11:59AM (#55076225)

    Doing systems integration work, my recent experience with web applications has mostly supported this point. javaScript, wrapped in FrameworkOfTheMonth, is slowly replacing client-side applications for better or worse. If we're not allowed to have rich client applications anymore, JavaScript is pretty much the only tool to make a browser act like a rich client -- but it's a good example of shoehorning a technology in just to save complexity. I'm not saying we should go back to Java applets or Flash or ActiveX, but JS is really being extended way beyond what it was ever meant to do.

    I think its rise comes from a few factors -- massive amounts of cheap CPU and memory being available on clients, and a billion web frameworks to make using it easy for beginners. This latest dotcom bubble has spawned a bunch of "coder bootcamps" that teach basic front-end web development in a JS framework. It really is easy to throw something together that functions. However, you can definitely tell when either the framework and/or the programmer isn't doing something efficiently...just look at client side UIs that totally freeze up when a database call is taking longer than it should, or websites that slow quad-core systems with 16 GB of RAM to a crawl while they load 11,304,283 snippets of code from different hosted libraries.

  • IMO it's not the language itself, it's the life time and complexity of applications: there is a a little value in developing a well designed and thought through application when its life time will be weeks and its doesn't do anything but parse a trivial request and fetch something simple from the storage.

    Stitching together something that "just works" using the (almost) same set of tools as the UI is much easier.

    The trend towards simplified stateless cloud-based backends is to blame.

  • by Krakadoom ( 1407635 ) on Thursday August 24, 2017 @12:26PM (#55076475)

    Fastly? Since when is Trump writing summaries for Slashdot?

  • by OrangeTide ( 124937 ) on Thursday August 24, 2017 @12:30PM (#55076525) Homepage Journal

    I'm primarily an embedded/kernel developer, and I've been using C for decades. Normally I'm pretty strongly in favor of using C. But I readily admit that you can throw together a project in NodeJS very quickly. There isn't much revolutionary about NodeJS, other than it is packaged nicely and is easy to use. When the primary purpose of writing software is to solve problems, getting something going in short order has value.

    I grew up on BASIC, but JavaScript is so ubiquitous and is not terribly hard to learn that I would recommend it as a first language over anything else. (Ideally you should learn multiple languages as you advance, as they each have their own advantages and quirks)

    PS - I have a fondness for FORTH that may never go away, even if I will likely never again get to use it in a professional project. R.I.P. OpenFirmware

  • All we are missing from the public service announcement is a glittery star and a rainbow.
  • by Billly Gates ( 198444 ) on Thursday August 24, 2017 @01:16PM (#55076921) Journal

    I maybe in the minority with the young hipsters, but this summarizes my thoughts on Node.js [youtube.com] from the same guy who did nosql webscales video where he pointed out non SQL databases don't have data protection or integrity.

    Basically the video states node.js has the complexities of assembler with the syntax of javascript. You have to write your own freaking threads with callback after callback loop. Why?? It makes no sense in 2017 where NGINX has async threading models built in. Javascript is bad language too and while node.js looks cool for simple things if you already know Javascript it gets sucky very very quickly when you need something complex.

    So why build your own multitasking when you can use built in threads?

    • How do you use NGINX? (Serious question, I'm trying to understand the uses people have for it).
      • nginx was a great low-footprint option for when apache was total overkill.

        It was originally designed to act purely as a proxy server, and it does that function *fantastically* well with very low resources. This is because it used a strict event-based model that only spawned processes as requests came in.

        Since it's inception, it's grown more powerful and you can also use it for serving sites and applications as well, so it can do a majority of what Apache is. You'd have to google for an actual comparison a

    • just use typescript
  • by mveloso ( 325617 ) on Thursday August 24, 2017 @06:57PM (#55079467)

    I've been using node for about a year. What's it good at? Glue. It's awesome at being glue. It's mind-numbingly easy to put something together that can handle 40k messages a minute on one thread.

    The libraries are well-designed, are documented, have good error handling, and make sense. Most of the packages seem to be written by experienced developers who don't have retarded APIs or naming conventions. They're very task-oriented and don't have a lot of extra crap in them.

    As an example, you can build an SNMP poller in about a day or two that could replace HPOV/NetView. That's pretty good. And you could do it using one xeon core.

What is worth doing is worth the trouble of asking somebody to do.

Working...