I’m Joining LinkedIn(tomdale.net)
tomdale.net
I’m Joining LinkedIn
http://tomdale.net/2017/01/im-joining-linkedin/
171 comments
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.
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.
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...
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.
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.
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.
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.
Probably not; people would just learn Haskell.
And that would be so amazingly beautiful.
Google will hire people who can write good vanilla JS code, not someone who's good at the latest fad js framework. In fact, if you're good at writing vanilla JS, you would probably pick up these frameworks overnight.
Pickup a framework overnight results in shoehorning your current knowledge into the framework and late night rants about how the framework sucks.
It was a figure of speech! :)
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.
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.
I'd say it depends on the framework a lot.
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 :)
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 :)
I plead guilty
People focus on frameworks and popularity, but as someone who builds a lot of complex front ends, what really matters to me is architecture--architectural simplicity and architectural scalability.
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.
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 think your points have some weight to them. Specifically I 100% agree that JS frameworks are at times misused, and in lots of situations are completely unnecessary. However, my point is the valid use cases for these JS frameworks warrant the open source investment that many community members are pouring into them.
That I completely agree with. And to be clear, while I disagree with some of what Tom Dale says sometimes, he's a very talented guy. LinkedIn is lucky to get him and I think it's entirely a good thing to see another prominent open source project get some corporate support.
I think we see many here pump up their abilities that they could homebrew an excellent implementation of [insert special feature] better than [insert framework/library]. Truth is, I don't trust most software engineers to do that without a vetting of some sorts, and open source software provides that. I consider myself pretty good, having done some serious open source work in the frontend world, but if I had to homebrew a framework like React and all of the pieces to make it work (or Angular, even with my intricate knowledge of it), I would not be able to match everything with performance, flexibility, and good API signatures. Most developers are not experienced with thinking about all 3 factors in tandem, and it shows with the code that is written on a typical basis.
Unfortunately a lot of us in HN make our living writing thick clients that ultimately perform worse than server-rendered apps with little benefit. It's just too easy to find a front end dev job that pays well, at least where I live.
Maybe you should find any of the websites that profit from faster load times and argue the business value. Because that's most of the places.
I've suggested just that at multiple companies, and even if the business value was acknowledged, the usual (informal) response boiled down to "it won't impress my boss as much as new feature <x>, and there's no reason for me to argue with them about this".
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.
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.
From my pov : welcome to the fact that a huge part of the web still is handled by tons of never finished perl script and old Js stuff, that had to scale and evolve despite noone making it scale and evolve.
It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.
It is closer to that. We got a ton of new things, but never the budget nor time to go fix the old thing.
>> 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
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'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.
Thing is, by the time you have to take back this application for maintenance, chances are high that the then mainstream framework will be outdated, newcomers won't even know it, the doc will have vanished in a poor "let's move to this new shiny TLD", and still the business logic of the application will be vastly undocumented as well.
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 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 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.
I am in the Emberjs community, I do not observe this in that framework.
I am in the Emberjs community, I do not observe this in that framework.
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.
Yeah! It feels like we are in the 90s again! Where you got flash videos but only a 54k connection. It is not faster...At all. just. slower and slower..
>> 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.
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.
> 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.
Which frameworks claim to target "devs who can't hand code"?
To a certain extent all of them do. "devs who can't code" is hyperbole, but the whole point of a framework is to provide a framework that allows you to fill in the details without building all the plumbing underneath.
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.
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.
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.
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.
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."
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."
LinkedIn tried to hire me to help with their SaltStack infrastructure several years ago when they were first rolling it out/beefing up their infra with it and I emphatically said no. Even if I like working with the technology I would never work somewhere like LinkedIn, they are scum and working there lowers my opinion of a person.
Out of interest, why are they scum? Never heard this before about LinkedIn.
Where to start?
* 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.
* 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.
After writing my own comment and reading the others in this thread, I actually realized I gain nothing from LinkedIn and deleted my account.
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.
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.
Literally just received an unsolicited LinkedIn email as I was reading your comment :(
I would assume it is related to their widespread use of dark UI patterns and general attempts to get your to share e-mail-addresses of everyone you've ever communicated with. Constant badgering with new types of notification emails and generally strange user-hostility.
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.
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.
I don't know are they really scum, but also for me the platform is mostly clueless headhunter bots offering Ruby positions even without reading my CV. Ok, I know it's nice that we have headhunters banging our doors, but when you like to do things properly yourself, you kind of expect the same from the headhunters.
P.S. I never took any jobs from that platform.
P.S. I never took any jobs from that platform.
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.
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.
if you count all the jenkins task with automated unit tests and integration tests, etc. this is pretty believable. It happens all the time.
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?
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.
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.
> 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.
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.
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.
In that case why not use something more lightweight such as Vue?
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.
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.
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.
They must think of themselves as Facebook Messenger, which most people check with obsession, or at least aspire to become that.
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.
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.
Exactly that. The tripadvisor experience is also bad, they block all but 5 reviews from their mobile site to push users to their app
I agree, it really is a terrible experience. If I've received a notification from a service, I want near instantaneous response. The whole waiting-for-more-than-3-minutes to load business is disturbing to me.
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?
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?
Sleazy things in the past?
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/
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/
For some reason Linkedin spams me a little less, or maybe the reason is that I unsubscribed from their spam, although I don't remember the last time I logged into linkedin
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.
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.
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.
> 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.
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.
[deleted]
He's probably thinking that past sleazy behavior was driven by a need for revenue. The Microsoft purchase changes that. MS needs to protect it's reputation more than it needs revenue from Linkedin.
Microsoft paid 26 Billion for Linkedin. I'm pretty sure they expect to extract revenue out of them.
They paid for the largest professional social graph in existence. That is inherent value they can use to strengthen their own product line (or "synergy" or whatever term they've been using).
If Microsoft felt it needs to protect its reputation, our industry wouldn't
have the Windows 10 calamity (user tracking, advertising built into the very
OS, and unsolicited auto-update to Win10).
> Discourage dark patterns?
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.
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.
My somewhat cynical guess is they threw an insane offer his way. A man has to eat, and Linkedin has been heavily recruiting for its Ember.js bet. Tom Dale is a big name in Ember.
And he's also going to be able to get all that while contributing to the community he loves. No company is perfect and it's easy to see how you can explain those things away.
[deleted]
[deleted]
Regardless of web tech, Tom is an awesome dude and Linkedin is lucky to have him. ^5
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.
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.
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.
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.
> 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.?
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.?
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
Source: I'm the lead eng for our consumer group
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.
My personal conclusion: LinkedIn is a lame duck. The previous owners sold it at the right moment to Microsoft.
> I'm glad Ember is gaining more traction in enterprise
Isn't Ember mostly used in enterprise?
Isn't Ember mostly used in enterprise?
Apple Music was built in Ember for example.
http://builtwithember.io/featured/2015/07/04/apple-music/
http://builtwithember.io/featured/2015/07/04/apple-music/
I don't think there's any "in-room elephants":
- 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.
- 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.
Fastboot is still being actively worked on. Glimmer 2 is used in production by LinkedIn and others, and they continue to work on it with other Ember contributors. In fact, almost all of the things you listed are still being worked on by their respective contributors and I can confirm because I know this first-hand.
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, 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.
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.
> 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.
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.
> ... 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.
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.
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.
(note for those playing along at home: both of those "bugs" come down to the same issue, which is lexical vs non-lexical analysis. That post was written in 2013, but adding the non-lexical feature has taken quite a long time, requiring a huge refactor to the compiler internally. We're just now getting to the point where the feature could actually be worked on directly.)
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
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
Advanced tools act as force multipliers for specialists, allowing them to focus on just their specialty and execute it even better & more efficiently e.g. instead of having to hand optimise large swathes of a program, -O3 does a good-enough job for most things, allowing the specialist to spend even more time on the small number of super-hot tight loops.
"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.
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.
> 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.
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.
> 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?
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 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.
This is what I took it to mean. It wouldn't be horrible if Starbucks was the only option for coffee, but take away all the small cafes and you miss out on a lot. There may be some trouble with that analogy but the idea is there's value in specialization.
I think it's referencing middle-out compression.
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.
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.
I don't know how technology can best help people in different places make money and find the work they want. I think the author is saying that economies of scale helps bigger companies deliver better products and services, but I think moving forward on the other end by enabling the development of specialized software can also be beneficial. In fact by continuing to work on Ember I think the author is actually doing this.
So what were you doing with that whole "fishing" bit?
(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.)
(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.)
Is this concerning?
https://www.google.com/trends/explore?q=ember.js,react.js
In any case congrats on the new gig Tom.
In any case congrats on the new gig Tom.
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.
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 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
Maybe the front-end (SPA) ecosystem, both in terms of technology and use-cases, just isn't stable enough for a Rails-type framework?
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.
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.
Honestly, though, Tomster v. electrons-circling-nucleus branding aside, both ember and react are currently experiencing a lot of community-driven convergence in core philosophy.
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
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
Nitpick: Redux-ORM is _only_ about managing relational data in normalized form locally. (Technically, it's not even Redux-specific - you can hand it any plain JS object to work with.) It doesn't do any remote requests or syncing.
That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.
That said, it's a great abstraction for handling relational data, and I'm a huge fan of it.
Ember has never been the trendiest and hottest framework.
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.
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.
I think a more accurate comparison is this: https://www.google.com/trends/explore?q=ember%20javascript,r...
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.
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.
>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 definitely matters, it's a huge deal: popularity > usage > superior ecosystem > jobs > repeat
Probably not for the same reason this isn't concerning:
https://www.google.com/trends/explore?q=vue.js,react.js
https://www.google.com/trends/explore?q=vue.js,react.js
Ooooh I like this game! How about now?
https://www.google.com/trends/explore?q=ember%20js,react%20j...
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?
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?
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.
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.
I'm not into Ember and have no clue how it compares to the other SPA frameworks. But from these political point of view it doesn't look worse than the others. React and Angular might die or change in an unsuitable way even sooner since they are driven by other big companies for their own merits. Maybe extjs or aurelia might be different, since they are maintained by companies which earn their money through this.
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.
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.
> Do they just hire good JavaScript developers and train them for Ember?
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.
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.
Ember has been around for a while now, isn't that hip and very stable for a JS framework.
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.
It's not "a" core maintainer. LinkedIn now has 4 (out of 13) Ember core members on board.
Just curious but what happened to Dust? Is it still a thing with them?
It is still a thing. (Source: I work there.)
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?
> LinkedIn has bet big on Ember.
I like how as technologists we talk about "betting" on things. As if technology choices are like gambles.
I like how as technologists we talk about "betting" on things. As if technology choices are like gambles.
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.
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.
My point is that's a broken attitude. I think Alan Kay likes to say software is a pop science and in pop science you bet on stuff because there are no other indicators of importance other than popularity.
But if it works, how is it a gamble?
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 chooses good tools.
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.
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.
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.
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.
Technology is often a moving target, particular when it's end-user facing. You're betting that your choices will allow you to keep moving with that target, rather than get left behind by the latest browser release, iOS release, Android release, etc. etc.
It's a choice between multiple (all workable) options. The "gamble" is about how well-supported (&c) those options will be in the future.
Or you can just allocate your resources so that you're permanently safe with your choice.
Given the fact of uncertainty about the future, investing in anything (e.g., building applications using a particular framework) is a gamble. Granted, the ability to re-write is a good hedge, but you're still hedging a bet.
They are bets. In the global market if you pick the wrong tool you severely limit your talent pool and upgrade path. Imagine being stuck on Marionette and Backbone these days. Tough to attract talent with old technology like that.
And this is the global market.
Imagine how worse it is if you want to hire local. Yikes.
And this is the global market.
Imagine how worse it is if you want to hire local. Yikes.
I hear this mentality a lot, but I wonder how true it is in practice.
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."
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."
That is not a bet. Choosing the wrong tool and blaming one's failure on "chance", on "losing a bet", is a classic case of denial. A smarter thing to say is "I made a mistake", and learn from it rather than denying it.
Depends on what you're doing besides 'growing'.
[deleted]
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.
[deleted]
[deleted]
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.
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.
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.
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.
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.
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.
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.
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...
> 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.
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.
As long as companies continue to value maintainability over efficiency you're going to have slow sites.
[deleted]
First I thought this was Jim Dale - the amazing narrator of Harry Potter - and was pretty confused.
[deleted]
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.
Is there a typo here? Why would he think React is better than Ember?
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.
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.
I can't stop imagining that he thinks that something like React is better than Ember in all situations
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".
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".
Huh? Why would you think that?
I think here we have the "my tooling/programming language is the best, in every situation everytime".
I could be wrong. Edit: typos
I could be wrong. Edit: typos
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.
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 :-/
If Dale Said it otherwise, im sorry. Its all about opinions Here :-/
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
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
[deleted]
I think what the parent is saying is that the parent likes to play this imaginary story in his head, and in this story, Tom Dale actually thinks React is better but can't work on it because he is known as a core contributor to Ember.
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).
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).
Clarifying: I was just imagining, I wasn't asserting that the he thinks React is better.
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?
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?
Making assumptions like this is a dangerous habit.
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.
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.
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.