The Brutal Lifecycle of JavaScript Frameworks | Hacker News Reader

The Brutal Lifecycle of JavaScript Frameworks

stackoverflow.blog

224 pointslainon122 comments

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.

Agreed. It'd be nice to have graphed the number of pageviews of each tag as well.

Just made me think about a great metric as a developer: understanding how popular each SO page is about your library. Ie. "X is still catching up everyone, it's a very busy page. We have done a good job making Y more obvious, people aren't searching for it anymore."

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.

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.

The chart seemed to show React to be growing very quickly as well.

From my anecdotal experience of just watching SO's React queue, most questions about React that show up (that aren't repeats) are almost always regarding how it's used with some library in the ecosystem.

React-router, Redux, Webpack, Material UI, etc.

So even though the API itself small, there's still an endless number of questions out there for people to ask!

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.

This intuitively makes sense, but I'd like to see some control data. Has the volume of PHP questions (for example) fluctuated much over time?

http://sotagtrends.com/?tags=[jquery,python]&relative=false

That seems like a pretty compelling counterpoint.

Looking at the regex tag would suggest this logic doesn't necessarily hold.

Surely they could have used the number of times questions were viewed rather than asked.

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)

I did that on a product as well. It went pretty well. The issue is with more complicated UI. The more complicated it is, the faster JQuery breaks down. That being said, it's better to have a bit of a spaghetti JQuery than to try and retrain unwilling programmers in Angular.

jQuery doesn't have to be spaghetti though. It gets that rap I think because most people that used it weren't good/experienced enough to organize bigger code. It can/usually does turn into a mess though but is faster to bang small things out in for me anyway.

It doesn’t have to be spaghetti. You are right. However, when you change state in multiple places, they either have to be aware of each other or you need some kind of state management. The benefit of libraries like React are that they abstract view rendering and take care of DOM diffing. The benefit of frameworks like Angular is that it manages state in addition to what React does.

On simpler projects, JQuery is more productive. But my main point is to program where it is comfortable and practical. The better academic choice is not necessarily the better choice. View your programming resources as people and make the pragmatic choice.

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.

Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.

> It can be done but it's brutal and fragile.

Actually many who did jQuery were proud of it.

Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement.

Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-)

Edit: and given what we have seen over the last few days now would be a good time to reconsider if every website really needs to be able to run Javascript.

I miss progressive enhancement, when/why did it die.

Did progressive enhancement ever catch on? It made for some great Rails 2 tutorials but I don't remember seeing it much in the wild.

It's going away because you basically have to write everything twice and it's hell to keep consistent.

If you need your website to work without JS, Nuxtjs is an amazing VueJS framework for SSR or static prerendering.

For the majority of my web development that verb is in the present tense.

I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago and it seemed like a complete disaster. Recently, I've been working on Vue and this seems a bit better.

> And [jQuery is] a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

> Is it just me

Probably.

Depends on the SPA. If you're trying to do something relatively simple, where the events and state clearly map to the UI, jQuery isn't too bad. It's even fun.

Once your SPA goes through an iteration or two with a few different programmers, you find your events have nasty ordering dependencies and your data becomes inconsistent all on its own. You have no idea why because you can't reproduce any of these issues on your own. You have to watch other people interact with your app just to reproduce bugs ("why the hell would you double click a link?") and git bisect becomes the most productive tool in your toolbox. Most project discussions end with a shrug. You yearn for the days when it was possible for a single human to ever understand the entire app, but that was six months ago and management steadfastly refuses to fund a rewrite. You look wildly around for any sign of hope...

As for Angular, agreed, but I'd rather work with it than a bunch of jQuery. React and Vue are quite pleasant.

>And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

Not at all. The issue with an application written in jQuery is a lack of sane state management. Forgetting to initialize (or re-initialize) values, not expecting things to be executed in a different order, and just poor organization in general led to mountains of runtime errors.

Nowadays we use Elm. The difference is night and day. I wrote a post on this topic a few months ago: https://charukiewi.cz/posts/elm/

I wish those days were past.

Need to target IE 11 and FF ESR currently.

I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]

Yes, in a way... it’s certainly (IMO) nicer to use than the DOM API. But “done right” used to mean not just “nicer to use” but “actually implemented correctly” (unlike major browsers at the time). Now that the DOM basics are pretty well-standardized, it’s mostly just “sugar” which isn’t necessarily worth the extra bundle size.

Another, bigger factor is that most modern frameworks use some form of templating and binding which means that you have less need to modify/interact with the DOM directly.

DOM APIs have much improved since jQuery first arrived, so while that was the case originally, it's become less true over time. It's definitely still less verbose though, for example:

  $('.my-component div').css({ background: 'yellow' })

vs.

  Array.from(document.querySelectorAll('.my-component div')).map(node => {
    node.style.background = 'yellow';
  })

Why use map instead of forEach?

If you only want to translate(map) each element in to another set of value, using Map is much more simpler and readable than forEach

The code loops through an array, has side effects and returns nothing so forEach would be more descriptive IMO.

As for simple/readable it’s the same code but s/map/forEach.

Actually, this is incorrect. You're abusing map here. The purpose of map is to map an existing array onto a new array. You're using map here to mutate properties on nodes in the original array, and creating a new Array, which has the length of the initial array, where each value is the return value of `node.style.background = 'yellow';`

forEach is much more indicative of what you're actually doing here, which is running through an iterable and mutating properties on each node.

Simple rule of thumb: if you're not using the results of `map`, you shouldn't be using it.

The modern DOM API has forEach on NodeList so you can skip the Array.from.

  document.querySelectorAll('.my-component div').forEach(node => node.style.background = 'yellow');

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo...

"Of course there's going to be less questions"

Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false

You could argue that jQuery covers handling (a part of) DOM APIs which are updated only rarely.

Once you know what $().append().on().trigger() does, there's not that much left to know about jQuery. And most everything can be understood from docs.

Python, however, is a continuously evolving language with an ever expanding number of libraries and areas of application.

Python is just an outlier when looking at this. Here's[1] a larger set of languages and frameworks, and given the premise it's not hard to guess the JS frameworks from the graph.

1: http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,rub...

StackOverflow's job posts show the same trend. Jquery is required less and less http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cj...

But again probably less <this is losing popularity> and more <this is no longer cool to tag>. That's a really nice tool though

That's a possible explanation too. No one wants to say that the job is mostly maintaining large Angular codebase in addition to a small internal tool written in React that only senior stuff is allowed to play with...But hey we are a React shop!

I think part of that is that jQuery is pretty universal and it's probably assumed that if someone says they know JavaScript, they know jQuery. Or, I at least assume that when I'm doing interviews.

I think that would apply more to an Html than Jquery

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.

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.

In addition to the possibilities you listed, it might mean:

* most sites aren't SPAs, and progressive enhancement of a document with light interactivity via jQuery is a development model that's a good fit for those sites

* progressive enhancement of a document is an easier development model to move into from having started to author HTML & CSS than many of the SPA frameworks (note that this is also true of PHP), and many training materials that bring people into web authoring use js+jQuery as the next step

* many sites aren't rewriting their codebases particularly frequently, and anything used there remains relevant longer.

ha, i came here to say this. I'd rather see web traffic results.

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.

Thank you! Oh, now that you mention it: just a few years ago, web streaming was not possible without using either flash or (maybe?) silverlight or something else because it was not implemented yet. Youtube crashed my pc regulary during the hd4850 end-days due to driver crashes. Node was not even a thing yet, let alone Electron/NWJS....

"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!

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.

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.

WordPress.com But Vues triumphal march starts before Laravel or WordPress.

My understanding is that this tweet https://twitter.com/taylorotwell/status/590281695581982720?l... kickstarted the Vue popularity. Taylor Otwell is the creator of Laravel.

Here's Evan You (creator of Vue) https://youtu.be/D_z-RAweP1k?t=3m9s talking about the tweet.

WordPress.com uses React[1] and the new WordPress CMS Gutenberg[2] editor is also using React. (Just FYI)

[1] https://github.com/Automattic/wp-calypso

[2] https://github.com/WordPress/gutenberg

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.

Does SO operate in the EU?

They don't block EU users, so they do business in the EU.

As it offers goods and services to EU citizens, it has to operate according to GDPR as far as I understand it.

And it does do sales in the EU, there are plenty of SO jobs being advertized (and paid for) in the EU.

I know GDPR is written this way, the question is how it will be enforced? If SO has no operations in the EU, and it's literally just take EUR payments, and the volume is relatively small (or they figure out some offshore processing hack) then they could make the decision to stop processing EUR and give GDPR the middle finger. That's a lot of ifs, but it's not a foregone conclusion that European markets are worth the GDPR headache.

No, they'd have to block the whole of the EU from accessing the site.

They said they only did this for US based IP addresses. (Not that it makes it OK...)

Not explicitly, they might have been just using US data as an example in this blog post.

Even if they aren't, I still wonder that if they're checking everyones IP addresses against that database, essentially sharing our access of SO with a third-party, would it still be an inappropriate use of personally identifiable information?

It seems they're using data from a company called MaxMind https://www.maxmind.com/en/geoip2-isp-database#features .

Quoting their website, "The organization name is available for about 40% of corporate, government, and educational networks."

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.

It's not the IP address that's the problem, it's that they're processing personally identifiable information about their users in a way they haven't asked permission for and is not related to the service they're providing.

Here's the UK's ICO guidance for what you can process, as far as I can tell they've got no lawful basis for trying to match a user's IP address to a company without the user asking them to.

https://ico.org.uk/for-organisations/guide-to-the-general-da...

I skimmed that link and couldn't figure out what they mean by "processing". (It's related to compliance with a law, so I assume that the common sense meaning of a word isn't necessarily what is meant.) Do you understand what they mean by "processing" in this context?

It seems like you're saying that analyzing IP addresses a user connected from in order to determine their likely employer is against the UK's GDPR guidance, even if the data is released only in aggregate (but that it might be fine to keep that IP data since perhaps there are other uses for it which would be legitimate). Is that your understanding?

Since these provisions are most likely based on EU directives I would assume that this definition is also reflected in UK law:

> (b) 'processing of personal data' ('processing') shall mean any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction;

(Directive 95/46/EC)

All IPs are personal data (even if they are dynamicly assigned) if I read [1] correctly (Not a lawyer and there is most likely something I miss).

[1] http://curia.europa.eu/juris/celex.jsf?celex=62014CJ0582&lan...

It's not about what you release to the public, if you're processing this data in private it's still culpable.

This page gives it some context:

https://ico.org.uk/for-organisations/guide-to-the-general-da...

Further down are the 6 reasons for processing.

We know the first 5 don't apply:

    consent - there's no consent
    contract - it's not necessary to provide the Q&A answer site
    Legal obligation - there's no legal obligation
    Vital interests - nope
    Public task - nope

So what it falls under is "Legitimate interests", SO want to use a user's IP address, process it to add company name, store that and then use that data for profiling their customers to serve them ads.

One of the problems for SO is that further down they go into this a bit more and there's a few key questions:

    Would individuals expect this processing to take place?
    Are some of the individuals concerned likely to object?
    Are you able to stop the processing at any time on request?

Which I would think would be answer No, Yes, No. Which seems to indicate that there's some problems with SO's approach.

In skimming through the StackOverflow privacy statement it certainly appears that they disclose the collection of IP addresses and use of that information to report aggregated data ("we may publicly display information that is not personally identifying in the aggregate").

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.

> Stack Overflow Trends lets us examine how each of these technologies has been asked about over time.

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.

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.

> I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things.

While true, none of them have changed so quickly as JavaScript ones, which seem driven by devs eager to create portfolios on Github.

> which seem driven by devs eager to create portfolios on Github.

Is this supported by any facts? It seems like a hand-wavey hasty generalization.

The increasing trend of startups asking for Github accounts on their job offers.

You just need to search on job boards.

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!

io.js?

Yups. Nice one!

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?

IME Vue is so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official documentation.

You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...

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 ?

That could be the idea, but currently it seems Angular devs are more open to that idea, given that WebComponents are mostly driven by Google.

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.

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.

React's API is fairly small. Most of the code you're writing with React (outside of libraries) is based on ES6.

You can easily get by with someone that has years of Javascript experience instead, preferably a developer who's familiar with Functional-style JS.

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.

and don't eject until you really need to! CRA is fantastic and surprisingly extensible.

Right now I'm stuck working on getting SDKs installed.

I got my android app running which was easy after all the installs and updates.

Now I'm doing some weird command line stuff to try to get my Javascript server to wake up. Changing ports, more SDK updates, etc... Changing my App.js doesnt update, except if I turn everything off and back on again.

> 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 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.

Alternative hypothesis:

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.

Woah...

Was honestly surprised to see Vue.js was so tiny in comparison to Ang and React regarding "% of Stack Overflow questions that month".

I thought it was much bigger

Vue.js has a spectacular tutorial that answers most if not all questions one might have about the framework.

As much as it is praised in HN it is not that much adopted compared to Angular or React in the real world.

Good documentation and you did not need to ask so many questions.

You also have to take into consideration that the Vue community has the most Chinese devs of the JS SPA contenders and that might be reflected super well by SO data.

Maybe this should serve as a reminder that the HN bubble is not at all representative of the web development community at large nor it's membership a strong indicator of the community's sentiment.

Angular and react are used by more devs than Vue.

also keep in mind that Angular is complex enough to warrant 10x more questions. and React community, has done a lot of RnD in areas like flux, graphql, cssInJs etc. hence they too would have more questions.

Why are 'angular' and 'angular.js' seperate tags?

AngularJS refers to major version 1, Angular refers to 2.

Wow. That's really unintuitive.

I agree with the sentiment. Most people view them as distinct frameworks. I believe the use of the name Angular for major version 2+ helped retain a lot of users. I've seen a lot of uninformed devs and managers assume that because they already have so much code in AngularJS that Angular is the next logical tool for their team to use.

Presumably that reflects the 1.x / 2.x split. They're arguably different enough to be treated as separate frameworks.

Knockout isn't a Microsoft technology

The JavaScript/jQuery community (no difference from outside) was absolutely cancerous. It was impossible to find a javascript question that didn't include top answer "In jQuery...". Makes my blood boil just thinking about it years later.

I wonder what effect this has on usage. How likely are new developers to use it if virtually every question they have is answered by this (no matter how irrelevant the answer should be today).

To be fair, that's because the jQuery solution was usually orders of magnitude simpler. Although newer versions of javascript have absorbed enough of the jQuery api that this is no longer the case.

Acceptable way would be "Hey, it's done like this, but since the language sucks there's this random library where you can do it this way".

Including jQuery for one small task would be stupid.

Including jQuery in a non-web project would be weird.

Including jQuery in some es variants would be impossible.

At that time, javascript was used exclusively for client-side web development. It was pretty much impossible to write ajax requests in any sane fashion that worked cross-browser. It's not such a stretch to assume the user asking the question could use jQuery.

The first part is not true.

And while I agree with the second, I'm talking about general language questions not related to web in any way (no DOM manipulation, no http requests, etc..).

The contemporary equivalent, albeit one or a few steps up the abstraction ladder, is "how to get started with (javascript|frontend development)" guides — append "in 2018" for better SEO — which boil down to "use React".

Reply on news.ycombinator.com