Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming Stats

Which JavaScript Framework is the Most Popular? (infoworld.com) 161

Posted by EditorDavid from the popularity-contests dept.
An anonymous reader quotes InfoWorld's report on which JavaScript frameworks are the most widely-used: In a study of 28-day download cycles for front-end JavaScript frameworks, NPM, which oversees the popular JavaScript package registry, found that React has been on a steady upward trajectory; it now accounts for about 0.05 percent of the registry's 13 billion downloads per month as of the fourth quarter of 2017. Web developers as well as desktop and mobile developers are adopting the library and it has spawned an ecosystem of related packages. Preact, a lightweight alternative to React, also has seen growth and could become a force in the future.

On the down side, Backbone, which accounted for almost 0.1 percent of all downloads in 2013, now comprises only about 0.005 percent of downloads (about 750,000 per month). Backbone has declined steeply but is kept afloat by the long shelf life of projects using it, NPM reasoned. The jQuery JavaScript library also remains popular but has experienced decreasing interest. Angular, the Google-developed JavaScript framework, was the second-most-popular framework behind React, when combining the original Angular 1.x with the rewritten Angular 2.x. Version 1.x was at about 0.0125 percent of downloads last month while version 2.x was at about 0.02 percent. Still, Angular as a whole is showing just modest growth.
They also report that the four JavaScript frameworks with the fastest growth rates for 2017 were Preact, Vue, React, and Ember.

But for back end services written in JavaScript, npm reports that Express "is the overwhelmingly dominant solution... The next four biggest frameworks are so small relative to Express that it's hard to even see them."
This discussion has been archived. No new comments can be posted.

Which JavaScript Framework is the Most Popular? More

Which JavaScript Framework is the Most Popular?

Comments Filter:

  • Vanilla-JS.com (Score:5, Insightful)

    by ChunderDownunder ( 709234 ) on Monday January 15, 2018 @07:39AM (#55930837)

    http://vanilla-js.com/ [vanilla-js.com]

    • Re:Vanilla-JS.com (Score:5, Insightful)

      by holostarr ( 2709675 ) on Monday January 15, 2018 @09:03AM (#55931141)
      Yea, try building and maintaining a large scale application using nothing more than vanilla JS. The reason JS frameworks are popular is because they do a whole lot of stuff behind the scenes like variable binding, efficient rendering of the DOM (for example virtual DOM), implementation of patterns such as MVVM, state management, routing, and a whole lot more. There is no way you could build an application such as Youtube or Facebook without some sort of a framework; best case scenario you will end up rolling your own, at which point why not just use one of the many existing ones with a community support and a full time team that is focused solely on the framework development. Unless you are a very large corporation with lots of resources such as Google or Facebook where you can devote resources to building and maintaining your own framework, it doesn't make sense to roll your own. You will make something that works, but works badly and perhaps with lots of security vulnerabilities compared to one of the major frameworks.
      • Who builds and maintains "a large scale application" who isn't "a large scale corporation"?
        • Believe it or not, there are companies out there that build enterprise apps, and yet they are NOT large enough (or don't see a value) to have internal teams devoted to an in house JS framework. For example, I work for a Telecom and although we have large development teams for building various applications for our customers, our focus isn't building and maintaining frameworks.
          • Telcos are still generally quite large, and I find it implausible that an adequate substrate couldn't be maintained by just a few people who understand the needs well. Of course, skilled people - now that might be a problem since these are generally scarce.

            • Re:Vanilla-JS.com (Score:4, Insightful)

              by holostarr ( 2709675 ) on Monday January 15, 2018 @09:54AM (#55931407)
              Try making a compelling reason to the management that they need to hire a team of say 2 developers, a project manager, and a QA just to build and maintain an in house JS framework, when there is a plethora of frameworks out there! Large corporations like to focus on areas that is relevant to their business, and for most building an in house JS framework is not relevant. Facebook and Google do it because they are sufficiently large, and they are in the business of platform as a service, so they provide tools and frameworks to attract developers to their platforms. They are also on top of the food chain so they are big enough that they need to invent solutions to their unique problems, because they are constantly trying to push technology forward.

              • Try making a compelling reason to the management that they need to hire a team of say 2 developers, a project manager, and a QA just to build and maintain an in house JS framework, when there is a plethora of frameworks out there!

                To me, if a company is already small, there is no "management" team... Thus, there usually is one person who builds/maintains an in-house application using an available framework out there. :-/

            • Why would they? Most enterprise development teams are swamped with doing real, productive work. If we hired two developers more at the utility where I work we certainly wouldn't have them working on a dumb-ass task such as writing and maintaining a framework when Google and Facebook are doing the job for me for free.

      • Re: (Score:1)

        by Anonymous Coward

        So does using frameworks. The decay rate on frameworks is roughly 5 years. So if you commit to one framework before it's popular, you might get 5 years out of it. If you commit to it, at it's peak popularity, you will only get 2-3 years out of it.

        As much as I hate jQuery and all the hellspawn it's created, developers need to recognize that if they can't build it in straight javascript, they should not be building it at all. I have never gotten a single thing via NPM to work, and quite frankly the rate that

        • If you application is well written and there is a good separation of business logic from the UI, then 2 to 3 year lifespan for a framework is pretty good. There are also commercial solutions out there that provide frameworks with greater support, for example Ext JS. It all depends what you are doing, but chances are that as a business your product is constantly evolving, and you also want your product to evolve with the technology, otherwise, your product will feel outdated and stale. Also, I don't know why

          • If you application is well written and there is a good separation of business logic from the UI, then 2 to 3 year lifespan for a framework is pretty good.

            This is fucking insanity.

            • No one is forcing you to rewrite your application using the latest fad framework! If you wrote your app in say Angular 1 and you are happy with it, then don't rewrite it! You have access to the source after official support ends and can continue to modify it and use it for development it as long as your heart desires! That is one of the many benefits of open source isn't it? But if you want the latest, most cutting edge features, then you might want to rewrite your presentation layer using a newer framework

              • No one is forcing you to rewrite your application using the latest fad framework!

                Developing a product using components only supported for 2 or 3 years is totally insane.

                You have access to the source after official support ends and can continue to modify it and use it for development it as long as your heart desires!

                Official support is the point.

                But if you want the latest, most cutting edge features, then you might want to rewrite your presentation layer using a newer framework.

                What specifically do you get in return for a critical dependency only being supported for 2 or 3 years? Are there new conceptual advances in UI design requiring cutting edge support libraries to implement?

                • What specifically do you get in return for a critical dependency only being supported for 2 or 3 years? Are there new conceptual advances in UI design requiring cutting edge support libraries to implement?

                  The reason why these frameworks are constantly changing or being replaced is because the browsers and web standards are constantly evolving. Right now there is a major push from big players such as Google, Facebook and Microsoft to move things towards the cloud, and as a result they are introducing more and more features to the browser. As a result of this push, a framework that was written 3 years ago with a different set of capabilities in mind, no longer makes sense.

                  And like I said, if for your product i

            • If you application is well written and there is a good separation of business logic from the UI, then 2 to 3 year lifespan for a framework is pretty good.

              This is fucking insanity.

              I'm a user of GNU Maxima. Its development (under a different name) started around 1968. It's still supported. When I read what GP wrote, I had a hearty laugh.

              • You can laugh all you want, but it doesn't make my point invalid. People like you act like this is a holy war, and only you are capable of seeing the truth. Well NEWS FLASH! Web developers are not STUPID, most of us realize that on the web client development side things move fast, however, that is the nature of the business! Right now there is a lot of innovation going on in this space from lots of big players including Google, Facebook and Microsoft are pushing things towards the cloud. As a result of this

        • But then again, you can also make the app 100 times smaller than using these grossly bloated frameworks.

          You really should learn how modern JS applications work, my code has 0 extra "Bloat" code because it is removed during build / compile of the system.

      • Re: (Score:2)

        by Junta ( 36770 )

        In my search to explore your comments, the react page touting the vritaul DOM:
        "BTW. I myself managed to create a web page with a source of 5GB+. It wasn’t even that hard.

        Consider a DOM made of thousands of divs. Remember, we are modern web developers, our app is very SPA! "

        These are huge warning signs that the developer has an issue, regardless of whether the environment can handle it.

        All that aside, I think the virtual DOM will be regarded in the near future as a needless over complication. It's try

      • The vanilla js solution might be a shitty one, but at least it's yours.

      • Or you can write a large application in whatever language you want. If you need it to be in the browser, compile down to some horrendous, unreadable, JS mess.

    • But is it webscale?

    • -1, not enough jQuery.

  • But they all force Javascript on users (Score:4, Insightful)

    by cjonslashdot ( 904508 ) on Monday January 15, 2018 @07:42AM (#55930851)
    What if the user does not want to use Javascript, for security reasons? Javascript is the primary vector for a large percent of malware infections. Yet, with single-page web apps, one has to enable Javascript to see anything. Not so with websites such as the NY Times and other major news sites; why should it be with company XYZ site? Javascript has destroyed the Web, but with the latest frameworks we are shoving it down people's throat.
    • Perhaps fixing Javascript in the browser or providing other means to run code would be more useful than destroying all interactivity in browsers. Preferably with imposing some resource limits, though. The current state of interactive web is a travesty.

    • Re:But they all force Javascript on users (Score:5, Interesting)

      by holostarr ( 2709675 ) on Monday January 15, 2018 @09:26AM (#55931287)
      Every time there is an article about Javascript, there is an individual like you complaining about why Javascript is needed. I'm sorry that all you want to use your browser is to read news on NY Times, but the truth is that there are a lot of people out there who want to do more than just browse static pages. The browser is the most efficient app delivery system today. You no longer have to worry about whether the end user has the latest update of your app, and which OS or version they are running, your app will just work! If you are paranoid and don't trust the browser sandboxing, then maybe you should run Qubes OS or browser in a VM, otherwise, perhaps it is best to stick to printed news.

      • Re: (Score:2)

        by pjt33 ( 739471 )

        ... but the truth is that there are a lot of people out there who want to do more than just browse static pages.

        That is completely orthogonal to the question of whether or not static pages should render something with JS disabled. The very real existence of pages with no dynamic content which render as white without JS enabled is shameful. I've seen sites which have CSS that sets the body to display: none and then load the real CSS using JS. They're usable in Lynx, but not in any GUI browser with JS disable

        • Again you are just complaining why sites don't make their content available when JS is disabled. Fact is there are no laws or standards to require the content to be accessible without JS and since people who favor browsing the web with JS disabled are in the minority, frankly most companies don't give a shit. Like I said, the only reason to complain about JS is if you are paranoid about security, at which point either trust the browser, or run it in a VM.

          • Re: (Score:2)

            by pjt33 ( 739471 )

            Fact is there are no laws or standards to require the content to be accessible without JS and since people who favor browsing the web with JS disabled are in the minority, frankly most companies don't give a shit.

            They should, because of SEO, but that's getting too far off-topic.

            Like I said, the only reason to complain about JS is if you are paranoid about security, at which point either trust the browser, or run it in a VM.

            I'm not sure where you said that, but I disagree.

            Simple benefits for the end user of

      • Hi. Yes, you are right - people do want to be able to run apps. I am just saying that these frameworks are now being used where they should not be. It seems like so many sites now use them, when the site really only has static content; but because a framework is used, I have to enable Javascript, or enter click after click in my NoScript plugin just to see a web page. I would prefer that single-page web app frameworks only be used when one really needs an app . For static content, one should be able to tur

        • At the end of the day it all comes down to trust. The question is do you trust that your browser vendor's product is reasonably secure? If you are not convinced, then like I said there are other options such as running the browser in a VM or selectively enabling Javascript in sites that you trust.
          • Yes, I have wondered if OSes are going to move to containerization for apps, which would provide that level of protection for the average user who does not know how to run a browser in a VM. There is a product for Windows called Bromium that uses virtualization to sandbox web pages. I think some of the browsers do that to but I don't think they use virtualization - not sure. There is an interesting blog post about how hard it is to write secure web apps: https://blog.plan99.net/its-ti... [plan99.net]

        • Part of this is simply efficiency. With an SPA loaded, clicking on each link to a static article simply sends the relevant data rather than rebuilding the entire page server-side. That's a whole lot faster and cheaper to do.

          As for JavaScript being a powerful malware vector, is that really a thing these days?

          • Yes, having a whole page reload from each click is very inefficient. Does HTML5 provide a way to avoid reloading a whole page, but without using Javascript?

            Yes, malware is a terrible problem today: if someone wants to hack an organization, pretty much the most guaranteed path to success is to use Web based attacks, by hacking sites that staff of the organization visit. Read this article - it is very worth your time, I promise: https://blog.plan99.net/its-ti... [plan99.net]. If you are impatient, skip down to the section

            • Re: (Score:2)

              by dave420 ( 699308 )

              That link has very little to say about JavaScript - did you mean to post it?

              • Well he is referring to the whole Web ecosystem, which Javascript is a big part of, and he makes many points about web pages that try to behave like apps. Indeed, Javascript is not the only problem - HTTP is a horribly flawed system of headers and encodings rules that application programmers should not have to get involved with.

          • Part of this is simply efficiency. With an SPA loaded, clicking on each link to a static article simply sends the relevant data rather than rebuilding the entire page server-side. That's a whole lot faster and cheaper to do.

            Not necessarily.

            Once you yank out all of the unnecessary abstraction and complexity in the attempt to create a thick client all of the sudden cost of reloading page vs reloading content is irrelevant.

            Often what really matters with regards to outcomes is round trip delay. If you have a page constantly doing a bunch of piecemeal loads (A practice that seems to be quite widespread) it's going to take longer regardless of how many fewer bytes went over the wire or how many fewer CPU cycles were burned.

      • Every time there is an article about Javascript, there is an individual like you complaining about why Javascript is needed. I'm sorry that all you want to use your browser is to read news on NY Times, but the truth is that there are a lot of people out there who want to do more than just browse static pages.

        Hence the reason operating systems allow programs other than web browsers to be executed.

        The browser is the most efficient app delivery system today. You no longer have to worry about whether the end user has the latest update of your app, and which OS or version they are running, your app will just work!

        This must be why I regularly find myself switching browsers. It's always stupid shit like buttons that do nothing when clicked.

        If you are paranoid and don't trust the browser sandboxing

        Browser sandboxes have proven themselves not to be trustworthy.

        then maybe you should run Qubes OS or browser in a VM, otherwise, perhaps it is best to stick to printed news.

        Or maybe people should stop confusing a document viewer with an execution environment for general purpose software.

      • ay. You no longer have to worry about whether the end user has the latest update of your app, and which OS or version they are running, your app will just work!

        Being able to run an application when I want, and the version I want, is one of the main reasons I have a computer. I don't want to be forced to update to the latest version that moves buttons around. And I certainly don't want the lock-in and monthly charges (or constant ads) that come with a cloud hosted application. It incurs more charges for t

      • The problem is that few web developers really understand why the WWW was developed as a document platform, the differences between document-centric design and application-centric design, and how to apply these principles.

        In most cases, replacing documents with apps is work of the ignorant, and is truly a plague. Most sites I know that have converted from static pages to dynamic pages are so broken to the point of being almost unusable, especially with regards to standard browser navigation (shift-click and

    • Re: (Score:2)

      by Junta ( 36770 )

      This is a good reason for web developers to be trained:

      First and foremost, be mindful of HTML and use it correctly. Doing this fairly simple thing improves experience greatly, and renders accessibility easy.

      Next up, up you want to be fancy, CSS can do almost all the sane visual sprucing up you can imagine, and can play nicely with accessibility.

      If you have a need for Javascript, first consider what the language/runtime can do without a framework. This keeps your application a bit more straightforward to d

  • This one! ;-) (Score:4, Insightful)

    by ls671 ( 1122017 ) on Monday January 15, 2018 @07:46AM (#55930869) Homepage

    This one:
    https://en.wikipedia.org/wiki/... [wikipedia.org]

    No seriously, wasn't there an article here a few days ago saying that the most popular js framework changes every six months and that things become a major cluster-fuck? I also remember an article saying that third party js libs loaded from third party sites sometimes disappear when the developer decides to pull them off. With regards to that, I always tell my devs not to load from third party sites and to download and install locally instead. It is also less scary for people with uMatrix or noscript looking at your site!

    • yes, but this iteration is a bit different.

      In the past you had rather different concepts at play. Roll your own solution with jQuery (which is nothing more than a functional approach to the DOM), Backbone, Angular, Ember, etc. All quite different in concepts.

      React and Vue however are far more similar and are now the dominant frameworks. Seems the community is coalesced around a single concept and have two different approaches to it. Vue is better imho because it's syntax is so much cleaner.

      > I also reme

      • Re: (Score:2)

        by Junta ( 36770 )

        This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".

        Note that at every changing of the guard, a month later there are a lot of people eager to explain why *this* time is different and the change will endure, unlike all those previous flashes in the pan before it. Six months from now we will have people explaing how Vue and React were ultimately flawed concepts somehow and how *new* framework brings enduring sanity to the world.

        Nexus supports NPM so this is an irrelevant problem.

        No, npm is a a ma

        • > This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".

          yeah I mean it's a fair point. But I see the major difference coalescing around a similar idea, which did not happen before. So maybe 6 months from now there will be the New Framework on the Block (and in the JS world, I wouldn't be surprised if that's its actual name), but I suspect this new framework will just be an iteration over the concepts of virtualdom and data binding espoused by V

    • I always tell my devs not to load from third party sites and to download and install locally instead.

      But, but... that's not cloud!

  • Clearly the JAF framework is most popular. Followed by jkit and ghostj. They are all a lot easter than wjav, especially wjav 2.0.

  • Fleeting popularity . . . (Score:5, Funny)

    by PolygamousRanchKid ( 1290638 ) on Monday January 15, 2018 @07:48AM (#55930877)

    Which JavaScript Framework is the Most Popular . . . ?

    What day of the week is it . . . ?

    This is more of a question for a celebrity poll on tmz.com.

    We live in a throwaway society. We begin each day by tossing out yesterday's JavaScript Framework, and replacing it with something new that promise to taste better, and last longer!

    • Re: (Score:3)

      by jrumney ( 197329 )
      Looking at the figures (0.05%, 0.1%, 0.02%) the correct answer to the headline seems to be none. They are all decidedly unpopular.

  • Angular of course. (Score:5, Funny)

    by Anonymous Coward on Monday January 15, 2018 @07:51AM (#55930895)

    I sat the team down and said were moving to Angular 14. They said it moves to fast and we wouldd always be updating if we put in Angular 17. I said nonsense, we were putting in Angular 23 and that was final!

    • I sat the team down and said were moving to Angular 14. They said it moves to fast and we wouldd always be updating if we put in Angular 17. I said nonsense, we were putting in Angular 23 and that was final!

      Best comment ever.

      +10

  • back end servicesin JavaScript (Score:5, Interesting)

    by dehachel12 ( 4766411 ) on Monday January 15, 2018 @07:55AM (#55930913)
    But for back end services written in JavaScript. WHY ???

    • Re:back end servicesin JavaScript (Score:5, Insightful)

      by KiloByte ( 825081 ) on Monday January 15, 2018 @08:04AM (#55930943)

      But for back end services written in JavaScript. WHY ???

      For JavaScript developers, if all they have is a pillow, every problem looks like a nail.

    • Code reuse. If you're validating form input, for example, it would be nice if you can use the same code for client-side and server-side validation. The server-side version protects you against invalid date, the client-side gives more immediate feedback to the user, but both will give the same result. There are basically two solutions to this problem. The simplest is to use JavaScript on the back end, the other is to use something like GWT or similar that lets you write the back end in one language and t

      • The latter solution, however, nicely evolves later into running WebAssembly binaries or something similar on client side once WebAssembly or something like it becomes available. With moving Javascript onto your server side, you're apparently stuck with a semi-weird language.

      • to the extent that C code compiled to JavaScript and run with v8 is often close in performance to natively compiled code, and sometimes faster

        Proof that v8 runs faster with a real-world application and not in some contrived microbenchmark.

    • Javascript is actually much better for high performance back-end applications than many languages.

      The core event loop and processing model is very much the way you would write a C/C++ process based libevent or similar epoll loops. This is extremely common for high performance programming, especially with interfaces where your process gets interrupted mostly on network or storage. Its far less important for blind batch jobs, but can be very important for response batch jobs.

      so its far easier to write high pe

    • In some cases (which I cannot divulge), your partners allow any backend solution you want. But all their SDKs are written in JS, and you'd have to start from zero to rewrite it in a real language (and do the SDK updates yourself). It's far easier to allow them to dictate the backend language (if you are a small shop. A large shop can afford to re-write the SDKs.)

  • Express "is the overwhelmingly dominant solution...

    Please tell me. What was the problem?

    • Re:In search of a problem (Score:5, Insightful)

      by Lunix Nutcase ( 1092239 ) on Monday January 15, 2018 @09:42AM (#55931349)

      The problem was not enough shitty Javascript in the world. Now the same incompotent monkeys can not only write insecure front-end code, they can also write the insecure back-end code, too!

  • NIH Framework (Score:4, Funny)

    by 0100010001010011 ( 652467 ) on Monday January 15, 2018 @07:56AM (#55930921)

    I've been in multiple software industries for ~10 years. The NIH framework has been universally accepted everywhere.

    • Does everything the other frameworks don't.
    • Does everything you need.

  • Sadly, this is how we make decisions on frameworks (Score:4, Insightful)

    by MobyDisk ( 75490 ) on Monday January 15, 2018 @08:04AM (#55930947) Homepage

    This seems to be the way we make decisions on frameworks these days. Survey what is most popular and pick that, in the hopes that someone will still be using it and supporting in 3 years. This isn't a good thing. It makes me think of the Has open source changed the world? [slashdot.org] and npm spam flag [slashdot.org] discussions. Open source is fine, but we need some commercial entities standing behind these things. We have really good infrastructure and really good tools. But now we need stability. We can't have frameworks changing this fast, and minor errors causing the entire world's IT infrastructure to hiccup.

    Some suggestions if you are creating an important commercial product or web site:
    * Keep a local package cache (npm, nuget, rpm, deb, apt, yum, MSI, ...)
    * Don't lock-in to any infrastructure that you aren't paying for (CDNs, "free" cloud services, "free" email services)
    * Give back to the open-source community, don't just siphon from it (or it won't be there in the future)

    • we need some commercial entities standing behind these things

      Some of these javascript frameworks do have commercial entities standing behind them. I am not sure how much it helps.

  • Skyscrapers, Sandy Beaches and JavaScript (Score:2, Insightful)

    by Anonymous Coward

    I'm a systems developer at heart, but I've had to do some web apps in more recent times, and I've found that building an application on top of JavaScript is like building a skyscraper on a beach. You can do it, but you have to dig all the sand out of the way first and make your foundation firm. Node.js is an example of one way I've seen it work. But web apps are by nature building a sand scryscraper on top of a sandy beach, especially if you are using frameworks. You rely on the browser not to have any bugs

  • Hold my beer (Score:1)

    by Anonymous Coward

    Who the f* cares here on this mammoth graveyard that is Slashdot?

  • If I had to offer a guess, I'd say... (Score:3)

    by QuietLagoon ( 813062 ) on Monday January 15, 2018 @08:54AM (#55931115)
    ... uBlock.

  • The one with the best GC (Score:3)

    by Snotnose ( 212196 ) on Monday January 15, 2018 @09:15AM (#55931211)
    Any Javascript framework with decent garbage collection will know to bury itself 6 feet under, cuz javascript is by definition garbage.

  • What is NPM? (Score:3, Insightful)

    by pedz ( 4127433 ) on Monday January 15, 2018 @09:54AM (#55931413)
    Seriously... first, don't they need to demonstrate that NPM is what most developers are using? I don't use it. I deploy my javascript such as jQuery by pulling down a copy and embedding it in my app. It seems a more reasonable approach to understanding the current state of Javascript is to ask the spiders that crawl the web and see what packages they encounter.

  • Shouldn't that be amended to "Which JavaScript Framework is the Most Popular this month?"

  • Change like their underwear (Score:5, Insightful)

    by gabrieltss ( 64078 ) on Monday January 15, 2018 @10:44AM (#55931713)

    People change JS frameworks like they change their underwear. One week is one library, next it's a different one.
    In one year a company I was with had 50 different apps with 50 different JavaScript libraries I swear. Who THE FUCK is going to support all of that mess? Managers should be slamming keyboards on developers hands! Pick one and stay with it - quick FUCKING changing them all the time. Just because some A-Hole thinks they can re-invent the wheel or thinks they are being cute - we get a new JavaScript library. Message for all of you STOP THIS SHIT! We have enough of them already! Why don't you all get together and pick one or two and make them better instead of creating a new one. You want to write your own as a hobby - great - leave it on your system for your hobby purposes! Better yet, help out on an existing one to make it better.

    Seriously - why do people STILL think this language is so great. It's POS! Pick the latest JS library - they all come from the same root Language. One that was written in 10 days! Hell even the company that had it developed didn't even implement it properly. And now people think we should run it on the server side. WHAT THE FUCK is wrong with you? I DO NOT allow server side JS libraries on MY servers - PERIOD! You want to code on the server - use a REAL language! JS libraries come and go WEEKLY! I've been developing for over 32+ years - I DESPISE the thing. I avoid it like the plague. It only gets used when I absolutely have to.

    The only people that were in total love with JS is/was the PORN industry!

  • Some reactJS problems... (Score:4, Insightful)

    by Parker Lewis ( 999165 ) on Monday January 15, 2018 @10:55AM (#55931821)

    I joined a reactjs/flux project some months ago. I properly learned how it works quickly, and liked the idea. Several years ago I've worked with desktop UI apps (in C++, later Java/Swing and C#), so I had no trouble with the idea.

    But then I tried to create, like in the GUI desktop world, when you have a nice hierarchy of components/containers, a parent component that will have most the logic, then 2 children classes, including only the different logic. First wall: the same guides in other crap OO language/frameworks. "you're not supposed to use inheritance, you need to use composition ".

    The most irritant issue: of course, several things that worked in the past with reactJS simple were removed or are under constant changes. I can even handle that, but the problem: a LOT of the erros and warnings just don't handle a stack. They simply give you a warning/error message and you'll have to dig in the code where it was raised. Again, terrible OO.

    Even flux it a weird flow, because it relies in a dumb event system: just a big pipe raising all events. If you want to listen for an event, you need to plug into this big pipe, listen all events and use a switch/case to get the ones your component wants.

    Not to mention some repeat-code-everywhere approach, when you have thousands contants that are just the same string as the constant. This for a dynamic language... i.e., people will make a typo in the name of the constant too and nobody will notice.

    I can just saw that JS turned the new PHP: developers that don't want to proper learn how to code everywhere with "brilliant ideas".

    • Re: (Score:2)

      by caseih ( 160668 )

      Why would you use inheritance to establish a hierarchy of widgets? That doesn't make sense to me. A GUI is by definition a container that contains other widgets. It's a "has a" relationship, not a "is a" relationship. Inheritance to establish this just isn't appropriate. In desktop GUI programming, inheritance is used very rarely, and only when you want to extend a widget in a particular way. So in this regard, reactjs seems to be doing it the right way. The widgets themselves should have precious lit

      • Re:Some reactJS problems... (Score:4, Informative)

        by Parker Lewis ( 999165 ) on Monday January 15, 2018 @12:10PM (#55932301)
        If you really used GTK+, Qt, wxWidgets, WinForms in C#, etc, I'm sure you'll be familiar with GUI hierarchy, as all of those you've cited are based on inheritance hierarchy, and if you've used them seriously, you probably created re-usable components inheriting any other component. And, funny, any reactJS component is inheriting a reactJS component too. It's just so bad designed that it supports just 1 level of inheritance.

        • Re: (Score:2)

          by caseih ( 160668 )

          You and the other commenter are misreading! Sure components themselves have an inheritance hierarchy, but the use of those components certainly involves composition, not inheritance.

      • Re:Some reactJS problems... (Score:4, Insightful)

        by Lunix Nutcase ( 1092239 ) on Monday January 15, 2018 @02:03PM (#55933135)

        ...In desktop GUI programming, inheritance is used very rarely, ... I can only speak for GTK+, Qt, wxWidgets, WinForms in C#, etc.

        And you speak poorly about them. Qt, for example, uses inheritance all over the place in its widgets.

        Just one example: QPushButton [github.com] inherits from QAbstractButton which is inherited from QWidget which inherits from QObject.

        You also are wrong about WinForms:

        Let's look at the Button class: [microsoft.com]

        Inheritance Hierarchy
        System.Object
        System.MarshalByRefObject
        System.ComponentModel.Component
        System.Windows.Forms.Control
        System.Windows.Forms.ButtonBase
        System.Windows.Forms.Button

        I could go on but I won't. You couldn't have been more wrong if you tried.

        • And we can even go one more level deep with the QPushButton example. QommandLinkButton [doc.qt.io] inherits from QPushButton, which inherits from QAbstractButton, which inherits from QWidget which inherits from QObject. The fact that you said inheritance is rarely used by Qt for GUI programming is just absolutely hilarious.

        • But these systems using inheritance is a chicken-and-egg-slash-cargo-cult problem. People parroting other people's bad designs, both in languages and in libraries. So maybe the right thing to say would be "In desktop GUI programming, inheritance is used very rarely if you're not actually being forced to use it by someone else.".

          • How exactly is using inheritance in GUI programming a bad design? It’s a very natural fit and not like a cargo cult at all.

        • Re: (Score:2)

          by caseih ( 160668 )

          Posting late, but you seem to be misreading what I wrote. I was talking about the use of the widgets, not the widgets themselves. Of course there's an inheritance hierarchy of the actual widget implementations. But that's not what I was talking about! So be careful when you say I couldn't have been more wrong. Because I knew exactly what I was talking about.

          Now it could be I was misreading the original post (I don't see how it's possible for a framework to implement composition with inheritance), but I'

  • I'm thiking NFJS is for me... (Score:3)

    by AmazingRuss ( 555076 ) on Monday January 15, 2018 @11:43AM (#55932119)

    No Fucking Java Script!

  • It is expensive, but really gets the jobs done. (No, I do not work for them, I just work for a company that uses it)

Slashdot Top Deals

news: gotcha

Close