nickdandakis

Here to say that I have been working on a canvas-based app for a while now. Canvas apps are hard y'all!

I greatly appreciate tldraw and think the licensing changes are completely reasonable. The team is highly responsive on Discord, and looking forward to the company nailing down the nuances of pricing out this specific business model.

Pricing is difficult as it is, open source pricing double so, open source canvas library pricing has got to be one helluva hard problem to solve.

I would like to see more improvements to the sync portion, specifically more granular authorization controls.

I actually wish Mozilla put out a dedicated password manager.

They have Sync, and they have SoPS (or well, used to?).

I'd gladly pay extra for it

Analytics should just be one point to weigh across others when making a decision. I don't fully think it's a binary decision to use it or not.

Consider analytics. Consider user feedback. Consider your gut. Consider stakeholder requests. Consider historicals. Consider your team. Consider your debt. etc etc

This is the best take, IMO.

Different strokes for different folks, but frankly managers don't care if a deadline greatly encourages or greatly stresses their ICs. Either way, it's a way to hold people accountable for a deliverable at a certain date, or at the very least an update why it was missed.

Not having deadlines requires much more nuance to ensure a team delivers work consistently, and unfortunately nuance in work management doesn't report well

You should already be spinning up caches and databases in dev anyway?

I agree though that the article is missing some explicit insight into how this change is handled on the local dev environment. I'm assuming the local dev environment run commands were also updated to be these three commands, one per workload.

Basically, this distinction should be represented throughout all environments, dev/test/prod

You're translating the class-based way of working in React against hooks, without stopping to consider understanding hooks as a first-class principle instead of a translation.

It's called useEffect because it runs on the (side)effects observed by the dependency array. An empty array happens to happen on mount. useEffect returns a teardown function which happens to correlate with unmount when an empty array is passed.

It's called useRef because it returns a (mutable) reference that's detached from the reactive layer. The DOM element connection is just sugar.

I agree that useEffect has a lot of footguns, but this position seems very shallow. The whole pattern changed, it doesn't make a lot of sense to continue comparing the two

yeah the article has a very US-centric take, stick shift is still very much alive in Europe. it's a lot of the times the more affordable option, and plenty of places in Europe dont have bumper to bumper traffic that makes stick a pain

Have you used git submodules before? I've only used them once and vowed to never use them again.

It's effectively just a pointer to a hash, and ends up being useless for versioning + a really nice footgun for tracking upstream updates.

The monorepo vs manyrepo tradeoff boils down to this:

Do you want more complicated build + deploy tooling or do you want more complicated dependency management?

If the former, pick monorepo. If the latter, pick manyrepo.

This is all fair and good. I was just pointing out the beginnings of a trend.

To me, build-time image optimization would’ve been a prerequisite for next/image even launching in the past. Something in the tune of “…and Vercel does all of this for you, automatically, by default when deployed to Vercel”. Instead, we get a build-time error on export.

I agree that the vast majority don’t need a custom server. If I could go without one, I would. Unfortunately I can’t, and this one’s not a criticism. It was clear to me once “Develop. Preview. Ship.” became the tagline that things like Docker support would go away. Fair.

Glad to hear Next.js Live will be open source, and I’m assuming it’ll be easy to deploy given the quality of Vercel’s work. I personally don’t understand the use-case but can see how it adds to Vercel’s value add.

Appreciate the reply! I just wish Vercel looked into immutable database provisioning, continued Docker support, alongside the stellar React work.

Also disappointed by this. Vercel has increasingly been putting out more features that are tucked behind a vendor-lock.

- `next export` when using `next/image` doesn't have a sane default

- Running a custom server means no deploying to Vercel. I understand that one the most, since Vercel has decided to lean on serverless

- Next.js Live can only run on Vercel

I still reach for Next.js + React first when starting a new web project, but have since replaced Vercel with Render because more times than not, I need to run something that just doesn't work on serverless. Been a user and fan since v1.0.0, and have only just started noticing some features that go against the "sane defaults, config available" ethos that seems to be core to the team.

No hate, just observations.

The vast majority of candidates I've spoken to commit their code to private repositories. Same goes for me.

Roles were for fullstack and frontend. You're right in that sometimes time escapes us when coding. That's why I set a time limit to the exercise and ask them to submit whatever they coded in that time frame. Doesn't have to be perfect, nor does it have to be complete. The point is to have code to talk through specific to the role you're hiring for, and ideally specific to the project itself.

What does skill have to do with difficulty?

Big red flag if you think the only way to impress someone of your coding skills is if you overengineer a solution. If some candidate submitted an overengineered solution, I wouldn't hire them.

I agree on needing time to solve the take-home. That's the biggest con with this approach.

If you don't have the desire to complete the take-home exercise, then you probably don't want to work there in the first place.