Better use pnpm, faster for those that don't have 1 Gbps uplink and live outside the usa.
> 3. Use Typescript
Better use jsDoc, d.ts files are scary and are really complex, you need a typescript wizard la matt pollock just to tell you are mistakenly trying to concatenate a string and int.
> 5. Use prettier
yes use prettier but don't forget to configure eslint to work with prettier otherwise you are going to have a bad time.
> 6. Use react
Use whatever fits your problem but if you are going to really use rect then do it with Next.js, no point in still using CRA/CRACO
> 7. state management
Avoid using state, try to solve every problem with pure functions, if you must use state then consider redux/react-query
> 8 & 9.
You should still recommend stylelint, specially if you are going to write css by hand otherwise don't just use tailwind, tailwind is bootstrap with extra batteries (change my mind).
> yes use prettier but don't forget to configure eslint to work with prettier otherwise you are going to have a bad time.
Can you elaborate? I'm using eslint and prettier with pretty much default settings and never had it conflict with each other. My impression was that they work on different aspects. May be there're some overlapping eslint checks, but they're not enabled by default (or I didn't stumble upon them yet).
When you want to integrate a javascript module that isn't annotated with types... types in a dynamic language like javascript are complex once you start doing really abstract things like generics the fun of typescript ends, also there is a recent push to abandon typescript mostly fueled by svelte fan base but nevertheless typescript is really complex, easy to shotgun yourself.
And thats why it isn't worth, you are adding complexity to a problem that doesn't need to be complex, jsDoc is the best of both worlds, type safety, zero complexity and it works with typescript (if you still really want to use it).
Personally i think typescript isn't going to be around much time on the frontend side, maybe on the backend by some people that still believe in adding another compiler layer to their build time.
You have pretty much described the "php way" of developing things, is funny js-driking cool-aid guys talk about "SSR" being the thing to have, when we already had that, we already found that it can't scale without lots of money and started pushing computation to the client and now we are bring them back because it's not fast on the initial load...
damned we have come to full circle whats next, an assembly language so we can run binary code inside the browser kinda the way activex and applets just used do it... wait isn't that the whole point webassembly? sight you f** javascript developers have done it again sight
This is fairly reductive. SSR is less about rendering HTML on the server, and more about having both the initial render and the client-side updates use the same process. Contrast this with other ways of rendering the front-end where either the client needs to build the entire view itself, or you need to write a separate application to do any client-side manipulation that might be necessary.
As with everything in software, it's all about tradeoffs. Using PHP to render your templates works great if there's limited client-side interaction (say, blogs, forums, documents, marketing pages etc), while frontend rendering allows you to build much more complicated applications that can react much quicker to user interaction, but will be slower to load the more complicated they become. And SSR tools try and have the best of both worlds, but make other aspects more complex in exchange.
> But I just hope to learn to stop feeling bad for honest mistakes.
A: By trying to fix them.... this is the way.
It is simple, the difference with people that take feedback personally and the ones that don't, is that the last people are willing to make an attempt to fix the problems the others don't want to be bother.
I always take personal feedback with this mentality "ok fine, lets do it your way", if it works and its either better or equal than my solution then fine good for you, if it isn't then its the awkward/refreshing? moment when you have to tell them they were wrong and you have proof.
ChatGPT et al has run online coding exercises/trivia/exams pointless imho, leetcode problems are cool solution to the problem if you want someone with lots of "raw abstract knowledge" but zero real world experience.
Promotion in USA seems to be more like a thing that most happen every one or two years at work rather than for work well done, last time i had a friend that was working for a faang (pre-layoffs) and show me he was like a third level manager for several projects because he had 3+ years at company, he still does the same job as when he got in just that now has to manage or mostly deal with upper management request for estimated time to finish every day.
This looks and feels like passwords with extra steps...
I mean now i need to "store, manage and secure" my per-user-certificate sorry "my passkey" myself and if its get compromised its my fault, how are passkeys more "secure" than enforcing a secure long password that the user can't change unless he met certain conditions and its conveniently stored inside the password manager i just built.
What happens if i lost all my devices due to a fire? at least a password let me still access things we these i might need to prove again that i am me, it might even be more easy to steal accounts because i can ask google to change it because i lost my passkey.
Passwords can be both stolen (they are valid for multiple authentications) and are susceptible to phishing/MITM attacks.
TOTP/HOTP solves the first problem by making the credential provided during authentications single-use, but they're still susceptible to phishing/MITMs (since you don't know where you're entering your OTP).
WebAuthN solves both.
> What happens if i lost all my devices due to a fire?
Passkeys are synchronized to your device ecosystem vendor by default (i.e. Google or Apple, and soon also third-party password maangers on Android), for better or worse.
> Passkeys are synchronized to your device ecosystem ... and soon also third-party password maangers on Android
And at that point they make a full circle becoming just passwords with a master password. Essentially what password managers already do. You already can tie a master password to a biometric or another factor.
Not quite: Passwords are long-lived bearer tokens, which can be phished/MITMed (exclusively using auto-fill helps, but non-technical users are still prone to be phished) and are administratively harder to securely manage on the backend of the relying party.
Me too – I'd much rather trust my password manager, so I'm hoping that platform/browser APIs will eventually become available that will allow such third-party implementations. (Android is planning to; iOS hasn't stated anything yet.)
Even then I would probably not add my bank credentials or other high-sensitivity things there.
The solution, for you, is a cloud synced passkey manager, possibly a custodial one.
A password manager with strong passwords is weaker than a password manager with passkeys, because passkeys use asymmetric crypto and passwords+2fa involve exchanging a shared secret over an insecure channel at some point (yes I'm considering 1-sided TLS an "insecure" channel here).
Trust the security experts when they say passkeys are more secure. Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.
So in the event that i lost everything, i mean catastrophic, like my house burned to the ground with all my belongings, i have no kin nor "trust alternate people" configured for my account, my password manager requires my "synced in google/apple drive/cloud" passkey or my last known device, i can't retrieve it in anyway, how can i recover my account?
Either have to prove that m me to my account provider, which essentially is huge security hole since what data it will be required to prove might be more easy to fake (kinda like how people do sim swapping) and stole my passkey or do the "crypto thing", that if you lost your decryption key all your money is gone forever and ever and start fresh.
I mean my point is... password are not going to be deprecated, we had so many attempts to murder them but their convenience outmatch any other solutions, feels like passkey aren't well designed imho if the backup requires a password, then passwords won't be deprecated... maybe passkeys aren't meant to replace password but long-sessions oauth tokens if you ask me why passkeys exists.
Sure. The idea of authenticating a human based on something you know, passwords, is still useful and not going to die anytime soon. But it would be a much much safer world if you only had to remember one or two passwords than if you had to try and get passwords right for every service you use out there. A single password protecting a keychain full of passkeys is still better than reusing that same password on every single site. Hands down no argument. This is why passkeys exist. They are objectively a superior technology and you are objectively safer using them, as long as you can comfortably recover from disaster scenarios. The fact that you might choose to still use a password to get access to your passkeys is, well, up to you. You're free to take whatever posture makes most sense to you. Someone else might "trust alternate people" and another might keep a printed copy of all their passkeys in a bank vault. But whatever you choose as your preferred recovery/bootstrap method, using that to get you to a per-site passkey world makes you safer than what you're currently doing using symmetric keys everywhere.
> Trust the security experts when they say passkeys are more secure.
I trust the security experts when they say passkeys resist various attacks better than current systems...
> Now, solving the UX to make it match that of passwords plus managers today is the problem, agree.
... but poor UX makes it likely the users will end up doing things that are less secure, not adopting them at all, or messing things up themselves in such a way that they lock themselves out of their accounts.
So until the UX issues are fixed, "more secure" only in the narrow definitions that sophisticated security folks worry about. If the folks I support blow it, it doesn't matter that some mostly theoretical MITM attack was prevented.
Understood completely. I was only trying to articulate that there are tangible security benefits to using passkeys over passwords and no/zero theoretical downsides. A 32byte random password is just an edDSA private key that's not private, after all, and the two can be managed the exact same way with none of the device-bound woes. That is, all assuming that platform vendors commit to providing the same affordances for passkeys as they do for passwords in terms of allowing users to delegate to 3rd parties to complete signing of the WebAuthN challenge.
I also believe that Apple/Google/Microsoft understand the importance of not having a "I lost my device all my stuff is toast" UX, which is why Apple requires iCloud keychain to enable passkeys. They are making a pretty strong statement that the UX they imagine working for the masses is not some rigid "no cloud no syncing not here not ever" stance. So I think they realize it has to be a solution that doesn't have that failure mode. They're okay with soft keys, which is at least a relief.
Quite difficult to review that many hours of video but from the syllabus there are probably some missing pieces, mainly stored procedures and triggers, yes i know MySQL sucks for that particular job and probably you didn't touch them because planetscale probably doesn't support them (not a planetscale dev but this is my wild guess).
Also didn't see any topic on choosing the right charset/collation for the right data and why.
Oh there are definitely missing pieces! I tried to cover the "meaty middle" of what application developers usually need to know. I did not cover stored procedures and triggers.
I did cover CTEs and windows, which are not yet supported by PlanetScale. I also covered foreign key constraints, which are not yet supported by PlanetScale.
As far as charset and collation, I cover that a bit in the "strings" video of the "Schema" section.
I have said it before and still say... InfoSec is a glorified policy writer.
You spent more time 90% of the time "writing documentation" rather than on finding the security problem and suggesting the fix. That's why i choose development rather than InfoSec (despite having a knack for it), because its more technical and i don't need to explain "why" everytime.
The best security tools and practices won't protect the business if they're not used consistently. Policy is how things get done. It's an expression of the business' values and priorities. Even if it's just "all employees must install the authenticator app or request a Yubikey otherwise the cyberinsurance will drop us."
I think you are mistaken. Obviously InfoSec is a rather generalising term, while you are abstractly describing the work of someone that works in Application Security.
I don't know if these advice still applies en 2023, mostly because at least on the "web" side of development there are so many solutions/frameworks/libraries releasing that look exciting but there aren't enough problems to be solved solely through software development in our daily lives.
Till this day i don't know were can i fit svelte/solidjs/remix in my current development environment without introducing more problems than solving issues but there is a crowd of young developers that learn from bootcamps these tools and start solving all the problems with the same tech (like why is everyone using nextjs for static content like devdocs?).
Sometimes is good to ask for problems to be solved, its more satisfying and challenging helping someone else rather than making another guitar mixer software that is a problem solved inside another software (ableton), also helps a lot to develop your professional skills because at the workplace you won't be the one using the software and you learn a lot of how people use your/the software.
This resonates strongly with me. I have no use for any of these technologies for any of the problems I face daily. The only problems these things solve are certain business problems which do not concern the individual.
> When I need to add a dependency, I invoke download-package and then declare it in the import map. I like this setup because it feels like I’m only using the bits of the NodeJS ecosystem
Thats using node/npm but with extra steps...
Anyway kinda like the importmap thing, it would have been better if he didn't reference solidjs but thats life.
Better use pnpm, faster for those that don't have 1 Gbps uplink and live outside the usa.
> 3. Use Typescript
Better use jsDoc, d.ts files are scary and are really complex, you need a typescript wizard la matt pollock just to tell you are mistakenly trying to concatenate a string and int.
> 5. Use prettier
yes use prettier but don't forget to configure eslint to work with prettier otherwise you are going to have a bad time.
> 6. Use react
Use whatever fits your problem but if you are going to really use rect then do it with Next.js, no point in still using CRA/CRACO
> 7. state management
Avoid using state, try to solve every problem with pure functions, if you must use state then consider redux/react-query
> 8 & 9.
You should still recommend stylelint, specially if you are going to write css by hand otherwise don't just use tailwind, tailwind is bootstrap with extra batteries (change my mind).