protonimitate

For those that didn't read the thread - this is for the Svelte compiler, not the Svelte library. Users of Svelte will be unaffected and typedefs will still be available.

There's nothing in the article (if you read it) that tries to paint that narrative. As far as NYP goes, it's actually pretty mild and factual. I don't understand why so many commenters here are jumping at the chance to defend poor little Google from the evils of bad journalism.

Also how is > Maybe there is a real issue but two suicides within such large number of employees isn’t really significant.

NOT minimizing?

Suicide is tragic regardless of the circumstances, and it's a really bad take to try to minimize this because it's not statistically "significant" or "clickbait".

An employee of Google who jumped from the Google office is a pretty obvious connection. Don't really see how this is clickbait.

To me the more interesting question is: did Neanderthals value art?

Could argue all day about what is and isn't art and if they created artifacts that fit the definition, but what I'd really like to know is "did they appreciate things purely for aesthetics and cultural relevance, and not utility?"

Memoizing the callback prop only matters if you wrap the child component in "React.memo".

If you don't wrap the child component with "React.memo", every time the parent renders the child will render regardless of prop equality, even with memoized props/callbacks.

> Several thousand borrowers with older loans will also receive forgiveness through income-driven repayment (IDR) forgiveness, plus another 3.6 million borrowers will receive at least three years of additional credit toward IDR forgiveness, the Education Department said in a statement.

I think this is the actual news. Although it doesn't state what the selection process is.

Drawing on the Right Side of the Brain is the holy grail. I don't think you'll find a much better single "diy" resource. I don't think you need to follow it cover to cover, but it's a great reference resource to have and contains a lot of super valuable exercises and resources for drawing "the right way".

Honestly, I wouldn't spend money on instruction unless it's in person - drawing is ultimately about seeing and it's hard to instruct that online. Other tutorials/lessons tend to be about copying existing work rather than drawing from life, which is the foundation of all drawing/art skills.

Learn about the basic elements of art (line, shape, color, value, form, texture, and space) and the principles of design (balance, contrast, emphasis, movement, pattern, rhythm, unity) and look up exercises to practice them all.

Most people only care about "line" when drawing (forced perspective, outlining the subjects, etc). This is a trap. Think about "drawing through the object" (don't outline and then fill in later, etc) and utilizing all the other elements of art.

Draw still life setups/landscapes/people from real life. A lot. Do long drawing sessions (4+ hours with the same subject). Short time boxed ones (15 mins max, 30 mins max, etc). Draw the same setup every day for a week. Draw every day.

If you want to copy other works, start with copying drawings/sketches from the "masters".

If possible, find a group drawing class to get IRL feedback.

Once you do this for a year or two you should have a pretty good foundation for pretty much any drawing/painting discipline.

Ultimately it's about repeated practice. Make it a daily habit and you'll see big improvements.

Source: art school, drawing/painting for 15 years.

Same thing happened to me at my last company. I was over worked, wore too many hats, and was paid significantly less than my team mates who were more junior than I was (and had less responsibility). I had a handful of conversations that never amounted to anything. As soon as I put in my notice with a new offer in hand suddenly I was able to "set my price".

I left for other reasons as well, but it really shone a light on how management thought of ICs. Managers: proactively reward your ICs, don't wait until they're halfway out the door. I would honestly take a less aggressive adjustment in comp if it was done proactively, rather than waiting until I'm fed up and on my way out.

Yawn. Another "hot take" article that's really just pandering to the HN/"true hacker" crowd that romanticizes anything pre-Google. It's a pretty shallow article that just regurgitates the same old "money makes things evil" rhetoric and slams the big Z cause it's low hanging fruit.

I'd be much more interested in something that highlights or talks about what _is_ better about web 2.0 than meme-ing about "old web good, new web bad". This is just click bait dressed up as anti-establishment / edge-lord blog spam.

Admittedly I haven't followed Svelte super closely, but isn't "no JSX/TSX" kind of a major ideological point? From reading the intro docs, it seems like separation of js/css/html is a selling point. JSX/TSX would contradict that, no?

Just wondering if my read is correct or if there's some other reason it's been left off the table.

Also curious - I'm spinning up a small side project with Rust and Svelte. Was looking in Tauri as a replacement for Electron but wondering what other approaches people have worked with (assuming this is a cross platform desktop app, that is).

Most at home racks have "safety bars" that you can adjust to act as a safeguard from dropping weights.

The most dangerous for dropping weight imo are bench and squat, and both are easily mitigated with the bars adjust to the correct height.

Ex: https://www.garage-gyms.com/wp-content/uploads/2013/11/squat...

Huh, interesting. I've done this pretty much my whole (programming) career. As a non-traditional, I always felt it was a weakness to be "that guy", but it's good to know that it's a common tactic.

Luckily, I've always been around coworkers that never put me down for asking those questions.

Despite the Electron detractors, I do think it's a pretty powerful tool. In a lot of cases it's very un-optimized/bloated, but it has been proven to be very quick in some cases (vscode, etc).

In any case, even if Electron falls out of favor or doesn't continue improving - other's will take it's place. I believe "web on the desktop" is not going away any time soon.

Great advice here. A lot of people try to get fit instantly and it's a big horrible negative feedback loop.

One thing to add which helped me get into shape - pick one main goal in fitness. Want to lose weight? Focus on that. Want to build muscle Focus on that. What to run a marathon? Focus on that. It's really really hard to manage multiple (often, disparate) fitness goals at the same time.

Hint: "getting toned" is a trap! Generally you can either lose weight or build strength. While it's certainly possible to "re-comp" it's demoralizing (ime) because it is very slow and can lead to wheel spinning.

And yes, consistency is key. I personally fell into the trap of "go really hard, get burned out, hate the gym" early on in my fitness journey. Find a fitness routine that you actually look forward to doing every day / every other day. If you feel anxious about working out, something should be changed.

I get where you're coming from with the metaphor, but I see these types of comparisons a lot when talking about computing "fundamentals" and they've never really felt right to me.

Even though pilots may know the basics of lift and drag, they have abstractions over those things (tools, processes) to management. That really isn't any different than saying "I get what/why bit manipulation, but have never needed it".

Also - you _can_ learn fundamentals on the fly in software dev. Sure, not everyone has the drive to, but you can't reasonably google "how does lift/drag work" as a pilot who is flying the plane :)

For me burnout comes from the endless treadmill of external pressures (arbitrary deadlines, changing requirements) and the endless treadmill of development work. There's not really ever a chance to step back and take a breath - just constantly moving from one high priority task to the next.

It's also a bit thankless, being good as this job, in a lot of cases, means you are moving really fast from one task to the next without any down time in between. I find it hard to get to a place where I can feel accomplished or proud of a piece of work, because the next fire/high-priority task is already "behind schedule".

I think part of it may also be due to the fact that the job is constant problem solving. Even though its nice to find solutions to problems, knowing you'll be perpetually in a state of "there is a problem that must be fixed" is taxing on mental health (for me at least).

As a art-degree holder turned engineer - yup.

While there's a romantic vision of the starving artist, being broke is a whole different type of burnout.

I've been having a good experience with pnpm lately. It's not a silver bullet but it addresses some pain points with npm/yarn.

"at scale" here means # of contributors, not # of lines or scope of code base.

Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.

Maybe I worded that incorrectly - yes performance is important. But the negligible gains between framework x and framework y are not high on my evaluation checklist, as long as the minimum performance requirement is met (which is often dictated by the product requirements).

I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.

I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.

Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.

React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output.

Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).

That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.

I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.

I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.

Why not both? I can drink a chai latte in my PJs and "occasionally" work through-out the day and still be more productive than if I waste 3 hours a day on commuting and have to fight through constant noises and distractions in an office.

The one and only leetcode-esque interview question I even enjoyed was a pretty mild "easy" problem, where it was explicitly state that a solution was not the goal. The purpose was to simulate pair programming with the interviewer (who claimed they didn't know the solution off hand).

It was casual, conversational, and actually enjoyable.

I've personally never thought of Uber engineering as the pinnacle of contemporary engineering teams, is that a common sentiment for others? I know they're popular, but I thought it was mostly due to the pay scale / name recognition, not technical quality.

+1 for the grokking algorithms rec. It's a great summary/refresher/at-a-glance resource.

This is informative.

How is the configuration overhead? Is it relatively easy to get Vite + a custom react app template + tsx + testing up and running?

CRA is bloated, but still one of the fastest ways to get a "full app" up and running with React.

I really disagree with this point of view. I don't think anyone should feel indebted to their circumstance/employer just because there are others out there without the same opportunities.

Is it entitlement? Maybe. But isn't it also entitlement for companies to try to squeeze the maximum amount of productivity out of employees for the least amount of compensation? Why can't they see that there are less fortunate companies that can't afford to bring on the most productive workers?

If OP wants a low stakes job to coast to retirement in - more power to them. The only "issue" I see is if OP intentionally deceives their immediate team/coworkers and is off-loading their commitments while reaping the benefits.

> It goes completely against the idea of progress and works against any form of entrepreneurial spirit

Not everyone cares about these as values. Some people just want to have a decent life and spend time thinking about things other than work. I don't see why they should uphold these values just because others don't have the opportunity to.

I have a hard time wrapping my head around why companies are mandating 100% return to office.

Cost issues aside, I've always maintained that the absolute best experience is a hybrid/flexible schedule and location policy. I'm currently full time remote (I'm on the East Coast working for a West Coast company). My previous company had its main office in my current city, but allowed a super flexible choose-where-you-work-from policy. It was the best.

Didn't feel like dealing with the commute or had a ton of heads down work to do? Stay at home. Wanted to go in to be present for meetings? Easy. Start the day at the office and go home to finish off the day and avoid the commute? Sure.

Of course they made it possible by actively managing it. No meetings before 11am ET (to accomodate those in different TZs). Every scheduled meeting required a Zoom/conference link. Dedicated offices were set up as "conference rooms" so remote people could call in. And of course, people all the way up the ladder worked from home at least some of the time.

Being full remote doesn't work for everyone. Providing a space for those who want it is such a huge quality of life bonus imo. But the biggest factor is creating a culture of inclusion, despite your employees working preferences. This is the hardest thing to do, especially at scale.