Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I’m Joining LinkedIn

tomdale.net

Post reply on HN
Print view View original

161–170 of 172 posts

Re: I’m Joining LinkedIn

#161

Post by iamleppert »

luketheobscure wrote: post #111
iamleppert wrote: post #109

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 de…

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…

I can't give you a direct citation, sadly. And this is just one anecdote, there are many others on how this choice of framework has actually contributed to losses of productivity, the exact opposite of what its supposed to do, I assume?

Re: I’m Joining LinkedIn

#162

Post by biznizcat »

iamleppert wrote: post #109

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 de…

I have worked on the Ember apps since the beginning of the project. It easily takes 20 minutes to start a server up. At its worst it took me maybe 35 minutes-- enough time to come to work, start the server, go have breakfast. Add in that the server crashes a couple times a day and I lose ten hours a week from tooling.

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.

Re: I’m Joining LinkedIn

#163

Post by kethinov »

zackthehuman wrote: post #155
kethinov wrote: post #100

Earlier quoted context omitted.

Well I have observed it. I've worked on many projects that used one of the big frameworks (including Ember.js projects) that would've been better off with vanilla JS and a collection of small JS libraries instead. I'm not going to name names, but they're out there. It's a tool that does get misused, like any other.

Recent releases of Ember actually reduced the output size (sometimes in the high double-digit percent) and Glimmer 2 improved rendering performance. Sometimes the needle moves back after work internal to the framework.

Yep. And to play devil's advocate for a moment, I've really been impressed with fastboot too. I think it's a great idea. Overall things are certainly heading in the right direction, but I just wish we hand't sunk so low from a performance and robustness (progressive enhancement) standpoint first.

Re: I’m Joining LinkedIn

#164

Post by kethinov »

stupidcar wrote: post #123
kethinov wrote: post #51

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

Purely anecdotal. Got any statistics to back up your opinions?

If you google for stats on the average size of webpages these days, you can see a bunch of studies people have done which show the average file size of website page loads is increasing. Images are the biggest offender, but JS bloat is a significant factor as well.

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.

Re: I’m Joining LinkedIn

#165

Post by PeterisP »

treehau5 wrote: post #14

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

"We need people who can write segfault free C++ code" is wishful thinking - as our experience with software vulnerabilities show, even the very best engineers carefully writing and reviewing small security focused code do occasionally get buffer overflows.

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.

Re: I’m Joining LinkedIn

#166

Post by PeterisP »

inopinatus wrote: post #45
mateo411 wrote: post #34

Earlier quoted context omitted.

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

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 ch…

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.

Re: I’m Joining LinkedIn

#167

Post by pier25 »

iamleppert wrote: post #109

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 de…

> Anyway, besides the recruiter app, is LinkedIn really worthy of a SPA experience?

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.

Re: I’m Joining LinkedIn

#168

Post by KurtMueller »

pier25 wrote: post #167
iamleppert wrote: post #109

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 de…

> Anyway, besides the recruiter app, is LinkedIn really worthy of a SPA experience? 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 t…

React and redux don't have to be a part of a SPA. You can have server-rendered pages with some react-based widgets on them. I think react and redux is great for that kind of stuff - I know I enjoy building widgets using react and redux as opposed to jQuery.

Re: I’m Joining LinkedIn

#169

Post by KurtMueller »

pier25 wrote: post #167
iamleppert wrote: post #109

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 de…

> Anyway, besides the recruiter app, is LinkedIn really worthy of a SPA experience? 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 t…

React and redux don't have to be a part of a SPA. You can have server-rendered pages with some react-based widgets on them. I think react and redux is great for that kind of stuff - I know I enjoy building widgets using react and redux as opposed to jQuery.

Re: I’m Joining LinkedIn

#170

Post by inopinatus »

PeterisP wrote: post #166
inopinatus wrote: post #45

Earlier quoted context omitted.

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 ch…

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.

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.

Post reply on HN