As an engineer, I want to believe this, but really - does it?
Most folks use frameworks because it's easier than learning how to build it all yourself - things are done for you instead. This niche is now getting eroded by AI and low-code substantially.
Couple that with my experience maintaining frontends that are far too complex for their use cases - e.g. do we really need SPA's, state sync, and reusable components for our admin tool that doesn't reuse components?
This leads me to think there's been bloat here for at least a decade. So, while vibe coding will also lead to bloat, it's easier to work with, and arguably higher value than paying for a specific framework.
It's a tragedy in life that things that are useful don't always get valued, instead being used as a stepping stone for progress, but I'm not sure that has a solution.
I've been exploring decentralized trust algorithms lately, and so reading this was nice. I've a similar intuition - for every advance in scraping detection, scrapers will learn too, and so it's an ongoing war of mutations, but no real victor.
The internet has seen success with social media content moderation and so it seems natural enough that an application could exist for web traffic itself. Hosts being able to "downvote" malicious traffic, and some sort of decay mechanism given IP's recycling. This exists in a basic sense with known TOR exit nodes and known AWS, GCP IP's, etc.
That said, we probably don't have the right building blocks yet, IP's are too ephemeral, yet anything more identity-bound is a little too authoritarian IMO. Further, querying something for every request is probably too heavy.
- Like you mentioned, it helps me learn more about a topic/explore it more deeply, I usually begin with an intuition and then explore outwards.
- Folks positively mention my articles - both current connections and new connections.
- They sometimes spark interesting discussion which helps refine my knowledge further.
> What kinds of posts actually worked (for learning, career, network, opportunities)?
- Hard to say, I don't have a high signal here. Usually just having some content for people to skim was enough, but folks would tend to mention nearly random articles depending on their interests.
> Any practical format that lowers the bar (length, cadence, themes)?
- I'm not a great blogger in that I have no established cadence. I didn't want pressure to deliver crap (biweekly), nor did I want necessarily to put posts on too high of a pedestal (monthly+).
> If you were starting today, what would you do differently?
- Highly recommend going with simple tech. A static site based on Markdown does wonders. Offload discussion threads to sites like HN or reddit - the comment section of your links.
Good question, was on my mind too. The problem I could see is Walmart style - the predator will beat the prices of the non-predator down until the non-predator goes out of business, then raise their prices again.
They can do this because they are operating in other areas with predatory prices, giving them the ability to operate at a loss, and relying on the fact that at least some of those areas are not being challenged by non-predators.
Everybody seems to be playing the game right in this scenario. Interesting to try to come up with a good counter.
Does this actually happen? If a community opened up a co-op shop that started eating into the revenue of a dollar store, would the dollar store company try to fight back, or would they just exit that market?
Yes, I guess well capitalize companies could offer unrealistically low prices, but on the other hand, any kind of co-op or community driven organization has the benefit of not needing the margins. Dollar store investors are there to make a buck, if their capital isn't getting reasonable returns will ultimately exit the business and move somewhere else.
Cooperatives do not get rid of the net negative cycle. Ultimately whatever the benevolent entity ends up being, it becomes a contest of who can bear to lose more money.
Cooperatives distribute the losses but it is still a money pit.
Builders once disrupted the tech world, but now they’re the gatekeepers. As their success made them risk-averse, they see any change as a threat.
Today, they’re bullies - ripe for disruption.
This is nothing new - we’ve watched this same story play out across many industries in our lifetime, as well as by empires rising and falling throughout our history.
These days, the empires may be smaller - e.g. products, teams, startups - but the pattern is still the same. If every move needs a meeting and every idea a committee, you’re not short on talent, you’re just tangled in control.
Here's three ways I've found to break out of this:
Cycle Leadership: To avoid entrenched thinking, cycle leadership between projects. This demonstrates both upward mobility as well as the idea that growth is continuous, and nobody is ever done.
Institutionalize Experimentation: Embrace the “how might we” mentality to continuously experiment and iterate. Form hypotheses and find the lowest cost way to validate them.
Subordinate to Metrics: Rather than following people, follow metrics - the measures that prove you’re moving in the right direction. This shifts teams from control towards collaboration, based on a set of values shared by both the market and the team.
As they say, in life the only constant is change. How is your organization tackling it? Are your teams builders, or bullies? I'd love to hear about your challenges and solutions.
It's uncontroversial that with high traffic websites these sort of frameworks are necessary, but the decision to use React is much more commonly being applied at tiny companies as the new "right way" of building things.
What is unclear is what you lose by not using React. This is similar to how trendy MEAN was back around a decade - "it's web scale", etc...
This gets into necessary versus unnecessary complexity, which is nuanced. But the large scale companies get this, and are doing just fine handling it. It's the small ones that can't draw the distinction. Discourse on these sites or articles is much more likely to matter to these smaller companies, and so in general the best "universal advice" is probably to recommend the simplest thing that doesn't close any doors.
The trouble is this calculus is being done at the local level despite the mantle of responsibility of management; the manager decides it is not worth their personal effort to lose a low performer, because they will generate more work for themselves. Meanwhile, the company suffers the net negative impact of such a decision - arguably even worse for the manager's career.
That's the main challenge I have coaching management folks - now you have the option of doing work, and often you'll be tempted to take the path of least resistance, but that'll usually lead you astray.
Edited to add - sorry I missed your net negative comment - to touch on that, as it's another thing I see often.. Giving up on the org's ability to satisfy your needs is another toxic pattern for management - it is a lose/lose essentially. Management is often in a position of needing to push for the things it needs and advocate for the people relying on them.
Most folks use frameworks because it's easier than learning how to build it all yourself - things are done for you instead. This niche is now getting eroded by AI and low-code substantially.
Couple that with my experience maintaining frontends that are far too complex for their use cases - e.g. do we really need SPA's, state sync, and reusable components for our admin tool that doesn't reuse components?
This leads me to think there's been bloat here for at least a decade. So, while vibe coding will also lead to bloat, it's easier to work with, and arguably higher value than paying for a specific framework.
It's a tragedy in life that things that are useful don't always get valued, instead being used as a stepping stone for progress, but I'm not sure that has a solution.