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.

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.

Out of curiosity, how is it not still "rendering"? Do you prefer "start" because it renders a tree of children?

But yes, rendering doesn't need to be interrupted. They specifically mention architecture decisions to avoid rendering operations that take too long (debounce and throttle).

This eliminates previously necessary architecture decisions while providing a better user experience. How is that solving the wrong problem?

Also, this is still the view layer. There's nothing React-specific about data fetching, "complex manipulations" or "event processing".

Previously if you had a text input whose output you used to fetch some data and render in a list, you'd use debounce.

Now, with Concurrent Mode, you don't have to and can instead use the React API.

Sometimes frontend developers overengineer their solutions, yes.

Sometimes you need a more complicated solution for a complicated set of requirements.

Do you need GraphQL? Nope!

Do you need GraphQL for an application that needs to fetch a lot of highly relational data with nested objects? No, but it sure would be more optimal to just ask for what you need in one request in the shape you expect, instead of either:

a) Multiple REST API calls that you need to combine and coordinate in the frontend

b) A specialized REST API call that gives you all the data you need in the shape you want, but it isn't very RESTful

c) A REST API call with a bunch of `with[]` params (a la Laravel) that indicate what nested objects you'd like, but not their exact shape

So, which is more maintainable then?

—

The other wild misconception I see time and time again is this:

Of the five things you mentioned "React/Redux/Graphql/hooks/bazillion-libs", only the first one is React, and the second-to-last (Hooks) of which it is optional.

The rest are dependencies you opt for, hopefully after weighing pros and cons. You don't need to use Redux, GraphQL, react-table, whatever other dependency in your React web application.

Please separate out React from React-based codebases from code architecture. They're not one in the same.

- Don't default to "Agile" (or be fully "Agile" for that matter)

- Don't default to Typescript (or any technology for that matter)

- Don't default to TDD (or any dev methodology for that matter)

- Don't default to linters and bundlers (or any intricate tooling for that matter)

- Don't default to complicated infrastructure

A friendly PSA that you can still, in the year of our lordt 2019, create a static site with an HTML file deployed to shared hosting over FTP. You could also create a dynamic site with some PHP thrown in there.

Reach for the minimal process, tech, methodology, tools and infrastructure you need to get the next X pieces of work done, and complicate things only if the pros outweigh the cons.

I'm not picking on you specifically blobs, I'm sure you walked into an organization that employed all these things with seemingly no good reason. The thing is, there's always a reason, it just might not be a great one!

That said, if your goal is to estimate things more accurately, you might need to spend a little more time with your coworkers to define as many unknowns as possible.

I don't.

I have stints of high motivation and stints of low motivation.

The trick is to be productive without being passionate about programming. "Choose a job you love and you will never have to work a day in your life" is a toxic mentality, and it's okay for work to just be work (sometimes or even all the time!).

Key-value stores satisfy a set of use-cases, as do NoSQL, and SQL.

Key-value is great when you have a key-value pair that you'd like to cache. Specifically in web workloads, maybe you'd like to cache the API response (value) to a certain API query (key) such that its returned without processing power from your backend. Or maybe user permissions per action, where they don't really change as they're reliant on the user's role.

I'm not entirely sure what a valid use-case would be for an embedded device, but if there's any kind of SQL query you would make on an embedded device that returns a response that hardly changes, you might also spin up some kind of key-value store such that it's returned without (well, faster than) SQL query time.

It probably doesn't make sense to completely replace a SQL database if you're trying to represent relational data.

My argument is that they're using the same strategy, language and branding they used to sell their brand to the world to sell their public offering to the world.

I don't perceive that as detrimental, and don't see how designing a document is "disgusting". It's nontraditional.

I'd agree except WeWork's emphasis on design is a huge reason they have become this big in the first place.

Question from someone that's not familiar with law, or I guess specifically antitrust (anti-monopoly?) law.

How are these acquisitions not in violation of these laws. Especially from the Big Tech Cos that slurp up literally any small competitor.

From the article:

"DoorDash's acquisition of Caviar creates a highly differentiated company with a unique brand and wide-ranging selection."

How is this not a play at eliminating competition?

Did your company try to write an FAQ page on how to accept the double-confirm dialogs in all major browsers (with screenshots) to maybe reduce your "90% of support tickets"? Does your ticketing software redirect you to (or display) an FAQ page that matches the ticket title?

I've come to understand how features like these get built, but I've also come to understand that people that use software are a lot more resilient and savvy than we think.

If 90% of your support tickets are about getting through a standard double-confirm, patio11 would probably recommend increasing your pricing to limit your paying customers to a pool that probably won't have much more trouble with that.

An actual Apple employee.