
I’m Joining LinkedIn - joeyespo
http://tomdale.net/2017/01/im-joining-linkedin/
======
kethinov
> Perhaps you can write a tiny web app that loads instantly and still retains
> a full set of features, but most of the world cannot.

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.

~~~
lcw
As software developers I think its easy for us to jump on this bandwagon that
if you hand code all the things then you can make a super fast site and the
internet would be such a wonderful place; and then thinking its all those
heathen script kiddies using these junk JS frameworks slowing our browsers
down.

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.

~~~
kethinov
The bandwagoning is disproportionately on the side of those leaning towards
big frameworks. Look, I've been on the inside of large companies making
framework choices and rarely is the decision rational. Often it's based on
what's popular and based on the assumption that popular things are popular for
good reasons. Biased metrics get thrown around to justify preconceived
notions, and off to the races we go. Years later, everyone sees the old stack
as "old and outdated" and a strong desire to throw it all away and rewrite it
with the new hotness takes hold. Then the entire irrational process repeats
itself.

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...](https://www.sitepoint.com/javascript-dependency-
backlash-myth-busting-progressive-enhancement/)

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.

~~~
addicted
Large companies almost by definition need to hire a lot of developers. Seems
to me that it would be an absolutely rational and sensible choice to use
popular frameworks keeping those constraints in mind.

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.

~~~
Ar-Curunir
Probably not; people would just learn Haskell.

~~~
sjg007
And that would be so amazingly beautiful.

------
iamleppert
The ember roll out within LinkedIn has been a disaster from those I know still
working there.

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

~~~
luketheobscure
I can't imagine where that 20 minutes number came from. Maybe a fresh `git
clone && npm install && bower install && ember start`... But even then that
seems very high (and somewhat irrelevant since subsequent builds will take
seconds). Citation needed?

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.

~~~
cocktailpeanuts
if you count all the jenkins task with automated unit tests and integration
tests, etc. this is pretty believable. It happens all the time.

------
nissimk
Does this mean I can expect improvements in the mobile web app? It has so many
issues that I won't click the links on my phone.

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.

~~~
timonovici
Oh, you're preaching to the choir. They're the worst. By far, the worst mobile
experience, and by far the most aggressive push for their mobile app. I choose
not to open their mail on my mobile phone. And obviously I don't want their
mobile app.

They must think of themselves as Facebook Messenger, which most people check
with obsession, or at least aspire to become that.

~~~
yomly
What's the reason for this?

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.

~~~
DerpyBaby123
Exactly that. The tripadvisor experience is also bad, they block all but 5
reviews from their mobile site to push users to their app

------
tyingq
Lots of flagged comments, I suppose because of short quips related to the
sleazy things LinkedIn has done in the past.

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?

~~~
blub
LinkedIn's behavior is driven by profit. They want advertising money and are
willing to sacrifice their users for that, just like Google, Facebook and more
recently Microsoft, which happens to own LinkedIn.

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.

~~~
tyingq
I think there is a line where it makes sense to speak up. Short term revenue
isn't always worth the long term reputation hit.

~~~
newsat13
> Short term revenue isn't always worth the long term reputation hit.

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.

------
neom
Regardless of web tech, Tom is an awesome dude and Linkedin is lucky to have
him. ^5

~~~
fergie
I kind of agree with this. Saw him give a presentation a few years ago, and
was very impressed (and entertained). Tried out ember after that, and quickly
found some dead ends for my use case, but hey- at least he actually got out of
bed and made something.

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.

------
tehwalrus
Some of the discussions on this thread remind me why I'm pleased I don't work
on code for browsers.

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.

------
ffn
> Joining LinkedIn

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

~~~
joshhart
The mobile-web version of LinkedIn and the new website are built in Ember. We
already use Glimmer 2.0 because we care about web performance. So we care
deeply about many of the things you mentioned.

Source: I'm the lead eng for our consumer group

~~~
smartbit
Just out of curiosity I logged into the mobile site. First I was greeted with
"your browser is not supported". After I logged in, I found a website full of
nonsense news, mixed with advertisements. Not a place I would go to for any
meaningful reason.

My personal conclusion: LinkedIn is a lame duck. The previous owners sold it
at the right moment to Microsoft.

------
treehau5
We need specialists too. We need the folks who can tune x86 assembly better
than -gcc 03. We need people who can write segfault free C++ code, and we need
people to fix the Rust borrow checker bugs
[http://blog.ezyang.com/2013/12/two-bugs-in-the-borrow-
checke...](http://blog.ezyang.com/2013/12/two-bugs-in-the-borrow-checker-
every-rust-developer-should-know-about/)

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.

~~~
RangerScience
> Every person has the same capacity, the same brain, the same capability to
> become an Einstein

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.

~~~
ctvo
> ... and (second) by RPGs and other games.

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.

~~~
RangerScience
I really think they have. RPGs may be niche, but games aren't, and there's an
expectation of balance between player positions in games; even across the
equipment load-outs. There's expectations that you trade, say, fire power for
precision; resilience for mobility; and that the trade is equitable.

------
sekou
> artisanal, shade-grown code doesn’t scale to large engineering organizations

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.

~~~
lomnakkus
> Some leeway could me made around that statement.

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?

~~~
WillEngler
I thought "artisanal, shade-grown code" was such a delightful phrase. I took
it to mean not bad, but rather too costly for practical/mass use. Like some
people can afford to buy $6 lattes, and those are likely very tasty lattes,
but Folgers is going to move more beans.

~~~
lomnakkus
It's an amazing phrase. AFAICT it doesn't actually mean anything. I certainly
_understand_ why such a high-profile developer would choose such a "bland, yet
poetic" phrasing; my issue is just with trying to interpret it as somehow
insightful.

~~~
zem
it pretty clearly meant "code that has been lovingly handcrafted to the
specifications of the problem", as opposed to "churned out using a mass-
production framework". the analogy works for me.

------
WhitneyLand
Is this concerning?
[https://www.google.com/trends/explore?q=ember.js,react.js](https://www.google.com/trends/explore?q=ember.js,react.js)

In any case congrats on the new gig Tom.

~~~
Ralfp
I've moved from Ember to React year back. Then over year I've (crappily)
recreated Ember.js using React.js and libraries.

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.

~~~
orf
I agree with your points about documentation and release cadence (they do have
a LTS release now though), but we've used ember-data with a Django backend
since day one and it's been flawless in every respect. Once you configure it
there are no issues

------
jamies888888
Who signs off moving huge, billion dollar companies onto immature, "hip"
JavaScript frameworks? I don't get it. It's too niche. It's too risky. How are
you expected to make hires for specialists in such a niche technology which
may or may not be here in a few years?

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?

~~~
tragic
Was it too hip, niche, etc to use Spring for a Java project in 2007? Because
that's how old Ember is now.

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

------
Bahamut
This makes a lot of sense - LinkedIn has basically went almost all in (if not
all in) on Ember. Being probably the biggest tech company relying so heavily
on Ember, it's unsurprising that they want a core maintainer of it on board.

~~~
cozuya
Just curious but what happened to Dust? Is it still a thing with them?

~~~
zackthehuman
It is still a thing. (Source: I work there.)

------
mwcampbell
It seems to me that the true analogue of gcc -O3 for web apps is the Google
Closure Compiler in advanced mode. How effectively can Ember applications take
advantage of this?

------
dkarapetyan
> LinkedIn has bet big on Ember.

I like how as technologists we talk about "betting" on things. As if
technology choices are like gambles.

~~~
daurnimator
Aren't they?

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.

~~~
komali2
But if it works, how is it a gamble?

~~~
mateo411
You are choosing an outcome which you think will happen in the future. It is
not certain that this outcome will happen.

~~~
inopinatus
I think a gamble needs to be predominantly a game of chance. Merely having an
outcome that isn't certain would cause any choice to be labelled a "gamble",
from crossing the road to turning on the kettle.

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.

~~~
PeterisP
Sports betting is one of the most ancient and most popular form of gambling,
even while the actual games are, as you say, games of skill and experience.

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.

~~~
inopinatus
In sports betting, the gambler has no control over the parameters or the
outcome of the game. Indeed when they do it is considered match fixing and may
be illegal.

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.

------
mkrishnan
Ember is a great framework and equally as powerful and popular like angular or
react. yet its developed by just a bunch of guys on their free time unlike
other frameworks which had huge enterprise support. I hope tom leverages the
linkedin support and take ember to next level.

------
jit_hacker
LOL. I love how full of his own crap Tom Dale has become.

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.

~~~
zackthehuman
Having worked on Glimmer 2 myself, I don't think it's accurate to say that
Ember devs worked on it for 14 months (that is, it took 14 months of work to
same 100ms). It had initial work done for a long time and then it sat for a
while unchanged because it's an open-source project that people work on when
they have time. Month later work started up again to get it out the door.

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.

~~~
jit_hacker
Well the Glimmer 2.0 effort started around the same time Ember 2.0 shipped
(Aug 2015). That was 16 months ago, Glimmer 2.0 shipped about 2 months ago,
ergo 14 months. I agree that it wasn't under development the entire time, but
it was a blocker for many other features the entire time.

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.

------
amorphid
Maybe you can help fix their new search UI. As a power user, I find it
basically unusable. For me, that was the final nail in the proverbial coffin
of usability. It is so bad AND slow.

------
r0m4n0
Interesting they made that bet on Ember... My only assumption is they made
that bet a few years ago and have been working on the refresh that just went
live. Seasoned Ember developers are going to be hard to come by not that they
couldn't settle for any other JavaScript specialist. I'm debating on an Ember
gig this very moment and am slightly bothered by the idea of spending a year
on a framework that is on a downward popularity trend...

~~~
1945
> downward popularity trend

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.

~~~
mercer
Marketing dollars?

~~~
andreime
Meaning: Ember doesn't have a big company actively spending money on
marketing, like Angular - Google and React - Facebook.

------
javascript-this
As long as companies continue to value maintainability over efficiency you're
going to have slow sites.

------
hillz
First I thought this was Jim Dale - the amazing narrator of Harry Potter - and
was pretty confused.

------
fiatjaf
So Tom Dale is one of the creators of Ember. Now he is joining LinkedIn to
work with Ember. I think this is a little sad. I can't stop imagining that he
thinks that something like React is better than Ember in all situations, but
since he has such high Ember credentials and somehow LinkedIn decided to go
with Ember then he feels he must accept that job.

~~~
aosaigh
Huh? Why would you think that?

~~~
darfs
I think here we have the "my tooling/programming language is the best, in
every situation everytime".

I could be wrong. Edit: typos

~~~
citruspi
Yeah, but fiatjaf is saying that Tom Dale (one of the creators of Ember.js)
believes that React is better than Ember in every scenario, not the opposite.
That's the part that doesn't make sense.

~~~
darfs
I think it's about he thinks that Dale believes. And thats based on the
opinion that React is the best in everything that Ember could do..

If Dale Said it otherwise, im sorry. Its all about opinions Here :-/

~~~
citruspi
Yeah, but the point is that he's conjecturing and doesn't provide any source.
If anything, I'd imagine Tom Dale believes that Ember is better than React in
some, if not all, ways given that he's... one of the co-founders.

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.

[0]:
[https://news.ycombinator.com/item?id=13325643](https://news.ycombinator.com/item?id=13325643)

