back to article JavaScript survey: Devs love a bit of React, but Angular and Cordova declining. And you're not alone... a chunk of pros also feel JS is 'overly complex'

According to a sizeable group of coders who responded to a new State of JavaScript survey, the React framework is not only the most used front-end framework, it also has the highest satisfaction rating. Survey authors Sacha Greif and Raphaël Benitte persuaded 21,717 developers to contribute to the study, reached via social …

  1. IneptAdept

    Not sure where to go

    As a long time web-dev working with .NET and then leaving for a few years to concentrate on mobile and desktop dev

    I am not sure where to come back to re frontend frameworks. React looks nice etc but VUE is also fairly appealing

    This is one of the main reasons I left web in the first place, to many frameworks lol

    1. Buzzword

      Re: Not sure where to go

      You haven’t coded much web in a few years and you’ve heard the landscape changed a bit? Step this way and read up all you need to know:

      That piece was written in 2016 and, to be fair, things have consolidated since then. The proliferation of web frameworks has settled down to a handful of winners (those mentioned in the article), though Javascript itself continues to add new features at a staggering pace.

      1. W.S.Gosset Silver badge

        Re: Not sure where to go

        > Step this way and read up all you need to know:

        I filed this when it first came out -- it is excellent.

        And also one of the socratic protagonists most wonderfully echoed my own feelings, and this is the quote I kept:

        You know what. I think we are done here. Actually, I think I’m done. I’m done with the web, I’m done with JavaScript altogether. [...]

        I’m just going to move back to the backend. I just can’t handle these many changes and versions and editions and compilers and transpilers. The JavaScript community is insane if it thinks anyone can keep up with this.

        "If it's Thursday, it must be another framework/library/time to re-learn nothing but a ream of new words for the same damn thing. Again."

      2. K

        Re: Not sure where to go

        I had a similar journey story a few years.. Backend developer, stepped out to assist with some servers, when I got home, some bar-steward decided my language of choice needed a dozen new frameworks - So I closed the door and went back to my server racks - I've never looked back.

        Here's the thing, I always enjoyed development cause it allowed me to build stuff, it was my "art". But now, its a production line!

    2. Tim 11

      Re: Not sure where to go

      For anyone (like me) who has been out of the loop and feels overwhelmed by it all, I think this video is a useful way to spend an hour of your time - less if you skip over the bits you're already familiar with.

    3. sum_of_squares

      Re: Not sure where to go

      First you have to understand the paradigm shift from the "old school" (server-side) frameworks like RoR, Django, Laravel or ASP.NET MVC and the "newer" (client-side) frameworks. Maybe read up on Fat Clients vs. Thin Clients. That said, the hype train already moved on (the MEAN stack appeared in 2013!) towards other usele.. ehem, other technologies, but you can safely ignore that stuff.

      My personal recommendation is to learn one server-side framework first - doesn't matter which one, just take 6 month and kick off a project. Afterwards you might want to look into Vue. If you understood Vue and are still curious you can take the deep dive into React. But be aware that (unlike Vue) React is not only a complete ecosystem with many different components but introduced whole new methodologies. Stuff like Flux or JSX breaks with a lot of classical web dev paradigms (i.e. keeping code and formating separated).

    4. bombastic bob Silver badge

      Re: Not sure where to go

      "As a long time web-dev working with .NET"

      For that, you have my pity.

      Question: why does anybody NEED "a framework"?

      Javascript (in a web page) really has only ONE purpose: to perform minor UI tasks that would respond poorly if done by the server. On the server side, *USE* *A* *REAL* *LANGUAGE* !!!

      If you code your web pages PROPERLY with CSS [not those 10Gb monolithic do-it-all style sheets, but one carefully tailored to your UI] you need very LITTLE, if ANY, javascript in them. I try to avoid it whenever possible, even in an embedded system using chrome in kiosk mode...

      If you must script, there are BETTER ways to do it. PHP. Shell. Perl. Python. No "frameworks" needed aside from the built-in features and installible modules (unless you're a glutton for punishment by 3rd party bloatware).

      Anyway, I'm sure that the JS fans will hate me for saying this, heh.

      1. Anonymous Coward
        Anonymous Coward

        Re: Not sure where to go

        There are basically two kinds of people who claim "frameworks are bloat":

        The first type will tell you their own measures against CSRF are much more refined and secure that those of Rails (and is probably right).

        The second type will create a website that can be get pwnd easily with directory traversal attacks and SQL injections.

        In my opinion the second type vastly outnumbers the first type, so unless you know what you are doing, use a framework. You got your CISSP, right?


  2. Anonymous Coward
    Anonymous Coward


    The news is not so good for Angular, once the rising star of JavaScript frameworks, but now in decline

    The rise and fall of "flavour of the month" Javascript frameworks...

    Will they all be superceded by Web Assembly?

    1. IneptAdept

      Re: Frameworks


      But again as a .NET dev I really liked the look of Blazor

      But that is not a full fat web ui framework really so still in the same boat

    2. J27

      Re: Frameworks

      Currently, I'm more into wondering when someone will write an engine to compile Javascript to Web Assembly. Oh, I know you're going to say something "Doesn't that defeat the purpose?" or "How stupid are you?" But I'm willing to stand by the prediction, because the current momentum in this space is to compile, transpile, minify and otherwise preprocess JavaScript six ways from Sunday and I don't see that changing any time soon.

      1. MonkeyJuice

        Re: Frameworks

        Certainly you could actually do a much better job of compiling JS to V8 if you want to spend some time in an optimizing compiler.

        Unfortunately because Spectre popped up, we no longer have access to SharedArrayBuffer. This means you cannot do concurrent garbage collection, so your overall performance would tank hard.

        It's annoying but I'd rather not leave my keys in the dash.

      2. W.S.Gosset Silver badge

        Re: Frameworks

        > because the current momentum in this space is to compile, transpile, minify and otherwise preprocess JavaScript six ways from Sunday and I don't see that changing any time soon.

        Uh, oh, it's been infected by its near-namesake's old slogan:

        "Write Once, Run Anywhere"

    3. bombastic bob Silver badge

      Re: Frameworks

      "Will they all be superceded by Web Assembly?"

      Angels, demons, gods, and monsters, I sure *HOPE* *NOT* !!!

      I'd rather just see the frameworks *DIE* and people go back to doing things simple and clean, low bandwidth, low CPU utilization, rely on CSS features, yotta yotta, but good luck with THAT happening any time soon, as "web coders" still need to JUSTIFY THEIR OWN EXISTENCE.

      I'd pay more money to someone who could "NOT use" JavaScript... or frameworks, for that matter.

      1. Anonymous Coward
        Anonymous Coward

        Re: Frameworks

        Bob, reality called, it misses you and wants to know when you're coming home.

      2. djnapkin

        Re: Frameworks

        Web pages with all the framework overhead run like dogs. No one ever wants to optimise or cull. We devs only to add more stuff into the page. Performance dies as a result.

        Clean CSS, just enough JS to do the job (and no more) - otherwise your pages suck. And you aren't a real programmer if you can't do it that way.

    4. Pen-y-gors

      Re: Frameworks

      The rise is fine, it's the fall that worries me.

      I develop a lot of sites for academic projects - typically funded for a few years, and typically delivers a nice website and database at the end, along with various books and conference proceedings.

      I'm currently going through some older sites (10yrs+ in some cases) and updating them from PHP5.x to PHP7.x, losing PEAR, tightening security and various other little tweaks. Hopefully they should then run for another 10 years without major work. After that, who knows.

      My worry with flavour-of-the-month framework in JS, PHP or whatever is that it may suddenly become unsupported and even stop working in 2,3,5 years. Not a major problem for large corporate-owned sites that have the resources to redevelop, but tricky for academics with no funding!

      So I think I'll stick to fairly plain vanilla stuff, even if it does take a little longer.

  3. Robert Grant

    JavaScript devs are also enjoying graphql more than Redux for the data layer

    They aren't equivalents. GraphQL is like REST; i.e. you might replace Axios with a GraphQL client. Redux is state management inside the client Javascript code.

  4. Anonymous Coward
    Anonymous Coward

    It looks web developers spend more time changing framework...

    ... than actually making web apps really working in a comfortable way.

    1. Pascal Monett Silver badge

      Must be the cost of having a vibrant ecosystem.

    2. bombastic bob Silver badge

      Re: It looks web developers spend more time changing framework...

      it's the temptation of "new, shiny" - like a cancer, except it's shiny.

      1. J27


        Yup and if you don't keep chasing it, you're out of a job. Web development is like chasing a slow-moving freight train. You can't rest for an instant or you lose it, because it's not stopping for anyone.

        1. Erp Erpington

          Re: Yeah...

          It also means that you're probably gonna have to do some job hopping, just to keep up with the breadth of different tech stacks out there. That hurt me last time I was looking for a job: I'd been at my previous job for too long, and I was good at the tech they used, but there's just so much out there that I'd never had a chance to try out.

          Of course, you often have to change jobs a lot if you want to be paid what you're actually worth, because hardly anyone gives real raises and promotions these days...

  5. Erik4872

    Doesn't paint JavaScript in the best light...

    Wind the clock back to the pre-framework era for a second. JS is being twisted into so many things it was never meant for. It used to be a simple language for controlling page elements dynamically.and was never designed to be a real "programming language" in the traditional sense.

    What boggles my mind is that the entire tower of frameworks, libraries and abstractions is built on such a rickety base. Just because every browser understands it, developers assume it's the best thing to build their entire world around. The fact that a coder-bootcamp graduate can't really be productive unless they're using some massive framework is not a good advertisement for the suitability of JS for all the things it's being pressed to do.

    If only Flash and Java weren't such security nightmares, web development might have been different. The web is littered with different tries at putting in something more suitable -- I wonder if anyone is going to try again, or if they're so scarred by Silverlight/Flash/Java that they're just going to keep heaping junk on top of JS.

    1. Marco van de Voort

      Re: Doesn't paint JavaScript in the best light...

      Yeah, I get the feeling that first gen JavaScripts are being confronted with legacy concerns, and it was not a nice meeting :-)

    2. Charlie Clark Silver badge

      Re: Doesn't paint JavaScript in the best light...

      One of the things the frameworks face is being replaced by native functions in the browser. This is to be welcomed, because over time it will simplify some of the stuff that is currently way too complex, but imposes a higher maintenance cost. And, as we all know, many many websites are barely maintained once written.

      1. Anonymous Coward
        Anonymous Coward

        Re: Doesn't paint JavaScript in the best light...

        Native functions? Like all the proprietry junk that has littered web browsers since their inception? Native functions that will stifle innovation, because it has to be built into the browser, then tested, then downloaded, then have a significant userbase before anyone adopts it? Or do you want to head back into the dark world of shims and compatibility js layers just to support a 'framework function'?

        The browser should be light, support a general JS feature set, and a general CSS set, and HTML5. All the frameworks should be entirely separate, because I don't want to be forced to use something that the big players have invested in - be it Facebook, Google, Microsoft, Apple, Adobe, Unilever, whoever. They only want what's best for them, not the general use of the Internet.

    3. Warm Braw

      Re: Doesn't paint JavaScript in the best light...

      To be fair, HTML was never intended as a means to produce complex interactive user interfaces, so having to monkey around with the DOM to produce, say, a date-input widget, is not something you're going to write from scratch if you can help it. Changing the language for altering the DOM doesn't really fix the underlying problem.

      1. W.S.Gosset Silver badge

        Re: WWW was never meant to be interactive

        > HTML was never intended as a means to produce complex interactive user interfaces

        Quite -- & actually quite the opposite.

        Our entire "modern" world-wide web is in fact only the Read-Only Prototype subset of hypertext, quickly hacked out by a chap frustrated at the slowness-of-progress on the all-singing-all-dancing 2-way hypertext environment -- just as a bit of a talking point, a demonstration that at least the display ideas worked, to actually SEE something tangible rather than all the endless theoretical wrestlings, and to encourage progress on the main problem.

        Instead, the world+dog leapt on the prototype and ran screaming off into the middle distance with it, and the full proper non-jumble-of-DSLs-masquerading-as-frameworks hypertext project kinda withered away in the background.

        It's been "amusing" to watch people progressively plug that originally-planned functionality back into things, but via nails-on-blackboard bandaid hacks tottering on top of, and leaning backwards over, something fundamentally read-only.

    4. Kubla Cant

      Re: Doesn't paint JavaScript in the best light...

      I suspect that part of the problem is the way the browser environment blurs coding skills with presentational talent. High-end sites will have UX specialists and graphic designers, though it's still a coder's job to get the concept on to the screen. Many sites make do with coders who have some sense of design.

      1. Michael Wojcik Silver badge

        Re: Doesn't paint JavaScript in the best light...

        When has that not been the case for user interfaces? Even in highly-constricted environments (GUIs built from simple, non-customizable widget sets, or CUIs in predefined menu environments such as ISPF, for example), user interfaces inevitably realize a user interaction model and enforce certain user experiences. Rarely do we see evidence that real UI designers - people with actual understanding of UI theory, doing actual UI research - were involved.

        How many people here have ever worked on a product where someone did a user ethnography study, or contextual inquiry, or any other methodologically-sound research into usability?

        1. W.S.Gosset Silver badge

          Re: Doesn't paint JavaScript in the best light...

          ...or who even have a clue what Fitt's Law is?

          1. AndyD 8-)₹

            Re: Doesn't paint JavaScript in the best light...

            "...or who even have a clue what Fitt's Law is?"

            hah! pointing devices - that's when it all went wrong -

            computer systems and interaction with same worked fine when output was read and input was typed. UPPER CASE ONLY even helped a bit with the typing (only slightly joking)

        2. Mike Pellatt

          Re: Doesn't paint JavaScript in the best light...

          Rarely do we see evidence that real UI designers - people with actual understanding of UI theory, doing actual UI research - were involved.

          Certainly no such evidence when it comes to the Windows UI. I still want to know what the guys who dreamt up the Ribbon for Office, whilst keeping the rest of the Windows UI as the "traditional" one were smoking.

          Coz I ain't going near it.

    5. Kevin McMurtrie Silver badge

      Re: Doesn't paint JavaScript in the best light...

      There were attempts to integrate Java applets into the HTML DOM. The idea was to ditch the arcane Sun Applet APIs in favor of something more modern and manageable. It never caught on for practical reasons. Java is a statically typed and compiled language while the HTML DOM is completely dynamic. It's not a good fit so it's hard to maintain.

  6. Elledan

    It's not about JavaScript

    The thing about these 'frameworks' is that they aren't so much JavaScript frameworks as DSLs: domain-specific languages, which just happen to be implemented using this prototype language that supports only IEEE 754 32-bit floating point and ASCII strings due to legacy reasons (like being dreamed up in two days back in 1995).

    Why nobody feels sad about these frameworks coming and going, and JQuery being the target of any front-end dev's jokes is that websites are pretty much disposable items. Give it two, three years tops before the next redesign and change to what's hot and new then.That's why backwards compatibility or even compatibility altogether doesn't really exist with anything JavaScript.

    Want to use JS modules? Pick your poison between AMD, NodeJS or ES6 modules. Oh, and there's that requireJS thing that nobody uses any more. Unless they do. Found a nice JS library? Too bad it was written for NodeJS and doesn't work in a browser. Or vice-versa.

    Having done both front-end and embedded JavaScript development (yes, it's a thing...), it's left me burned out to the point that I'll be very happy to never have to deal with it again in a professional setting. It's a very special world, but not one which I'm convinced is healthy for itself or those who venture deep into it. I'd rather deal with legacy C or FORTRAN code bases than ever touch a commercial JS project again.

    1. jake Silver badge

      Re: It's not about JavaScript

      For the record, there is still far too much work for not enough Fortran and COBOL coders. If you know either of them well, you can make a lot more money than a common or garden Java Script coder. If you know both, you can pretty much write your own ticket.

      Good old fashioned C will always have a place in the world of coding. It should be a part of any real programmer's toolbox.

    2. Tom 7

      Re: It's not about JavaScript

      I'd be quite happy to work on a JS project if it adhered to simple software management standards* and KISS - not found one yet.

      * perhaps the Unix idea of "Do one thing and do it well" is all we need..

      JS is like any other language - but it seems to have far too many self taught code warriors who can produce a simple flashy interface with all the bells and whistles but none of the organised back end supply lines required to keep it fighting for long.

      I think its fair to say legacy C and FORTRAN code is easier to work on - but only because the code warriors who wrote this stuff had experience of keeping the supply lines going - if they hadn't we wouldn't need to keep supporting it as it would have died out long ago,

    3. Michael Wojcik Silver badge

      Re: It's not about JavaScript

      supports only IEEE 754 32-bit floating point ASCII strings

      ECMAScript (which all modern "Javascript" implementations conform to, more or less) has supported 64-bit IEEE 754 floating point and Unicode strings since at least the 5th edition (2011). I'm almost positive earlier editions supported Unicode too (unsure about 64-bit floating point), but that's the version of the standard I have at hand.

      See ECMA-262 5th edition, sections 4.3.19, 7.8.4, and 8.4, and their references.

  7. Mike 137 Silver badge

    JavaScript is "overly complex".

    JavaScript is bloody lethal, and that's much more important than any complexity. The fundamental problem is an ingrained insistence of doing things client side that for safety should be done on the server. Add to that the common practice of kludging together arbitrary code fragments off web repositories and invoking unverified third party modules, and we get the mess we now call the web.

    A significant amount of JavaScript I've investigated is utterly unnecessary - e.g. using script for links and blocking the HTML anchor with #, or loading images using a script instead of the <img> tag, and can only be explained either by lack of understand or by the desire to force JavaScript to be enabled to allow snooping.

    Thank goodness for NoScript, and if I can't see your lovely pages as a result of using it, tough on you. There's always another better site I can visit.

    1. Sir Awesome

      Re: JavaScript is "overly complex".

      Call it self-celebrating, but I've always written all the JS I use myself, with the exception of the odd tool such as CKEditor. If I find a snippet I need online, I pull it apart and rewrite it to be sure I understand it and it adheres to my own standards.

      I'm also careful to also only use JS when something's not possible with native HTML or server-side code. Surely this is just a part of becoming a good coder?

      1. Spamfast

        Re: JavaScript is "overly complex".

        I'm also careful to also only use JS when something's not possible with native HTML or server-side code.

        I upvoted this because I largely agree, the gratuitous use of JS to do things that HTML and CSS are perfectly capable of doing alone annoys the hell out of me, for example.

        But there're some things that can't be done server-side such as rapid interactivity. Google Maps would be very clunky without client side code, for example.

        There's also the advantage of doing things client side in that it's more scalable. The server-side CPU and bandwidth resources required to serve up a set of static JS scripts, media assets, CSS & HTML files and a few WebSockets are way lower than trying to do everything at the head end for every client device.

      2. bombastic bob Silver badge
        Thumb Up

        Re: JavaScript is "overly complex".

        "only use JS when something's not possible with native HTML or server-side code"

        Good! Job!

      3. djnapkin

        Re: JavaScript is "overly complex".

        Re "but I've always written all the JS I use myself, with the exception of the odd tool such as CKEditor" - do you use jQuery? I find it doesn't impact the performance of my sites at all. Plus, the user's browser almost certainly has a cached copy already.

        1. bombastic bob Silver badge

          Re: JavaScript is "overly complex".

          (did you actually PROMOTE jquery???)

          I had to take over the 'web stuff' on an embedded project, and the "developer" slapped 3rd party "strap-ons" together to create the UI, which I then ended up hacking and heavily modifying to make it work.

          And throughout the code I've marked it up "TODO: un-jquery this" and similar. *I* *HATE* *JQUERY* - it is the *WORST* example of *WHY* *YOU* *DO* *NOT* *WANT* *SUCH* *THINGS* !!!

          It is *THE* PRIMARY example of why you do not want such "frameworks" at ALL.

          [learn to use DOM, and you will not NEED such things - W3Schools web site and others will help you. Search engines are your friend. I use them a LOT]

    2. Michael Wojcik Silver badge

      Re: JavaScript is "overly complex".

      The fundamental problem is an ingrained insistence of doing things client side that for safety should be done on the server

      That is not a "fundamental problem" of the language, by definition. It's not an attribute of the language at all. It's a matter of how it is used.

      1. Spamfast

        Re: JavaScript is "overly complex".

        Let's all do server-side database queries by concatenating GET & POST responses onto SELECT strings and client-side JSON parsing by executing it as JS. What could possibly go wrong?

        Never trust anything that's come to you over a comms channel any part of which is not under your control. That applies to clients receiving server data and vice versa. Sandbox everything.

        1. bombastic bob Silver badge

          Re: JavaScript is "overly complex".

          not so much sandboxing, but sanitizing. A good sanitizing algorithm will eliminate the possibility of SQL injection, as one example...

          my favorite is to look for ';' and '/' (or quotes, or path starts with '..' etc. - or SQL keywords if that's at issue) and just reject things outright that contain these characters/sequences. Others also exist. simple test. PHP script has some other built-ins as well.

          the only reason you would NOT want to do everything server-side is performance latency [when the server is across the world, let's say, or the bandwidth stinks]

  8. Anonymous Coward
    Anonymous Coward

    The reason javascript has so many frameworks

    Is because the people who develop in it are mostly 3rd rate programmers who couldn't cope using grown up languages writing proper systems and couldn't hack their way out of a wet paper bag so need even the most basic things done for them so they can plug lego their brick code together and pretend they're professionals to the pointy hairs.

    1. martinusher Silver badge

      Re: The reason javascript has so many frameworks

      >Is because the people who develop in it are mostly 3rd rate programmers

      That's probably being a bit harsh. Judging by the profile of these programmers they seem to be both inexperienced and badly led. You get young people straight out of their CS degree course, you pay them big bucks and work them to death (because the language requires that kind of bottom up knowledge; more experienced programmers would be asking the 'why' and 'what' and probably wouldn't appear as productive in terms of 'code lines per day' output). The result's invariably rubbish -- there's a few exceptions to the rule, but generally the result is bloat, communications overload and bugs.

      I don't blame the guys in the trenches because someone blew the whistle and ordered them to attack. Lions led by donkeys....

  9. jospanner

    A javascript-heavy website is a bad website.

    Thank god for uBlock.

    1. (m)any

      And uMatrix.

  10. John Gamble

    Everything Changed with ECMAScript 6

    It's the reason jQuery (and a couple other libraries) became irrelevant, and it's why "good parts" philosophy could be enforced. Javascript is still a little clunky, but a lot of the comments above are clearly based on turn-of-the-century experiences.

    I'm still a little scarred from previous experiences, and I'll note that I backed a couple of losers in the Javascript world, but on the other hand I'm glad a testing framework has finally gotten some consensus.

  11. Dave559

    More of this sort of thing, please

    More of this sort of thing, please.

    Thank you, this was an interesting article, and, as usual, further greatly enhanced by some helpful and informative comments by fellow commentards.

    I don't know why The Powers That Be at The Reg decided at some point to silo off software development related articles to a dead-end separate website (Dev Class) with no commenting/forum available (and therefore, no disrespect to your journalists intended, immediately losing half of any potential value that it might have, by excluding the input of the community that The Reg itself has built up over many years), but I for one would be very pleased to see more software development articles, like this one, actually on The Reg itself in the future.

    1. W.S.Gosset Silver badge

      Very much more of this sort of thing, please

      Hear hear. Very much hear hear.

      I've been growingly concerned that El Reg is turning away from its USP.

      Viz., (ex)front-line practitioners, writing entertainingly but with ability to land more telling blows than others due to actually understanding what's important and understanding what's going on under-the-hood and behind-the-scenes. Not just pure IT but relevant and insightful, eg Worstall. This, in a nutshell, is how TheRegister has garnered a global gold-class reputation.

      Latterly, it's all got very samey-samey, little or no UTH/BTS insight, cookiecutter journo-ese. Very occasional and very refreshing returns to form (eg Dabbsy, Stobb), but so few now as to start mourning the loss of what ElReg stood for.

  12. Anonymous Coward
    Anonymous Coward

    Why is JavaScript "overly complex"?

    Because of all the features developers kept asking for. And the pressing need to be "ahead of the Joneses".

  13. Anonymous Coward
    Anonymous Coward


    C never needed all this gubbins tacked on. Is Javascript really fit for purpose?

  14. Anonymous Coward
    Anonymous Coward

    It's always been a mess.

    I was a server side developer and we used to develop with a lot of MVC and have been amazed at the capabilities of these frameworks ,BUT, having put up with my own browsing and increased network volumes loading frameworks and libraries (especially on high volume websites) - I long for the day of a clean interface.

    When I started with CSS, JavaScript etc - I used to always go back to the likes of to see how we could focus on the content and clean, simple, low bandwidth HTML code and separate out the CSS and design elements.

  15. Kevin McMurtrie Silver badge

    DOM it to hell

    I think JavaScript is evolving fairly well but the object model HTML isn't. HTML elements can't behave as ordinary data structures for JS to manipulate. You can't define them in JS variables/constants using HTML syntax. You can't manipulate them in the DOM without rebuilding the GUIDs and backlinks. This is where the frameworks come in to help. These frameworks seem to die a bloated death every 6 months and be replaced by another having the same fate. Just fix the object model and give poor front-end developers a break.

  16. prandeamus

    How to track this one

    I think this website says it all:

  17. Joker421

    Angular still strong

    Angular is declined? No way. Angular has it's own market and it is still strong.

    AngularJS is declined that is true, moreover it is just was being officially deprecated in Dec 2021

    However AnulgarJS (v1.x) and Angular(2+) are two completely different things !=

    1. diodesign (Written by Reg staff) Silver badge

      You're commenting on an article from 2019... which the people who did the survey chose not to make a distinction between Angular and AngularJS.


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