nickdandakis's comments

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.

Handsome | Senior Frontend Engineer | REMOTE | Contract (6 mo+)

https://handsome.is

Handsome is looking for a talented freelance frontend (or fullstack) engineer to work closely and collaboratively with our design team to create extraordinary, award-worthy website experiences.

The primary workload will be building out React pages (from Figma mockups) while contributing to our Design Library, and integrating REST APIs.

Technologies:

- React

- Node

- CSS Modules

- Babel, ESLint, PostCSS, Webpack

- Next.js

- Storybook

We are ideally looking for someone that has 3+ years of experience in the above (or similar) technologies.

Handsome is a digital experience agency. We work with the world’s most innovative brands to create digital products, services, and businesses that help them thrive in a progressively connected world. Our client partnerships include FedEx, Keller Williams, Dell, Facebook, Home Depot, Nickelodeon and others.

Shoot me an email at nick.dandakis[at]handsome[dot]is.

Handsome | Senior Frontend Engineer | REMOTE | Contract (6 mo+)

https://handsome.is

Handsome is looking for a talented freelance frontend (or fullstack) engineer to work closely and collaboratively with our design team to create extraordinary, award-worthy website experiences.

The primary workload will be building out React pages (from Figma mockups) while contributing to our Design Library, and integrating REST APIs.

Technologies:

- React

- Node

- CSS Modules

- Babel, ESLint, PostCSS, Webpack

- Next.js

- Storybook

We are ideally looking for someone that has 3+ years of experience in the above (or similar) technologies.

Handsome is a digital experience agency. We work with the world’s most innovative brands to create digital products, services, and businesses that help them thrive in a progressively connected world. Our client partnerships include FedEx, Keller Williams, Dell, Facebook, Home Depot, Nickelodeon and others.

Shoot me an email at nick.dandakis[at]handsome[dot]is.

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.

Handsome | Austin, TX | Contract (4 mo+) | REMOTE

https://handsome.is

Handsome is looking for a talented freelance frontend engineer to work closely and collaboratively with our design team to create extraordinary, award-worthy website experiences.

The primary workload will be building out React pages (from Webflow + Figma mockups) while contributing to our Design Library, and building out additional landing pages specifically for SEO purposes.

Technologies:

- React

- Node

- CSS Modules

- Babel, ESLint, PostCSS, Webpack

- Next.js

- Storybook

We are ideally looking for someone that has 5 years of experience in the above (or similar) technologies.

Handsome is a digital experience agency. We work with the world’s most innovative brands to create digital products, services, and businesses that help them thrive in a progressively connected world. Our client partnerships include FedEx, Keller Williams, Dell, Facebook, Home Depot, Nickelodeon and others.

Shoot me an email at nick.dandakis[at]handsome[dot]is.

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.

I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total.

I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs...

I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire.

To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.

Yes, there is.

Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates.

If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place.

Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.

Preferred syntax should be enough, but here's a couple more differences:

- Vue has a set of core libraries (Vuex, vue-router, etc) maintained by the same org.

- Single file components with scoped styling out of the box.

- Vue integration as a standalone runtime is a little easier than React (unsure about this one).

You can read more about the differences here:

https://vuejs.org/v2/guide/comparison.html#React

I couldn't find any official comparison documentation from the React docs, though.

The thing is, I don't disagree that a large (if not majority) number of developers reach for dependencies by default, instead of carefully considering patterns first.

I don't think bundling React the view library, Redux the state management library, Typescript the Javascript superset, GraphQL the API query language, Webpack the bundler as one "React the platform" is helpful.

I'd like to see the developers that automatically merge all of these technologies together by default because everyone else does it (or worse, because X Big Tech Co does it) to start questioning and exploring other options. I'm not sure how to get there, and maybe my comment above is my contribution towards convincing readers to reconsider their understanding of the React ecosystem.

You're right though, it is a mess. I think the mess comes from people and how they code, not so much this specific library nor the language.

Not to mention you can still keep your pure UI components separate from your components that have data fetching logic (aka containers).

Components are highly reusable.

Containers are coupled to specific API calls or logic.

I still default to doing as much data fetching on the top-level page component as possible and trickling data down. But if there's certain logic or data fetching I re-use in multiple places that don't need to block the whole page, I'll definitely refactor that into hooks + containers and delegate that data fetching lower in the tree.