back to article Linux Foundation whacks open JavaScript projects umbrella

A project fostering JavaScript’s panoply of projects has been established by the Linux Foundation. The JS Foundation will cultivate JavaScript application and server-side projects. The thinking is to create a centre that drives broad adoption and development of JavaScript technologies and that fosters collaboration. It should …

  1. dajames

    Really?

    I can't help feeling that the industry would be better served by a project dedicated to replacing JavaScript with something better structured and more maintainable.

    JavaScript has its foot in the door, being the only language that is (just about) universally supported by browsers. That makes it Hobson's choice rather than a good choice for browser-based development.

    1. Anonymous Coward
      Anonymous Coward

      Re: Really?

      Not to mention that a lot of the frameworks and layers and frameworks for those layers and the layers built on those frameworks are ironically designed to make Javascript less unmanageable and easier to use.

      Now that Javascript has a central body and mainstream companies like IBM onboard the hipsters will move on and only the useful stuff will be left.

      All the craply named products with little purpose will vanish.

      Im not going to bother with my new product now:

      More refined than a McDonalds milkshake and more proceased than a German cheese...meet Civet.

      Using our own markup language you can pass your code through our "weasel rectum" pre-processor and generate Coffeescript which can then be passed into another pre-processor and converted into Javascript.

      We'd explain why our system is better than other systems but you probably wouldn't understand.

      What we can tell you is that our technology is guaranteed to be:

      1. Obscure.

      2. Not what anyone else is using.

      3. Permanently in beta.

      4. Forked every which way to Sunday.

      5. Badly documented.

      6. Laden with dozens of depencies that will take an afternoon to install.

      7. Shipped with its own web server.

      With our tech you can easily do what can easily be done with anything else such as:

      1. Javascript alerts.

      2. Parallax scrolling.

      3. Import data from JSON.

      4. Instantly bloat your project from 1 file to 20!

      If you love scribbling in crayon and think a persons programming skill is relative to the obscurity of the tech they use...get Civet from our Github repo now!*

      *Also available pre-packaged via a range of package managers nobody uses. Including:

      Bockzz.io

      Krayt.es

      WundaR.ar

      Phrrklift.it

      and c0debin.ninja

      *swings scarf round neck and twirls moustache*

      Im done.

      1. Anonymous Coward
        Anonymous Coward

        Re: Really?

        *opens tin of PBR, turns up coldplay album recorded to cassette on his walkman and looks on*

      2. Geoffrey W

        Re: Really?

        @anonymous civet

        You must have put as much effort into that post as the developers of numerous frameworks and tools do. Civet - stoataly different from all the others

      3. Buzzword

        Re: Really?

        Also, none of the package managers host the same version of Civet; and it always conflicts with your existing dependencies. Even if you don't have any.

    2. bombastic bob Silver badge
      Thumb Up

      Re: Really?

      "the industry would be better served by a project dedicated to replacing JavaScript with something better structured and more maintainable."

      well said. multiple thumbs-up (but only one counted)

    3. Anonymous Coward
      Anonymous Coward

      Re: Really?

      > I can't help feeling that the industry would be better served by a project dedicated to replacing JavaScript with something better structured and more maintainable.

      Depending on how old you are, you may have noticed that the world does not work like that.

      Nobody chose MS DOS in the 80s because it was good or offered sane features (say like CPM or Unix, which Microsoft used to sell at the time). People chose it because it was cheap and they were better at doing business than The Most Likely Opponent (CPM).

      Same with JavaScript. Before it existed, we already had a choice of quality languages that could have very well filled that niche: Smalltalk, various Lisps, ADA, Forth, Erlang, ... but they didn't fill that niche and JS did. Lots of people were exposed to it, learned it, and started to use it themselves. And why not? No language is ever going to be perfect, so just pick one you can be productive in and start coding.

      1. JLV
        Trollface

        >various Lisps,

        ((((defun really?)((to) (write))(some(kinda(web(div(span(div(pages(th)(tr)((td)(td)(td)???)))))))

        8 /- {

        No txs, DOM's enuff of a mind f**k.

        And sorry for the likely syntax mangling, but I plead dyslexia!

        1. Anonymous Coward
          Anonymous Coward

          Re: >various Lisps,

          > ((((defun really?)((to) (write))(some(kinda(web(div(span(div(pages(th)(tr)((td)(td)(td)???)))))))

          Oh, how quaint, the "lots of silly parentheses" remark. But, have you actually written software in Lisp? Especially on the less powerful computers of the 80s or on embedded systems?

          > No txs, DOM's enuff of a mind f**k.

          What is DOM? I can only think¹ of the Document Object Model, but I can't see how to compare a data structure with a programming language.

          ¹ Not entirely true. But département d'outre-mer seemed even more improbable.

  2. John Sanders
    Trollface

    How about making it use more than one CPU core....

    I'm looking at you FF/IE/Chromes of the world.

    1. Swarthy
      WTF?

      Re: How about making it use more than one CPU core....

      You mean letting badly-written JS lock up all of your cores?! I thought the forced single-threading of JS was a security/safety feature.

    2. bombastic bob Silver badge
      Devil

      Re: How about making it use more than one CPU core....

      'troll' icon observed. heh.

    3. Brewster's Angle Grinder Silver badge

      Re: How about making it use more than one CPU core....

      It's okay. Javascript is getting shared memory. It no has standard thread library or way to fork. But, nevertheless, shared memory will be in the core standard.

  3. bombastic bob Silver badge
    Megaphone

    The problem with JavaScript in web pages...

    The problem with JavaScript in web pages is that there is TOO MUCH of it.

    Anyone who understands HTML could, in my view, use frames and/or tables to accomplish what hundreds of kilobytes of downloaded script (written by others) seems to do. If the only thing that your script does is MEASURE THE DISPLAY AREA and then set a few DHTML values, it would probably run FASTER and more CONSISTENTLY than "what's being done now".

    This is another reason I use 'NoScript'. If your page requires scripting to display, I probably don't want to view the content. And if it loads "all that" from CDN's, it's probably for TRACKING or SPYING or generally IRRITATING me with ads.

    1. Anonymous Coward
      Anonymous Coward

      Re: The problem with JavaScript in web pages...

      I agree.

      JS looked promising 5-10 years ago but the much needed reform effort was derailed by the keep-it-broken contingent of web designers, and MozillaGate was probably the final nail in the coffin. This language missed its chance at greatness. Now it's a mainly a pollutant.

      NoScript isn't enough BTW - you'll need uMatrix to selectively allow 3rd-party crap, not just JS, on a site by site basis. Still not really enough.

      1. Novex

        Re: The problem with JavaScript in web pages...

        What I'd really like to have is an ability to block/allow individual javascript commands, not just the domains.

        1. AMBxx Silver badge
          Go

          Re: The problem with JavaScript in web pages...

          Us oldsters with our Frames and Tables. Don't put that on your CV/

        2. Anonymous Coward
          Anonymous Coward

          Re: The problem with JavaScript in web pages...

          > What I'd really like to have is an ability to block/allow individual javascript commands

          On the browser? Use the debugger.

    2. Anonymous Coward
      Anonymous Coward

      Re: The problem with JavaScript in web pages...

      > The problem with JavaScript in web pages is that there is TOO MUCH of it.

      So you come across poorly written websites? What on Earth does that have to do with JavaScript? Remember the poorly written Fl*sh sites of the 00s? How about the <BLINK><MARQUEE><FONT FACE="Comic Sans">90s<BLINK></MARQUEE><CENTER></FONT></CNETER>?

    3. Nick Ryan Silver badge

      Re: The problem with JavaScript in web pages...

      Completely.

      For most websites JavaScript should be there solely to enhance the website experience. It shouldn't be there to replace perfectly working HTML solutions, just to enhance them. Why? Because almost without fail every time some idiot developer replaces working HTML solutions with a JavaScript alternative usabilit and accessibility suffers and usually the only "benefit" is a few transitions and a few less server requests (the latter can be important, but given most websites really isn't for most).

      For example, what real benefit is there in having a JavaScript provided data grid that pages through a dataset compared to requesting the page from the server controlled by URL passed parameters? The JavaScript page is non-bookmarkable, usually fails basic accessibility tests and on many occasions is bug ridden with the single plus side being that the page request is sent once along with a single request for all of the data but this starts to fail on large datasets where paged results are more efficient.

      The other serious problem is where developers who could barely vomit up a usable User Interface in a Windows (i.e. rich) client application just don't comprehend that a web page is fundamentally different and must be built differently. Instead they go to great lengths to break the entire browser experience to try and replicate their own personal hell of a User Interface. Typically rammed in the top left hand corner of a much larger browser window with custom interactive components (why use the standard browser/HTML provided controls) and entirely non-scalable or liquid layout compliant of course.

      1. Anonymous Coward
        Anonymous Coward

        Re: The problem with JavaScript in web pages...

        > what real benefit is there in having a JavaScript provided data grid that pages through a dataset compared to requesting the page from the server controlled by URL passed parameters?

        Performance. Which benefits those on low bandwidth. I take it you are aware of offline applications?

        > The JavaScript page is non-bookmarkable

        Have you heard of the History Web API?

        > usually fails basic accessibility tests and on many occasions is bug ridden

        I can take a Stradivarius and play the Paganini capricci on it. The result is guaranteed to be shit. Must be that stupid Stradivarius.

        > a single request for all of the data but this starts to fail on large datasets where paged results are more efficient.

        Do you realise that paged (or otherwise filtered) results can be obtained via AJAX methods just as easily as via any other method? It depends purely on the server implementing the appropriate endpoints.

        > The other serious problem

        ...seems to be a spontaneous rant about something not related to JS at all?

        I am sorry, but I get the impression that you are criticising something that you're not very familiar with.

        1. Nick Ryan Silver badge
          Facepalm

          Re: The problem with JavaScript in web pages...

          Performance. Which benefits those on low bandwidth. I take it you are aware of offline applications?

          Web browsers already do a very good job of optimising content. It's called caching. If the caching mechanism isn't broken by the web server/site then the number of repeat downloads is quite low and this makes it very suitable for slow or low bandwidth connections.

          Applications. These are very different to the majority of websites. Offline applications are a great idea, shame about the ball ache of browser compatibility.

          Yes, I have heard of the History Web API. It can be useful, however good luck with mobile browsers and many toolkits just don't even support it. Unfortunately because the toolkits don't support it usage is low and then there are the security and privacy problems of history manipulation...

          I can take a Stradivarius and play the Paganini capricci on it. The result is guaranteed to be shit. Must be that stupid Stradivarius.

          I'm not sure what bearing this analogy has. Could be that many toolkits are poor because they are designed not to enhance basic web functionality (which is accessible and usable) with enhanced features but to instead replace and supplant the basic web functionality? Yes, some toolkits are better than this than others but a great many of them are appalling and cause many usability issues particularly when developers try to enforce desktop application paradigms onto web pages. I still come across copious examples fo dumb developers who want to prevent user's closing browser windows, navigating forwards and backwards through their history or just make reckless and stupid assumptions about screen orientation/space and DPI.

          Do you realise that paged (or otherwise filtered) results can be obtained via AJAX methods just as easily as via any other method? It depends purely on the server implementing the appropriate endpoints.

          Yes, but the point is that this does not really make any improvement in overall efficiency. It usually kills usability, accessibility and standard web navigation and when the caching mechanism isn't broken the server load and data transfer difference is trivial. When a page pulls down all of the data in one hit and this is manipulated by JavaScript there are genuine performance gains at the client end however these are offset by trashed usability and accessibility.

          ...seems to be a spontaneous rant about something not related to JS at all?

          I am sorry, but I get the impression that you are criticising something that you're not very familiar with.

          Then comes over that you are clueless and blinkered - sorry if this is wrong but it's the impression I get from this... Create an application using a toolkit that replaces the standard interface objects because you want some "consistent" (consistently awful) user interface? Try to maniuplate the browser windows and interface to delude yourself that your application is running as a rich desktop application and not within a web browser? They're different, plan and design applications differently.

          As for my experience... hmmm... let's say I've been through every iteration of web stupidity from the start so get to see the same dumb things being repeated over and over. And I'll admit that I did many of them myself before learning better. There's little practical difference between what many stupid developers did in the past with Flash through using it not to enhance a website but to replace every part of it leaving just a single page that loaded the flash object and what the same, or similarly stupid, developers are trying to do with JavaScript.

        2. Anonymous Coward
          Anonymous Coward

          Re: The problem with JavaScript in web pages...

          > Have you heard of the History Web API?

          This AC has. What a fucking trainwreck. Was always bug-prone, still isn't fully supported in the wild, and some browsers are already breaking it to fix security flaws in the spec.

    4. Hans 1
      Boffin

      Re: The problem with JavaScript in web pages...

      >Anyone who understands HTML could, in my view, use frames and/or tables to accomplish what hundreds of kilobytes of downloaded script (written by others) seems to do.

      Ever heard of CSS ? That is even more likely to replace JavaScript .... AND .... WTF, tables are for tables of DATA, NOTHING ELSE, got it ?

      Why am I so against you using tables for layout ?

      1, layout can be easily done in css

      2. table-based layouts fuck up software like JAWS, so the blind cannot get a clear read-out of your site

  4. Anonymous Coward
    Anonymous Coward

    Its odd, but in some ways Javascript reminds me of C, just can't quite work out why

    http://jazcash.com/a-javascript-journey-with-only-six-characters/

    1. Tchou
      Mushroom

      At least use the troll icon so we know you're kidding, because written as it is it very much look like you can't tell apart gourmet dishes from diarrhea.

      Most worrying comment ever seen.

  5. Anonymous Coward
    Anonymous Coward

    On JS

    Or ECMAScript, as the pedants call it.

    Why do I get the impression that a majority of readers who have bothered to comment, seem to think that it only exists in the browser? While that is a major market, and what made it popular, the thing is a generic language suitable for all sorts of scenarios.

    It is not the prettiest thing in the world, in fact it can be terribly frustrating even amongst the most experienced developers. It is not the easiest language to program on and requires a firm grasp of its architecture to do anything minimally sophisticated so not really a language for beginners. But with that said, it is good at what it does. For a non-compiled / JIT-compiled language, you get a lot of performance out of a single core.

    1. Tchou
      Facepalm

      Re: On JS

      Sure why bother to use one of the language that actually does its job like C, C++ or even Java, .Net when you can do server side scripting with Javascript?

      1. Anonymous Coward
        Anonymous Coward

        Re: On JS

        > Sure why bother

        Surely a project manager or engineer worth his salt knows how to evaluate the various factors that go into determining the choice of tools?

        I do not understand. What is your point exactly?

        1. Tchou

          Re: On JS

          My point is.. there's already enough well designed languages available, that are well known, proven and in certain cases bug-free.

          In comparison, all and every JS flavors are either new or relatively new, unstable (I think Angular / Angular 2), unproven, often buggy, and slower.

          Plus they do not add anything new, except "new ways of doing old stuff" which is far less interesting than an actual engineering breakthrough allowing to "do new stuff the usual way".

          Sure since the time of VB6 scripting improved, the syntax improved and the interpreters improved too. It produce better code. But scripting isn't native code, and for any serious job native language are the way to go.

          There's no way to make any *technical* breakthrough with interpreted languages, because you can't access the machine directly. You can still do *commercial* breakthrough by innovating in the business-service field, a bit like Doodle or Uber.

          But even then, what's the point using an interpreter after the PoK phase? Better go with a full blown solution that can actually scale on CPU cores, and manage memory correctly.

          Unless, of course :

          - Your project is very much time constrained, and you don't have time to actually engineer anything, so you use the "general case" of what how a software behave by using an interpreter.

          - You want to sell long term maintenance (usually do it all over again with the new JS flavor every 4 years)

          - You don't really care.

          - You actually believe JS flavors are released by Google and Co for the greater good (in that case you might be a bit optimistic or a little gullible).

          1. Anonymous Coward
            Anonymous Coward

            Re: On JS

            > In comparison, all and every JS flavors are either new or relatively new, unstable (I think Angular / Angular 2)

            Do you realise that Angular is what is called a "framework", that is to say, a bunch of generic (but goal-specific) code written on top of other technologies, and intended to facilitate productive development? It could just as well have been written in Lua or assembler and be just as old, new, stable, unstable, green, or capsicum-flavoured.

            I was hoping that you would have an insightful point of view that you could share for other people's edification, my own included, but either you are terrible at explaining things or your background does not qualify you for the discussion.

            > far less interesting than an actual engineering breakthrough allowing to "do new stuff the usual way".

            And what would be your contribution in that area? Or to the field of computing in general?

          2. Anonymous Coward
            Anonymous Coward

            Re: On JS

            > "Better go with a full blown solution that can actually scale on CPU cores, and manage memory correctly."

            A well written node.js application can do all of that for you. Minimal resource usage, very stable, predictable performance and can use as many CPU cores as you want.

            You clearly haven't tried it, so your opinion doesn't count for very much.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like