lllr_finger

That's what happened originally. Then bigger and bigger ad deals came in, then you needed more tracking to sell better deals.

The current revenue model is completely at odds with performance. If you're an established media company you can't just bail on principle and give up millions in revenue, unfortunately.

The problem is that they did see it clearly in the short term, and more ads and tracking always provided considerably more revenue. If Outbrain offers you $1M to be put on your site but it slows page load by 500ms on average, you put Outbrain on your site because there's no easy way to quantify how bad 500ms is to a userbase of 100M.

It sucks, and is part of the reason I changed industries.

I worked for a media conglomerate for several years on several high volume media sites. The GMs and POs that I came across often had a great sense for what made user experiences great, but those would take a back seat every single time for revenue opportunities. A company wants to do an ad takeover for the sites and slather sidebars/banners/popups everywhere, Ad Ops wants to sell a new module in the right rail, Outbrain/Taboola/whatever wants to pay you to throw their script and "suggested" stories at the bottom of the page - of course you jump at the chance to do any of these because the revenue can easily be in the hundreds of thousands or even millions.

Every time an AMP thread comes up, there is a minority being positive and trying to find a way to make it work, and it's for the reasons mentioned above. Apple and Facebook want walled gardens where they control the content and give the providers whatever revenue they consider "fair", with the huge benefit that the stories would be fast to load and provide a friendly, uniform interface. AMP is the only reasonable alternative I've seen pitched since RSS has essentially died.

I think she was close to figuring out what can happen, but missed the mark. Great developers leaving are your canaries, and the Dead Sea Effect is a real thing. So what do rules and processes have to do with this?

I'm currently happiest at my job that is the most "enterprisey" and has more rules. I can't wear shorts or sandals to work, which perpetually irritates me. I can't run the OS I want at work, and I have a hard time getting simple things like a decently sized monitor because of esoteric rules. A lot of these rules are dumb, and sound like the ones in the article, but I'm planning on staying for as long as I'm challenged and having fun.

Our team runs kanban instead of scrum/sprints, and we're constantly asking to use non-approved technologies (where appropriate) in a traditionally Java-based company. We have individual and team agency, and there is an implied trust that we will prioritize accordingly, get things done, and make good technology decisions. I would gladly deal with a dozen other dumb rules as long as I'm able to hold onto the above, as interesting work and agency to solve it in creative ways is the number one thing I'm looking for.

Contrast that with some of the other places I've worked. I used to be able to drink beer at work, we could have dogs in the office, I had more vacation time, free beverages and snacks, etc. All those things are nice perks, but they came tethered with what I consider the detestable processes that the article glosses over.

Any process related to productivity is designed to set a bar which will bring up your lower performing individuals. This bar will drag down your good developers - that is what makes good developers leave. Knowing how to fix problems and being unable to do anything about it while stuck in an endless barrage of sprint planning, sprint retros, forced demos, velocity tracking, etc. is not fun. Forced consensus on any decisions is like pulling teeth and people end up afraid to contribute or have a dissenting opinion.

The people that are OK with the productivity bar are the ones that stick around for 15 years and become "indispensable" because they know where the bodies are hidden. Anyone good that joins the company probably won't last more than 18 months.

I apologize for the long rant, but it's been a topic I've spent a great deal thinking about in the last 2 years after trying (and eventually succeeding) to find a good place to work.

Thank you for taking the initiative and time to do this. I'm excited to dig into both the wm and the compositor and try porting them for fun, as I'm sure others will.

In theory, this sounds great, and I am a huge proponent of functional programming. In practice, I've never seen it intuitive or useful.

I've been at 3 companies now where "time travel" has never been used and web app development has been more painful than it needed to be.

It feels very much like the proper (from a CS perspective) approach, but the language and libraries just aren't there to make it feel productive or fun. Is there any meaningful work being done to address this, or is it perhaps a boiling frog scenario?

Is it? Concurrent connection handling at scale is a major problem, and plenty of Fortune 1000 companies would jump at the chance to have even 5% fewer instances deployed.

366 rps in a test scenario doesn't scratch the surface of what I need, and I'm not doing anything I'd consider crazy scale. When you need to support hundreds of thousands of rps, small improvements can be very noticeable.

To play devil's advocate, a software craftsperson would ideally use the right tools for the job. You could fire up Groovy and Spring for a REST API that essentially takes JSON from a source/sources, transforms, and returns... but there are easier languages and frameworks and much more performant ones.

The developers I've met with this argument have usually been doing one stack for many years and don't want to do anything new or uncomfortable. It's like watching someone try to cut brush with a butter knife.

I consider Tealium doubly in the wrong here since the appeal to some orgs is that their tag manager allows BizDev/AdOps types to include scripts on sites without answering to product owners and developers.

AMP achieved this, for better or worse - the only script allowed on the page is AMP common library and approved plugins. I wonder if the Google CDN was removed from the equation if it would have been more embraced.

Unless you're looking at the Mamiya or Hasselblad MF lenses, good 35mm lenses tend to out-resolve MF and definitely LF. Projection circle is only part of the effective resolution.

Netflix's circuit breaking OSS project, Hystrix, is commonly seen alongside Ratpack/rxjava where both reactive streams and back pressure are in play. I don't think you're wrong, but Netflix and others using their solutions like Hystrix and Hollow, are outside of what I'd consider "usual" problems and solutions.

This is my first thought as well. It costs a lot of time and money to interview and hire - I do my best to not waste candidates time, and I hope for the same consideration on the other side of the table. Been at two startups and two enterprises and have worked with dozens of great devs who wouldn't respond this way.

If I came across this in the wild, I'd reevaluate the parts of the interview I control to see if maybe I could make it less robotic and I'd probably still bring them in to make sure I'm not missing a good dev, but I would be fighting my bias at least a little. There is a small handful of people I've worked with before that would appreciate this approach and their toxic attitudes would prevent me from wanting to work with them again.

The interview process can suck, but this is not how I'd recommend standing out from the herd.

It's not a technical problem at all, and it's not the developers being bad.

If the top 1000ish sites can make millions a year from tacking on Outbrain, Taboola, etc. and the analytics to support those revenue streams, why do they care if the page speed is 3 seconds vs 500ms?

Wrestling fans can be broadly defined as "marks" who buy into the illusion, and smart marks who understand the illusion and how it relates to business.

Arguably the largest part of this illusion "kayfabe" has been dead for years and years - everyone knows wins and losses are predetermined. That doesn't stop promotions from using wrestling news and social media to blur the lines of what's real and fake when it comes to contracts, injuries, and alliances.

Besides uncached views (I'm guessing a decent amount of the traffic from HN for this submission would be) you also have to consider parse/eval time. Look at the flame charts in Chrome Dev tools for some of your favorite sites and probably see a few that take almost a second to parse/eval cached JavaScript. It will be even slower for mobile users.

Just because it can be cached doesn't mean it's free or even necessary.

If a site gets 100m unique in a month they will be at the very top. They can then choose to provide a fast site, or slap on a bunch of analytics, tracking, and 3rd party bloat that provides business intelligence and millions in revenue - while staying ranked at the top.

They get to have their cake and eat it too, and there was no incentive (before AMP) to reign that in.

What's the right way then? When I worked at a media conglomerate, AMP was the only thing that reigned in and enraged the biz-dev and ad-ops departments. I'm still proud that my AMP launch partner pages are out there and serving up content really fast. I hate that it took this to provide that experience, but I prefer it to the FB and AAPL walled garden syndication approach for business and tech reasons.

I was at a top 1000 site and the senior product manager offered free dinner to be the first team to hit certain metrics (like pagespeed). He knew 100/100 wasn't useful but the difference between 50 and 90 for us was fairly significant. Are you chasing a number or what the number means? The latter is a good thing.

To each their own - I tend to agree with OP. My takeaway was rather close to "goroutines and gofmt are good" which are about two of the most obvious talking points when looking at Golang. Shallow has a bit of a negative connotation, but I was personally left feeling hungry for a deeper analysis after reading that.

> Nobody is forcing you to use redux, you don't need it

This is hand-waving to deflect Redux from legit criticisms, and is part of the reason I find both responses frustrating and unnecessarily dismissive.

You need to build your own framework for React SPAs because they're intentionally un-opinionated about the pieces you use. Just look at the scaffolding in place for create react app and all the various libraries. I would much rather solve real problems than discuss how to get Immutable to play nicely with Typescript or argue thinks vs. middleware.

"Get good" is a poor response to anyone wanting to see the wildly used/discussed state management solution for React get better, and implies that there aren't good devs out there with experience outside of JavaScript saying there is a better way.

You're right though - there are choices. I didn't like how the JavaScript ecosystem was progressing so I made a choice to not deal with it anymore professionally and it's been a very rewarding career change.

And this attitude is equally frustrating. Tools and libraries exist to save developers time. The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code, especially if you don't have pragmatic and decisive leadership on your team.

I buy them for anyone in my family that "just wants a laptop to browse the web", as they are fast, secure, cheap, and easy - with great battery life.

Typing systems for dynamic languages shouldn't be viewed as crutches for the inexperienced dev - experienced devs should seek them out when the ROI is there.

If any level of your tech stack offers you guarantees, use them so that you have less code to write. Less code is less opportunity for bugs and faster development.

Even the best models commonly available will only operate at a 3km resolution, which realistically isn't that much more useful than a 10km or 20km grid for ageostrophic winds (wind not affected by the ground). A model might show you have 8kt winds out of the SSE, but things like water, treelines, hills, etc. could have a large impact on a golf ball.

It'd be easy enough to look at the forecast for a 3km model like the HRRR, but the challenging part would be guessing at how the various features on a course interact with that forecast.

Immutability, and consequently determinism, are wonderful traits to embrace when you're managing deployments across environments and regions for dozens or hundreds of services.

You're obviously passionate about this; I'd personally be interested in seeing some more concrete points detailing exactly why this is bad.

In reality, they get scared of losing traffic by not adapting AMP, decide to implement it, and then flip out over how restrictive it is without understanding how they caused this situation.

It's all driven by money, and unfortunately AMP and bloated pages make money - fast, sexy pages without AMP do not.

As long as you're aware that this may not happen if your org is experiencing Dead Sea Effect. Having just gone through this situation, it can be challenging to understand when you're bitter and when you really are surrounded by less-than-ideal developers. Imposter Syndrome complicates this, as well.

That last sentence succintly describes my primary issue with front end developing, and why I'm starting a new job in a few weeks that is almost purely backend.

Most of my recent web work has been trying to manage shared libs and duct taping the build process together. Every feature branch has major shrinkwrap merge conflicts because there is so much module churn.