One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked.
So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.
On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery just isn't so needed.
The same path is likely on all frameworks - they were designed to solve specific use cases, and as the entire industry matures, different solutions will embed themselves in the industry in different ways, reducing the raison d'etre for each framework, over time.
Yep! Same for React. It has a much smaller API surface area than Angular (and goes wrong it mysterious ways less often!), so fewer people will be asking questions about it.
From my perspective, it appears that React is still very much in ascendancy.
Indeed! In fact, after I spent time using react and angular for two separate products, I actually switched back to mostly rolling my own JQuery (usually).
It just works, and takes up much less of my mindshare than trying to learn various frameworks every time I roll a new site (which incidentally is every 3 - 6 months). There is always more support for it (with all the questions being answered), and the API never changes. I actually develop faster, although typically I’m using web frameworks with templating backends - such as Rails (Ruby), Django (Python), Flask (Python), and Revel (Go)
Right, jQuery is good and mature, and I can usually find what I need in the documentation. It will never die.
I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.
Similarly, JQuery questions remain higher than the other ones in that chart; does that mean JQuery remains popular, or that JQuery is hard and people need a lot of help for it?
Speaking for myself, it was often easier to copy / paste SO answers (in jquery) than try and figure things out for myself. I can imagine a lot of beginning developer start with jQuery and go to advanced frameworks after that.
Very good point and this obviously can skew the results greatly. Working in a fairly senior mid-size team I don't remember any of my colleagues asking any question on SO either so results could be also skewed by composition of user base and how good the docs are for a given proj.
Yeah, it’s not like these sites have stopped using jquery altogether: my site uses React components but I still write a couple lines of jquery here and there for basic uses.
It is not really a brutal lifecycle at all, to be honest.
Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather:
In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from:
- Having static resolution for websites to dynamically changing site resolutions
- Having static HTML renders with some dynamic bits sprinkled over to full-blown SPA-s because of a variety of reasons*
- Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago
- Having gone from "nothing" to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based (<webGL>),
- Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems
And I could go on and on and on and on.
The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly.
The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with.
(heads up, you need have a blank space between lines in HN to render them on different lines)
I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms.
I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months.
There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.
"The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with."
These frameworks are not as different, though, so I don't that's the driving force.
I think that the implicit argument of the article is that although new frameworks emerge, almost none of them get a large enough ecosystem or amount of adoption to become entrenched.
The other thing that the author hints at is that there is a relationship between server-side platforms and choice of JS framework. Ember got a small lift because it was co-designed by one of the best and most well-known Rails developers, but Rails people seem to have gone to React, and Angular seems to have been adopted by the C# community to the point that Microsoft and Google run joint events. Thus newcomer JS frameworks are less likely to get enough adoption to stick around, because server-side frameworks now have implicit default JS frameworks.
The interesting story in this post is not about JS frameworks. It is about StackOverflow.
The Ember community made a proactive decision to abandon StackOverflow around the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide the tools we needed. For example when you answer a question: Are you answering for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is different. Perhaps, over time, an answer that once was correct is now suggesting something deprecated or not in line with best practices.
StackOverflow doesn't provide any features for dealing with versioning and changes in what is correct over time.
If your community has a StackOverflow moderator, perhaps you can update all the answers you want on a regular basis. I don't know, because our community had no such person, and the StackOverflow team was disinterested in helping us come up with a solution (the Ember project reached out).
Additionally as a tool matures (Ember is over 5 years old) you take more of this stuff under your own wing. Ember has a robust set of companies offering video training, in person training, and books. We have a community chat, a forum, and very active meetups. All of these things are controlled by members of our community, meaning they can respond to changes more fluidly than StackOverflow (moderated by some people outside our community) ever could.
StackOverflow just is not designed for long-lived multi-versioned software. So guess what happens? Users of that software don't stick around on StackOverflow. For living projects the short-term trend will almost always look better than long-term trends.
Ember's story here is not universal. I'm glad there are developers finding StackOverflow useful for other libraries. I think the story StackOverflow should tell is one that focuses on what they do well. But to draw a meaningful lesson about the JS community as a whole from such a idiosyncratic data source is a fools errand.
I think this is the most important takeaway. It's especially true for smaller libraries and commercial libraries. And even for huge ones like Rails, questions answered 6 years ago might be little more than a catalog of improper practices by now!
For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net
It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble:
* 180 questions tagged gojs
* 449 questions tagged jointjs
* 518 questions tagged jsplumb
These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS!
In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others.
StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.
StackOverflow is not a substitute to writing an API reference guide. Are you saying that Ember never planned to document anything of their framework? That sounds like a big problem.
The PHP and Vue correlation can at least partly be explained by the fact that Laravel, a popular PHP web framework, has first-hand support for Vue and installs Vue by default in projects bootstrapped with their cli tool.
As an aside from the interesting article, does any one else find it pretty scary and privacy invading that stackoverflow think it's ok to match our IP addresses to the company we work in?
It seems like a massive invasion of privacy (which I guess lots of websites are doing).
But to me that SO can so casually mention the mass surveillance and privacy invasion they're doing without thinking that there's anything wrong with it is the worst part of it.
I certainly never knowingly agreed that they could check my IP address and then try and figure out what company I work at from it.
EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I can challenge this privacy invasion and inappropriate use of personally identifying data. I guess we'll see if GDPR has any actual teeth in this instance.
Your IP is public, so you can't hide it; privacy invasion is a non-argument there.
IP data retention, on the other hand, will be interesting. On the one hand, law enforcement wants to have ISPs and companies to track and remember those, for future investigations. But on the other hand, privacy advocates want that kind of data to not be stored at all.
Much of the industry Stack Overflow serves is based on collecting, aggregating, and selling access to exactly this sort of data. I'm not sure what to think of this specific example, but it's just one small manifestation of whatever it is, bad thing or not.
I always have to show up to reiterate this is not a problem limited to Javascript. There have been framework fads for as long as there have been frameworks. I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things.
It does seem like there are more of them and they rise and fall faster in the Javascript world, but this is probably better explained by the sheer number of Javascript programmers than anything else. The labor statistics I can find peg the number of US software developers in 2002 at around 612,000 and around 3.87 million in 2016 - and most of the new ones focus on web development. There are way more web programmers out there than there have really ever been, so it makes sense that the rate of frameworks appearing (and to a degree, the overall lifecycle churn) would be accelerated.
Why is the measurement on questions asked for the first couple of graphs and then user traffic for the latter set? I wonder if traffic is the better measurement for the first two as well but I bet the graphs won't look quite as doom and gloom.
The first few graphs use the interactive [Stack Overflow Trends](http://insights.stackoverflow.com/trends) tool, which is all public data. This is useful since it lets readers modify the graphs (for example, to add a few more tags to the comparison).
The later graphs use data that's already not public (what tags users visit together, and what countries tags are visited from), so there's no reason not to use visits instead.
The graphs for visits over time do look very similar (in general question traffic by tag roughly matches questions asked, but as a slightly lagging indicator)
> PHP developers [...] visit a disproportionate amount of Vue.js questions.
I would guess this is because the installer for Laravel (one of the most popular PHP frameworks) defaults to scaffolding a Vue.js app for your frontend.
Remember that Merb was merged into Rails? That's a community converging, that's what brought Ruby to the point that it is recruiter-speak synonymous to Rails.
In the JS world: not so much. But that prolly has many reasons. I can think of: the language changing rapidly, the community not very "close", people coming to JS from widely different places, and the fact that a JS framework can span either the FE or the BE or both!
I thank YUI and later jQuery for getting me my first real software development job.
Today it looks surreal that a mere portfolio of mind boggling animation effects would be enough to get a 21 year old an $84k job, but back in the time of peak web 2.0 craze, just having words jquery and 3 years experience on your resume was just enough to get 3 to 4 calls with ready offers every month.
It's easy to see graphs trending down and say, oh, interest is waning. But the initial spike could just be lots people going through a learning curve. It tells you something about popularity, but ease-of-use, quality of docs, etc. must all factor in as well. I tend to see the high number of questions on certain frameworks as a red flag.
I certainly agree with the hypothesis of this article. I'd like to see how this compares with languages and not just frameworks overtime. How does this curve compare with mature/in-demand languages such as Java, PHP, JavaScript, .Net, Python etc. Do we find a similar graph with languages?
Ditto for React. Pretty much every "how do I do this" is covered in the official tutorial and every "how should I do this" is covered by supplemental guides (still official docs).
Some good ones: "thinking in React", "lifting state up", "controlled components", and similar docs in redux: "you might not need redux"
My question as a Java/Swing developper is this: what is the difference between React and Web Components? As far as I understand, both create self-contained components that you can use in your HTML, and that will react when you alter their DOM structure (for example changing an attribute value, or binding an HTML input value with an internal value inside the component).
And from that perspective, will we see in the future off-the-shelf HTML components (based on React or Web Components) just like we can use custom Swing components ?
Pretty much a Gartner's Hype Curve like behaviour on each case. Accelerated adoption, a peak, then delusion kicks in causing many people to lose interest and step away from the technology. Late adopters find lower barriers of entry later on caused by lessons learned and improvements made to the same technology. Usage increases again but a lower level when compared to the initial peak. Expectations around tech's capabilities are now more concrete and realistic, bringing stability to the ecosystem as a whole.
About to make an App using React(and react native?)
Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.)
For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer?
Also, this topic implies React will be gone in about ~5 years? That sounds good for me.
> Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.)
You can still do this with React. Some of the most-common general-purpose libraries for working with React aren't that big and could be written from scratch pretty easily. If you recognize when something's entire purpose is apparently to replicate OO features while staying "purely" functional by jumping through a series of awkward hoops, you can recall that the language you're writing in does, in fact, support OOP, and avoid the library altogether by using built-in language features (I keep seeing this in the React ecosystem and it drives me nuts).
Probably use Redux because everyone and everything expects that you are. It's easy to understand if you ignore their bad terminology and go in knowing it's just an event/messaging system, more or less. Action = event. "Action creator" = anything that dispatches an event. Reducer = your event handlers. Exactly what you'd expect from an event system with centralized event handling. Utterly mundane and non-magical. Figure out how to leverage "combineReducers" to keep your file structure sane and just go. The closest thing it has to magic going on is that when an event comes through it checks to see whether any of the refs in your "state tree" changed as a result of that event, and triggers re-renders on relevant connected view(s) (React views, in your case). That's it. Note that with a very little creativity one can decouple one's Redux code and most/all of one's business logic into its own library to share it between React and React Native.
If you use React Native, you're in for a treat if you're used to fully native cross-platform dev. It really does a great job of rounding off the many, many rough corners on Android that make it such a pain-in-the-ass to work with. Warning: the ecosystem's kinda nutty and does a bad job of keeping in sync, so avoid dependencies that directly target React Native as much as possible if you want to ever be able to, say, upgrade your React Native version without breaking everything. Pure JS libs that have no truck with React Native, good. Libs that add narrowly-scoped extra native integration for RN, usually good. Mostly JS libs that add on to React Native itself, typically just a disaster waiting to happen, no matter how nice they seem at first.
Oh, and use Typescript. For the love of god use Typescript. Just start the project with it, and never look back.
I would learn React if I was you. Check out create-react-app on Github. It will set you up with a working app to play with in a matter of seconds. If you're expecting to use React Native it looks like they have a create-react-native-app also.
I moved my frontend (I mean "in browser" by that) dev to elm about a year ago, and it's been a year of peace. I know elm has flaws, and it's development workflow can be criticized for being too slow or conservative, but it's been so predictable, so easy to work with, so maintainable and so solid in production, I have never been so happy about frontend dev.
Brand new frameworks have zero docs and zero questions in Stack Overflow. Older frameworks have (hopefully) complete docs and a library of SO questions. In between you get a gradient.
I'm just not convinced that the data they're looking at means what they think it means.
Just because the number of questions decreases about a framework does not mean people have stopped using the framework. I ask very few questions because I am normally working behind the bleeding edge and can get my questions answered simply by searching.
[+] [-] Kajayacht|8 years ago|reply
So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.
[+] [-] codingdave|8 years ago|reply
The same path is likely on all frameworks - they were designed to solve specific use cases, and as the entire industry matures, different solutions will embed themselves in the industry in different ways, reducing the raison d'etre for each framework, over time.
[+] [-] nicoburns|8 years ago|reply
From my perspective, it appears that React is still very much in ascendancy.
[+] [-] lettergram|8 years ago|reply
It just works, and takes up much less of my mindshare than trying to learn various frameworks every time I roll a new site (which incidentally is every 3 - 6 months). There is always more support for it (with all the questions being answered), and the API never changes. I actually develop faster, although typically I’m using web frameworks with templating backends - such as Rails (Ruby), Django (Python), Flask (Python), and Revel (Go)
[+] [-] slig|8 years ago|reply
[+] [-] jcadam|8 years ago|reply
I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.
[+] [-] Cthulhu_|8 years ago|reply
Speaking for myself, it was often easier to copy / paste SO answers (in jquery) than try and figure things out for myself. I can imagine a lot of beginning developer start with jQuery and go to advanced frameworks after that.
[+] [-] myth_drannon|8 years ago|reply
[+] [-] collyw|8 years ago|reply
[+] [-] itcmcgrath|8 years ago|reply
Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false
[+] [-] emodendroket|8 years ago|reply
[+] [-] qaq|8 years ago|reply
[+] [-] aalleavitch|8 years ago|reply
[+] [-] iambateman|8 years ago|reply
[+] [-] jonnycomputer|8 years ago|reply
[+] [-] Sawamara|8 years ago|reply
Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather:
In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from:
- Having static resolution for websites to dynamically changing site resolutions - Having static HTML renders with some dynamic bits sprinkled over to full-blown SPA-s because of a variety of reasons* - Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago - Having gone from "nothing" to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based (<webGL>), - Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems
And I could go on and on and on and on.
The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly.
The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with.
[+] [-] Klathmon|8 years ago|reply
I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms.
I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months.
There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.
[+] [-] sjellis|8 years ago|reply
These frameworks are not as different, though, so I don't that's the driving force.
I think that the implicit argument of the article is that although new frameworks emerge, almost none of them get a large enough ecosystem or amount of adoption to become entrenched.
The other thing that the author hints at is that there is a relationship between server-side platforms and choice of JS framework. Ember got a small lift because it was co-designed by one of the best and most well-known Rails developers, but Rails people seem to have gone to React, and Angular seems to have been adopted by the C# community to the point that Microsoft and Google run joint events. Thus newcomer JS frameworks are less likely to get enough adoption to stick around, because server-side frameworks now have implicit default JS frameworks.
[+] [-] webDevSucks|8 years ago|reply
[deleted]
[+] [-] mixonic|8 years ago|reply
The Ember community made a proactive decision to abandon StackOverflow around the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide the tools we needed. For example when you answer a question: Are you answering for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is different. Perhaps, over time, an answer that once was correct is now suggesting something deprecated or not in line with best practices.
StackOverflow doesn't provide any features for dealing with versioning and changes in what is correct over time.
If your community has a StackOverflow moderator, perhaps you can update all the answers you want on a regular basis. I don't know, because our community had no such person, and the StackOverflow team was disinterested in helping us come up with a solution (the Ember project reached out).
Additionally as a tool matures (Ember is over 5 years old) you take more of this stuff under your own wing. Ember has a robust set of companies offering video training, in person training, and books. We have a community chat, a forum, and very active meetups. All of these things are controlled by members of our community, meaning they can respond to changes more fluidly than StackOverflow (moderated by some people outside our community) ever could.
StackOverflow just is not designed for long-lived multi-versioned software. So guess what happens? Users of that software don't stick around on StackOverflow. For living projects the short-term trend will almost always look better than long-term trends.
Ember's story here is not universal. I'm glad there are developers finding StackOverflow useful for other libraries. I think the story StackOverflow should tell is one that focuses on what they do well. But to draw a meaningful lesson about the JS community as a whole from such a idiosyncratic data source is a fools errand.
[+] [-] simonsarris|8 years ago|reply
For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net
It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble:
* 180 questions tagged gojs
* 449 questions tagged jointjs
* 518 questions tagged jsplumb
These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS!
But behold, Google trends: https://trends.google.com/trends/explore?date=all&q=gojs,joi... (ignore the last, partial-data month)
In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others.
StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.
[+] [-] user5994461|8 years ago|reply
[+] [-] mkern|8 years ago|reply
[+] [-] mattmanser|8 years ago|reply
It seems like a massive invasion of privacy (which I guess lots of websites are doing).
But to me that SO can so casually mention the mass surveillance and privacy invasion they're doing without thinking that there's anything wrong with it is the worst part of it.
I certainly never knowingly agreed that they could check my IP address and then try and figure out what company I work at from it.
EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I can challenge this privacy invasion and inappropriate use of personally identifying data. I guess we'll see if GDPR has any actual teeth in this instance.
[+] [-] Cthulhu_|8 years ago|reply
IP data retention, on the other hand, will be interesting. On the one hand, law enforcement wants to have ISPs and companies to track and remember those, for future investigations. But on the other hand, privacy advocates want that kind of data to not be stored at all.
[+] [-] rainbowmverse|8 years ago|reply
[+] [-] tkone|8 years ago|reply
[+] [-] dasil003|8 years ago|reply
[+] [-] _greim_|8 years ago|reply
So what are we measuring here? It seems obvious that more popular frameworks would generate more questions, but so would:
- Newer ones which not as many people are familiar with.
- Poorly-designed ones which lots of people nevertheless use.
- Ones which disproportionately attract inexperienced devs.
[+] [-] catpolice|8 years ago|reply
It does seem like there are more of them and they rise and fall faster in the Javascript world, but this is probably better explained by the sheer number of Javascript programmers than anything else. The labor statistics I can find peg the number of US software developers in 2002 at around 612,000 and around 3.87 million in 2016 - and most of the new ones focus on web development. There are way more web programmers out there than there have really ever been, so it makes sense that the rate of frameworks appearing (and to a degree, the overall lifecycle churn) would be accelerated.
[+] [-] lakechfoma|8 years ago|reply
[+] [-] var_explained|8 years ago|reply
The later graphs use data that's already not public (what tags users visit together, and what countries tags are visited from), so there's no reason not to use visits instead.
The graphs for visits over time do look very similar (in general question traffic by tag roughly matches questions asked, but as a slightly lagging indicator)
[+] [-] rwbcxrz|8 years ago|reply
I would guess this is because the installer for Laravel (one of the most popular PHP frameworks) defaults to scaffolding a Vue.js app for your frontend.
[+] [-] cies|8 years ago|reply
In the JS world: not so much. But that prolly has many reasons. I can think of: the language changing rapidly, the community not very "close", people coming to JS from widely different places, and the fact that a JS framework can span either the FE or the BE or both!
[+] [-] scottmf|8 years ago|reply
[+] [-] baybal2|8 years ago|reply
Today it looks surreal that a mere portfolio of mind boggling animation effects would be enough to get a 21 year old an $84k job, but back in the time of peak web 2.0 craze, just having words jquery and 3 years experience on your resume was just enough to get 3 to 4 calls with ready offers every month.
[+] [-] drderidder|8 years ago|reply
[+] [-] systematical|8 years ago|reply
[+] [-] ToJans|8 years ago|reply
You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...
[+] [-] FLGMwt|8 years ago|reply
Some good ones: "thinking in React", "lifting state up", "controlled components", and similar docs in redux: "you might not need redux"
[+] [-] lolive|8 years ago|reply
And from that perspective, will we see in the future off-the-shelf HTML components (based on React or Web Components) just like we can use custom Swing components ?
[+] [-] pjmlp|8 years ago|reply
https://summit.polymer-project.org/
https://developer.chrome.com/devsummit/
You can some components here, as well as, the current state of browser support.
https://www.webcomponents.org/
Currently only HTML Imports seem to be a point of disagreement.
I am looking forward to them, as they can be the way for more sanity on Web development.
[+] [-] rodolphoarruda|8 years ago|reply
[+] [-] mkirklions|8 years ago|reply
Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.)
For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer?
Also, this topic implies React will be gone in about ~5 years? That sounds good for me.
[+] [-] ashark|8 years ago|reply
You can still do this with React. Some of the most-common general-purpose libraries for working with React aren't that big and could be written from scratch pretty easily. If you recognize when something's entire purpose is apparently to replicate OO features while staying "purely" functional by jumping through a series of awkward hoops, you can recall that the language you're writing in does, in fact, support OOP, and avoid the library altogether by using built-in language features (I keep seeing this in the React ecosystem and it drives me nuts).
Probably use Redux because everyone and everything expects that you are. It's easy to understand if you ignore their bad terminology and go in knowing it's just an event/messaging system, more or less. Action = event. "Action creator" = anything that dispatches an event. Reducer = your event handlers. Exactly what you'd expect from an event system with centralized event handling. Utterly mundane and non-magical. Figure out how to leverage "combineReducers" to keep your file structure sane and just go. The closest thing it has to magic going on is that when an event comes through it checks to see whether any of the refs in your "state tree" changed as a result of that event, and triggers re-renders on relevant connected view(s) (React views, in your case). That's it. Note that with a very little creativity one can decouple one's Redux code and most/all of one's business logic into its own library to share it between React and React Native.
If you use React Native, you're in for a treat if you're used to fully native cross-platform dev. It really does a great job of rounding off the many, many rough corners on Android that make it such a pain-in-the-ass to work with. Warning: the ecosystem's kinda nutty and does a bad job of keeping in sync, so avoid dependencies that directly target React Native as much as possible if you want to ever be able to, say, upgrade your React Native version without breaking everything. Pure JS libs that have no truck with React Native, good. Libs that add narrowly-scoped extra native integration for RN, usually good. Mostly JS libs that add on to React Native itself, typically just a disaster waiting to happen, no matter how nice they seem at first.
Oh, and use Typescript. For the love of god use Typescript. Just start the project with it, and never look back.
[+] [-] dentemple|8 years ago|reply
You can easily get by with someone that has years of Javascript experience instead, preferably a developer who's familiar with Functional-style JS.
[+] [-] brentm|8 years ago|reply
[+] [-] kuon|8 years ago|reply
[+] [-] larrik|8 years ago|reply
Brand new frameworks have zero docs and zero questions in Stack Overflow. Older frameworks have (hopefully) complete docs and a library of SO questions. In between you get a gradient.
I'm just not convinced that the data they're looking at means what they think it means.
[+] [-] watsocd|8 years ago|reply