I’m Joining LinkedIn
tomdale.net
tomdale.net
I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of.
> Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible, piece by piece, to your user’s browser.
I've been observing these trends for years and what I'm seeing is this: ever since these new thick client JS frameworks became so trendy, web performance has dramatically decreased, not increased.
This one-two combo punch of framework authors condescending their users as "our target audience is devs who can't hand code" while simultaneously promising performance that's just as good as hand coding and perpetually failing to deliver is a toxic stew that is crippling web performance.
This is distinct from a reuse library where you write the plumbing while someone else has written the details of some functionality.
Often you get these super-frameworks that do all the plumbing for you and throw in veritable kitchen sinks of reuse libraries with the intent that you glue it all together to match your business logic. Very frequently this is the stated aim of these super-frameworks -- reason only about your business logic and leave all the details to us.
It is a compelling story, but usually one that doesn't have a happy ending. The devil is in the details. Your business logic usually requires you to hack something that the framework/library authors didn't anticipate. That hack leads to 10 more as you route around the "it isn't supposed to be done this way, but what could we do" mess. Over time it degenerates.
Then you hire old guys like me who are willing to accept money to grind out all the problems without quitting in a huff and running to the new shiny ;-) (only because our legs are tired from running after shinies when we were young).
There are lots of reuse libraries and even minimal frameworks who specifically say, "You're going to have to wire this up yourself. We're not going to make it easy for you. That's because we can't anticipate the problems you will run into and we are trying to give you as much space as possible to figure out how it should be done".
I like frameworks and libraries like that. I don't like the other ones, even though they generally pay my salary.
And so we'd put another ad somewhere on the page to increase revenue, instead of decreasing the page load time down from 5-10 seconds with some truly trivial low-hanging fruit type adjustments (lazy-loading anything but the 'core' images, etc.). Or we'd do another redesign. Or add a widget somewhere.
What bothers me most is that these kinds of jobs were generally the highest paying and lowest in stress and 'friction' with the client. And I'd do them, telling myself that with the money I was 'saving up future time', all the while feeling incredibly depressed whenever I came home from work or had a moment to think about the current state of my life.
I always pitied the (shockingly high) number of employees in these companies, predominantly managers, who absolutely hated their jobs and constantly talked about 'one day I'll quit and do <x>' while never doing it because, well, the money and stability. Ever since I realized I was basically doing the vey same thing, I've been trying a little harder to find a balance between 'saving up'/stability and enjoying my day to day. And in my field that should be possible.
I know I'm guilty of this line of thinking so I'm not judging, but I also think many companies big and small are actually making rather rational decisions when it comes to site performance and the use of JS frameworks. For instance where I work its common for us to knowingly slow down performance on a given page because the feature makes the company X money that offsets the performance loss and the time and money it would take to make it perform better. This compounds over time, but all along the way the business is making reasonable decisions. Frameworks like Ember allow great developers to add powerful features quickly for the businesses to monetize on. I don't think we should write off performance initiatives in these frameworks just because we know they won't live up to a vanilla JS implementation. I also don't think its fair to disparage the movement of thick JS frameworks on these grounds. Many of start-up's and large companies wouldn't be able to lift off products as quickly as they have without the head starts that frameworks such as Ember have given them.
I'm not saying the big trendy thick client JS frameworks are the wrong tool for every job. But in my experience they do seem to be the wrong tool for an alarming number of jobs they are presently being used for. And I'm not just spitting rhetoric here. I'm more than happy to put my money where my mouth is. If you want to know specifically when I think a big thick client JS framework might be the right tool for the job and when it probably isn't, this article does a good job of outlining that: https://www.sitepoint.com/javascript-dependency-backlash-myt...
As for the tradeoff associated with developer productivity vs. performance, there is some validity to that. However, I think people overestimate the developer productivity gains the frameworks offer. You only get productivity gains if your whole team is already fully trained on the framework. And in addition to the performance tradeoffs, you also risk your codebase having a shorter lifespan because the framework may make breaking changes to its API some day (e.g. Angular 1 -> Angular 2), whereas a vanilla JS implementation that relies on smaller, single purpose JS libraries will age considerably better.
Google would go bankrupt from a combination of the insane salaries they'd have to pay and the inability to ever fill jobs if its entire stack was based on Haskell.
Many frameworks deeply affect how the code is written and have very specific boilerplate, custom templating and such. And some frameworks simply offer means of doing some things in an easier, usually specific, way with the relevant language.
In my experience it is also highly relevant how your thoughts on architecture match up to the framework's. I'd say you can happen to have a solid affinity for the way a framework is thought out. But in general, I'd agree, overnight is generally not sufficient for anything proper :)
My point was that unless you're a small startup with very specific need for the tech stack you're using, you probably shouldn't be hiring based on whether the candidate knows certain framework, because that can be learned quickly, as long as the developer has solid foundation.
Before trying React/Redux, I was against js frameworks too. They all seemed to add a whole extra layer of unnecessary mutable state to keep in sync, and required lots of cruft and duplication. Just give me coffeescript, underscore, and jquery, thank you very much. I composed nice little modular components that latched on to server-generated html, kept state to a minimum, and used a global event bus to deal with interdependence. It had some warts, but it got the job done and scaled up reasonably well. It certainly beat procedural jquery spaghetti and I thought it beat the current crop of frameworks too--what it lacked in polish, community, and standardization were made up for by modularity and simplicity.
Of course, then I discovered React, and more recently, Redux. I immediately realized that it was the culmination of what I'd been trying to do all along. It was basically the same idea, but battle-tested, standardized, and infinitely more elegant. So why wouldn't I use it? Sure, there was a learning curve while I got used to other people's way of thinking about and expressing these concepts. Rather than designing the system myself and knowing it like the back of my hand, I had to learn a whole new vocabulary and toolchain. But it was so, so worth it in the end. I'm still building apps with an architecture I believe in, and I get all the benefits of a well-supported framework to boot.
So, to finally get back to the central point: never once was popularity an important factor in my decisions, and I suspect this is also the case for many many others who adopt one framework or another. Not everything that's popular is only popular due to a bandwagon effect--sometimes the shiny new thing really is a big step forward.
I am in the Emberjs community, I do not observe this in that framework.
It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.
FWIW this is generally common knowledge within the webdev community. People debate whether or not it's a problem, not whether or not it's happening.
> I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of
Sometimes even when you can, you shouldn't. Any reasonably-sized organisation will have churn; new developers will have to ramp-up and it will take longer to do so on a hand-coded framework with all it's idiosyncrasies. I'll take Ember over Random Jim's framework, even though he is technically brilliant.
I was on your side for a long time, but I've come to appreciate a minimalist, simple, well documented in-house framework over a hype-driven "solve-all-the-thing" one, even free and with a currently big community.
> I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of.
I am also skeptical, but for a slightly different reason.
I believe the original statement from the article is true today.
I also believe things would be very different if the same web developers we have today spent less time learning new frameworks every five minutes and more time learning the fundamentals of the underlying technologies (JS, HTTP, and so on), broader skills like programming and UI design, and more professional practices like standardisation and backward and forward compatibility.
So many tools in web development today are merely papering over the cracks that other tools unwittingly created in the first place. The advocacy of using these kinds of tools to be more future-proof or standardised than building with solid fundamentals is one of the greatest ironies in programming history.
No one likes it and it takes over 20 minutes to "build" the code from scratch.
We're talking about frontend code, mind you.
At a certain level in LinkedIn, someone decided to standardize on Ember. Fine. But there were many issues, and instead of finding a more suitable and workable pragmatic framework, LinkedIn is instead deciding to hire Ember people to fix up their framework so it's actually useable. We really do work in the only industry where you can get hired to fix a mess you created yourself.
Anyway, besides the recruiter app, is LinkedIn really worthy of a SPA experience? Last time I checked isn't most of the traffic a quick "accept connection" or reply to inmail, or maybe check who viewed your profile bounce? Does the average user actually spend time in it? Probably not.
I'm reminded by a certain quote from a friend: "At a certain level in McDonald's, the managers start thinking of themselves as restaurateurs, and not fast food servants."
The people who are talking publicly seem very excited about how things are going. Chris Thoburn (runspired) was on Ember Weekend a few weeks ago talking about the work he's doing on Ember Data over at LinkedIn.
P.S. I never took any jobs from that platform.
* They steal the address book of any user who installs their app, collecting private information of people who have given no such consent
* They then proceed to create shadow profiles of all those people that haven't registered, creating the illusion that more people are on LinkedIn than really are (not sure if they still do this)
* They then start spamming all those contacts with multiple emails per day, for several days, asking them to register with LinkedIn. There is no "fuck off and stop emailing me" button, the only way to make it stop is to register for an account
I've blacklisted linkedin.com in my mailservers for this reason. And I would agree with the GP that they are scum and that working there lowers my opinion of a person.
From now on I will only use my personal network and services I have more respect, like SO Jobs, if I have a need for new opportunities.
I use the site but I'm deeply skeptical of the way their business tactics appear in my interactions with the site.
Edit: I would probably meet them for an interview to get a feeling for the company and team, but as a company they start on the minus side for me.
It used to take a huge amount of time to initialize a repository as well, but they recently switched to Yarn and that helped a lot.
I'm planning on leaving because as parent says, it's been a disaster from start to finish. Developer tooling does not help you be productive, the app performance is quite poor, and it's just not enjoyable to work on.
In some cases it makes sense, but very few websites really need to be SPAs yet everyone these days is using React, Angular, Ember, etc.
Facebook created React to not depend on other frameworks. They also added HTML and CSS into JS because their application is huge and complex. At their size it makes sense to have all the bits needed to work on something in the same place. Redux, same thing. It's a solution that is intended to solve problems at the 1B users scale.
The truth is 99.99% of web applications won't come close to that level of complexity, but devs insist in using solutions React and Redux because... hype? It's like driving with a school bus to carry 1 person. Dan Abramov has said himself that it doesn't make sense to use Redux until you need it.
Same thing with all those JS UI benchmarks. There must be a use case for rendering and doing data binding in 10000 UI elements at 60 fps, but those are very rare edge cases.
I'm guilty of this myself. I've spent 2016 working with React on a few SPAs and I have to admit I only got in it or the hype. Everyone was doing it which must mean it's the best way to go, right? Wrong.
I'm moving away from SPAs in 2017. Going back the classic route of generating dynamic HTML in the server and sprinkle pages with JS "widgets" whenever I REALLY need those UI enhancements.
If I need an SPA for a particular use case, sure I'll do it, but not as a default option.
Edit: In mobile SPAs makes even less sense. Sure you may be reducing requests, eventually, but the CPU usage is bigger and the initial load is also bigger. And sure, you can really optimise an SPA but this adds complexity on top of complexity.
Sites like HN and Reddit have proven that content is king.
No, I don't want the android app. Stop asking me.
Stop directing me to my home page when I clicked a link to go deep into the site.
And please stop showing that spinner for unlimited time.
Also, these may be back end issues but both the desktop and mobile web sites fail to update the notification indicators after you've responded to friend requests or read your feed.
They must think of themselves as Facebook Messenger, which most people check with obsession, or at least aspire to become that.
Is it because an app-user is a much richer data slave?
Airbnb are also relentless for pushing users to their app even though the app is an inferior product to their website.
I'm sure he's not unaware of those things. I wonder if he's thinking he may be able to influence them? Discourage dark patterns? Discourage the current mobile experience that's broken unless you download the app and/or log in?
This person probably just wants to work on interesting things (for them) and get paid well, just like the thousands of employees at the other companies I mentioned. Fighting for ethical software doesn't pay. Nor does it make one particularly popular.
What? 200k/year is a lot of money and a norm in these companies. With 10 years of such money, I can retire for life.
This in of itself may be enough to encourage him (it would be me, if I were interested in his line of work particularly). In essence, dark patterns drive short term profits at the expense of long-term value creation.
In the past as in last month, when I got one yet ANOTHER of those endless "I'd like to add you to my professional network on LinkedIn" spams?
As in last year, when LinkedIn's site was hacked and 6.5 million passwords dropped on the Internet, yet according to Vice, "LinkedIn never clarified how many users were affected by that breach" (turns out, about 18 times the reported number)
https://motherboard.vice.com/read/another-day-another-hack-1...
Or do you mean the last few years, as when LinkedIn paid a (paltry) $13 million to settle a lawsuit claiming they damaged people's reputations from their irritating emails and deceptive practices?
http://time.com/4062519/linkedn-spam-settlement/ http://www.mirror.co.uk/news/technology-science/technology/l...
Do you really think all of LinkedIn's members were fully aware their contact list was being harvested and had knowledge and consented to that list being used for spamming? Clearly not.
IMO, LinkedIn's only positive contribution to the world is making it easier to spy on spies: https://icwatch.transparencytoolkit.org/
Another thing to bear in mind is that ember is more or less an independent technology, whereas Angular and React have the weight of giant corporations behind them.
I've been writing native (or python) stuff for a long while, and I've come to rely on the assumptions the code makes being roughly constant (from the point of view of the language definition.)
My brain recoils at the idea of targeting a large number of different systems at once, like browsers and their versions, and then have the same code run on the huge set of future versions...
If your code behaves differently under a new GCC, it indicates a bug in your code. If your javascript behaves differently in the latest Chrome, that's just life.
Great, I'm glad Ember is gaining more traction in enterprise... but what does this mean for things like Fastboot, Ember 3.0, glimmer 2.0, ember-cli 3.0, and the whole cast of in-room-elephants such as ember-redux, flexi, ember-data, vr, etc.?
Isn't Ember mostly used in enterprise?
Source: I'm the lead eng for our consumer group
My personal conclusion: LinkedIn is a lame duck. The previous owners sold it at the right moment to Microsoft.
- Glimmer 2: Shipped
- Ember/CLI 3.x: Haven't heard anything, but there's not really any features that have been pushed to those versions that I know of. Glimmer 2 was the big roadblock for routable components, which is the feature we're most waiting for.
- Ember Redux: Was not particularly liked by a lot of the core team (from an API perspective), but the ideas it represented were. They're exploring ways to implement this in Ember.
- Ember Data: LinkedIn hired "runspired" and tasked him with improving Ember Data performance. His work will ship with the next version (last version had his initial work which revolved mostly around tooling)
- Flexi: Was never really a core Ember project, and I don't think it was widely adopted. It was a runspired thing, and I think he's being kept busy on other stuff (core projects and smoke & mirrors)
I don't use fastboot so I can't comment there, but I see new versions coming out regularly. I also don't know what "vr" refers to.
There are plenty of available consumer of good tools, with more coming into the market every day. We need more specialists. Every person has the same capacity, the same brain, the same capability to become an Einstein, a Hoare, a Dijkstra, a whatever modern Comp Sci figure or AI leader you admire these days.
I firmly agree with your point here; we need more people of all kinds. Specialists, generalists, communicators, community organizers, all of it. Since this is an ember thread, I'll link to Yehuda: https://twitter.com/wycats/status/675498087717056512
God, I wish this were true, but it definitely isn't. We're trained to think it is, by virtue of (first) our belief in meritocracy (it's value, and that we're in one), and (second) by RPGs and other games.
Our baseline cultural assumption is that things are, in the end, fairly balanced... but this just isn't the case.
I think it's demonstrable via the existing of evolution: There have to be differences between individuals on an inheritable level in order for evolution to occur, and if there are such differences, the playing field is NOT even.
I was expecting our western values rooted in the belief that all men are created equal or something.
I really don't think RPGs and other games have somehow conditioned us (the niche market that even plays them) to think we're capable of anything, but I quit WoW a long time ago.
Note that the statement isn't "we need more people who can write segfault free C/C++ code" - the assertion is that there aren't any of them, that no specialists can do that.
Some leeway could me made around that statement. People who work in fishing and agricultural industries for example could benefit from unique and specially crafted services when it comes to job search and fulfillment. There is a certain effectiveness in the one-size-fits-all approach of applications like Facebook but it could stand to exist within a more diverse ecosystem.
What do you mean? Who needs the leeway?
(I suspect "artisanal, shade-grown code" just means "bad", but perhaps stated in a more PR-friendly way.)
> People who work in fishing and agricultural[...]
What are you talking about?
I've known several people who work in fishing (fish farming, specifically), and I can assure you that they weren't particularly concerned about "job search" or "fulfillment". They were concerned about maximizing profit amidst the intense competition.
Can you relate what your fish-worker acquaintances/friends told you?
(I mean, I don't necessarily disagree with your position, I just don't think you should try to support it with entirely fictitious examples.)
In any case congrats on the new gig Tom.
Ember.js had many strong parts, but also had many issues that pulled it down. Documentation overfocused on explaining concepts but not providing examples of how to solve real issues. New release every six weeks bringing painful deprecations and changes. Lack of realworld apps to look up to for examples. Ember-Data that worked out the box... unless you weren't using Rails for your backend, in which case you've needed bridges and drivers for it to work. Rich of resources assuming that your backend is Rails or that you have enough of understaing about it to translate examples for your tech. All of this eventually pushed me away to React.js that seemed less opiniated about your backend and richer in examples and manuals, as well as unopiniated enough to forgive my mistakes and let me lear from them. Since moving I've made a lot of mistakes with my own solution build using React.js and libs from its ecosystem, which eventually made me understand design choices behind Ember.js, but I still preffer to improve on what I have now instead of considering returning to Ember.js.
I've only worked on a few SPA's in the past years and every single one of them had some unique fundamental demands that led to some equally unique and fundamental differences in how the app was built.
Maybe I'm just not creative enough, but I find it difficult to come up with one Rails-size solution that would've been useful for all of these apps.
On the other hand, I remember when Rails took off, it seemed like an obvious batteries-included solution to a whole set of rather typical CRUD websites.
Few random thoughts of things that make SPA's less 'standardized' and perhaps, at this time, less likely to benefit from Rails-size frameworks:
- with SPA's you often have to work with the back-end that is provided to you. That's usually not an issue with Rails. - since the significant logic is now client-side (routing, etc), you have a large number of possible ways to synchronize server-side routing with client-side routing. - code size is an issue, so in some cases choosing a simpler solution for one part of the stack is necessary, plus for anything big you need to deal with code splitting and all that this entails. - performance is an issue so we can't just re-render the entire page. React and similar solutions have been one of the best improvements in this regard and take out a bunch of complexity (but add some of their own). With a non-SPA solution this is just not an issue. - browser compatibility is still an issue. With an SPA solution you need to consider all the same stuff as with a non-SPA framework, but now you also have to deal with things like javascript version support, event handling inconsistencies, local storage, animations, multiple forms of interaction (slide, drag&drop, etc.), loading indicators and potentially a whole bunch of async stuff.
But perhaps most fundamentally: in a 'typical' Rails setup, the basic form of interaction is basically url -> page. It's turning one string into a bigger string. But in a typical SPA, there are tons of different types of interactions that lead to tons of different results. Any interaction with the page can mean: change state, send or retrieve something to or from server, save something in a cookie, go to a different page, load a different piece of content without changing the route, load content and animate to it (so simply navigating to a different route is not enough), and that's just off the top of my head.
And you generally still need some kind of back-end on top of that with its own complexities and odd ways of interacting with your client-side code.
For example, ember-redux exists to take the functional centralized state-management of redux that makes react great and ports it to ember. Similarly, react-scripts takes the developer-ease of ember-cli and gives it to react. Everybody uses the DDAU for handling DOM interaction, shadow-dom-tree-diffing (or whatever it's called) for rendering, some sort of declarative remote data-layer in both ember-data and redux-orm (and there's even ember-redux-orm), and junk like animation-handling and whatnot all expose the same change-attribute-yield-block API to the programmer.
If you look beyond the stylistic difference of things like writing jsx v. hbs, there's actually very little philosophical difference between modern 2.x ember and modern react
That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.
Regardless, I've bet on Ember both at my company and personally because I think they've done a lot of things right and their community process sets them up to continue on that track. As long as the community and innovation continues, I don't think it matters if React keyword searches are 20x Ember's.
It definitely matters, it's a huge deal: popularity > usage > superior ecosystem > jobs > repeat
It quietly sits in the back, takes what it can get from other frameworks and attempts to innovate on them (see FastBoot vs. the mess that is server-rendered React) while enjoying a smaller but lively community.
For example, the Ember NYC meetup is a lot better than any React NYC one I've been to in terms of community and quality.
Do they just hire good JavaScript developers and train them for Ember? And also tell them they may have to retrain in another framework in a couple of years when Ember becomes defunct?
The good thing is that if a company is as big as LinkedIn they could probably maintain the framework on their own if it gets out of favor. Of course they could also directly start a new one for their internal use, but it's questionable if this would get any better than the existing ones.
I don't really get why you're talking as if thick client web apps are some sort of unexplored continent that prudent enterprises should stay away from. Like it or lump it, they've been around for a while and there are now enough of them that they will be around for a long while yet. And if you're going to build one of those, you should use a framework.
There is really not a whole lot of Ember-specific training you need to go through. A good JavaScript developer would just have to read through the guides once to grasp its concepts.
I like how as technologists we talk about "betting" on things. As if technology choices are like gambles.
If there are two competing technologies, generally one will dominate, or more likely: both will be replaced by something new. You have to gamble that the technology you pick will stay relevant for long enough to be worth it.
Instead I believe choosing the right software platform is predominantly a game of skill and experience.
Remember that old canard, "a poor craftsperson blames their tools"; the corollary is that a good craftsperson chooses good tools.
A good craftsman can rationally choose tool A over tool B, however, for software platforms it is a major gamble whether A v2 will still be preferable to B v2 - it is (a) unknown, not decided by A being "better" than B, and (b) generally outside of your control.
In software tool/platform/protocol/standards selection, the person making the choice is a direct participant in the game, can control the local (and possibly global) quality of the outcome, and has (or should have) a priori knowledge of the characteristics and context that will shape the future viability of their choice.
Sometimes that requires a really deep dive into technical documentation and/or source code; sometimes it means assessing product origins, or the community/ecosystem around it; sometimes it means looking for warning signs (e.g. patent encumbrance, a toxic vendor, unnecessary interoperability barriers, opaque licensing or pricing); it almost always means understanding the values & norms & preferences of the people who'll be bound by your choice. Usually a combination of all these things and more.
The argument that we can't tell, in advance, doesn't wash with me; it is not borne out by my experience of being either the decision maker or decision victim, and just sounds like an excuse for a bad decision and/or poor execution.
What happens later is people saying "I made a bet and lost", a terrible post-mortem that smacks of denial, and one I've heard all too often. But whenever I've make a wrong call - and I've made plenty over the years - there was always, always, always some factor that I missed. Whenever I've made a decision that turned out really well, it has always been on the back of research and analysis and reasoning, possibly (and increasingly with experience) guided by gut feeling. "I made a mistake, what can I learn from it?" is the only hindsight I tolerate for myself and strongly encourage in others, and it is not compatible with framing decision-making as a gamble.
And this is the global market.
Imagine how worse it is if you want to hire local. Yikes.
The pool of engineers who are experienced with your stack will be bigger if you pick a "winning" or "popular" stack. But in my experience at Big Co, the stack is as often proprietary as not, yet Big Co can attract talent anyway.
Having lived through transitions from Popular Stack Today to Popular Stack Next more than once, I have yet to go through the experience thinking that the upgrade path is easy.
Proto-jQuery to jQuery, jQuery to Backbone, Backbone to Angular, Angular to React, React to other React-like things... these frameworks were all "winners," but I can't describe the upgrade path without using the word "rewrite."
Ember is a good framework with a lot of potential, but more than anything it needs a good PM. Ember devs just spent nearly 14 months rewriting the layout engine (Glimmer 2.0) that they had spent the prior 8 months writing (Glimmer). And what do they have to show for it? A 100ms or so speed boost on complex views. Instead they should focus on fixing up the crufty parts of their API and adding feature they've been promising users for years. Instead Tom Dale has been off writing FastBoot, an even more niche component of Ember that very few apps will even use.
React and Angular are far from perfect, but one upside is they have parent companies to help keep them focused.
I think that since LinkedIn is "all in" on Ember it will help to get some of the cruft removed and things moving forward. LinkedIn has probably the largest and most complex Ember app in existence, so there are a lot of learnings to take an use to improve the framework and ecosystem.
Basically when 2.0 landed, routable components couldn't be worked on until glimmer components were completed. Angle brackets, Improved Pods, etc, same.
So even if it wasn't under dev that whole time, it held back other features that would have really improved Ember.
Ember has always dwarfed by Angular and now more recently.. React. They simply have more marketing dollars behind them. That said, it has always had a strong community behind it, and believe it or not it's still growing strong.
I could be wrong. Edit: typos
If Dale Said it otherwise, im sorry. Its all about opinions Here :-/
fiatjaf is literally saying[0]:
> React cane out after Ember, and conquered the hearts of many many JS developers. Why couldn't Tom Dale be one of them?
And it's fine to wonder that, but he states it in the original comment as if it's a definite thing without providing a source.
Can you elaborate on this? I'm unfamiliar with Tom Dale and Ember so I'm admittedly ignorant, but it's not clear to me why he would think "something like React is better than Ember in all situations".
In any case, I think it's most likely that A) they are throwing a boatload of money at him, more than he could probably get anywhere else and B) giving him full autonomy to continue his desired work in a context where he has direct access to a lot of the hairiest problems.
Open source work is not known to be the most lucrative, so opportunities like this are very attractive, I really can't fault him for it.
Parent is saying React is so clearly better that even Tom Dale knows it.
(I'm merely translating ... not stating any opinion of my own here).
I don't see how you don't consider this hypothese. React cane out after Ember, and conquered the hearts of many many JS developers. Why couldn't Tom Dale be one of them?
1. React and Ember are different things, one is a framework, the other is not.
2. Ember 2.0 was a backwards compatible evolution of 1.0 that shifted the approach from MVC (old state of the art) to a more components based approach (similar to React in concept, not in implementation). Tom Dale was instrumental in making this happen, he didn't just ship v1 then proceeded to use React while doing some sad Ember support on the sidelines.
3. Why would he be one of them? Angular 1.x was the best thing for many JS developers, yet React came along. Why wouldn't the React developers just love Angular 1? There's a possibility that React will loose popularity to another solution.
4. Popularity is one potential indicator of how good a solution is. Despite it's popularity, many seasoned JS developers heavily disliked Angular 1.x because it felt like an overengineered-java-like-approach to building web apps. There are many seasoned JS programmers who are moving away from React to other solutions (Angular 2, Ember) because they have other pain points now, than 2 years ago. For example, Tom Dale once told me that he doesn't like redux as a solution for keeping the entire app state - yet Redux is all the rave now in Reactland.
5. JS (similar to PHP) has huge numbers of junior developers that can't build a web app on their own yet are working inside teams and are, in various degrees, competent at doing specific tasks. Almost all of the junior developers I know have heard of React and want to work with it despite not having the least understanding of what problems it solves and what problems it adds.