Live data from Hacker News

I’m Joining LinkedIn

tomdale.net

91–100 of 172 posts

Re: I’m Joining LinkedIn

#91
post #35

Is this concerning? https://www.google.com/trends/explore?q=ember.js,react.js In any case congrats on the new gig Tom.

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

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.

Re: I’m Joining LinkedIn

#92

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. > Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible…

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.

Re: I’m Joining LinkedIn

#93
post #67
post #42

Earlier quoted context omitted.

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.

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

plz stop talking, k thnkz

Re: I’m Joining LinkedIn

#94
post #89
post #73

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.

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

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

Re: I’m Joining LinkedIn

#95
post #72

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. > Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible…

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

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.

Re: I’m Joining LinkedIn

#96
post #26

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

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.

Re: I’m Joining LinkedIn

#97

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. > Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible…

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

Re: I’m Joining LinkedIn

#98
post #72

Earlier quoted context omitted.

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

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

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.

Re: I’m Joining LinkedIn

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

Re: I’m Joining LinkedIn

#100

> Perhaps you can write a tiny web app that loads instantly and still retains a full set of features, but most of the world cannot. I've long been skeptical of this line of thinking emanating from major thick client JS framework authors. I think they underestimate what people are capable of. > Over time, Ember will become like gcc -O3 for web apps, intelligently optimizing them and delivering them as fast as possible…

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

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.
Post reply on HN