101–110 of 257 posts
Off topic: Does anyone know of any sites made with Figma so I can see what the UX is like? As a user I don't care about DX if the resulting UX is bad.
Doesn’t even support more advanced prototyping things like inputs and dynamic changes.
Not a site builder
Off topic: Does anyone know of any sites made with Figma so I can see what the UX is like? As a user I don't care about DX if the resulting UX is bad.
You wouldn’t really be able to tell. Figma is often just a tool for working out designs and building up a design system for your site. That later gets translated to your front end by your devs. Figma itself isn’t a styling library like tailwind, etc.
If Figma helps building lean designs it's good otherwise not.
Designers tend to put too much useless parts into sites, like unnecessary transparencies and animations.
Earlier quoted context omitted.
Meh, as far as I can see PHP has a ton of very active development around web services and frameworks, which is its core value proposition. PHP as a language should probably slow down in general but the people who use it don't seem to be really dying out or slowing down as much as the bubble leads us to believe.
People hate php for no reason. They talk about performance or whatever while building rest crud apps. Literally any language can handle that easily and your bottleneck is usually the database. I've scaled startups on PHP to hundreds of thousands of users running on a few cheap ec2 instances. But no one wants to build new php projects instead focusing on Go, Python, or Ruby. I honestly don't get it. PHP devs earn less…
Earlier quoted context omitted.
It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased. Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience.…
Never start with Webpack. Use Vite with a template and go from there.
It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commente…
Earlier quoted context omitted.
It is actually a fairly indicative story. At the start there is a brilliant individual (Evan) who sets up an entire toolchain + core of the product. They then move on (or get pushed out, or get bored), and with the team (and the product) now being much bigger, things get replatformed to a more familiar, widely used stack. The success of these steps heavily depends on how robust the eng culture is at the organisation.…
It's ironic. For the past 5 years I've been writing type strict PHP. People love to shit on PHP yet I found that when I started using strict types my code quality improved, amount of lines needed to produce a result decreased, and necessary unit tests to produce the same result also decreased. Then a few months ago I decided to write a TS project from scratch. For the record I have 18 years of JavaScript experience.…
Earlier quoted context omitted.
Never start with Webpack. Use Vite with a template and go from there.
Or just go straight to esbuild. I've found vite just makes things more complicated and slower. Particularly, the "smart reloading" breaks in subtle ways and turning every source file into a request doesn't scale well. This can probably be configured away somehow, but again, that just makes things more complicated.
It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commente…
Sometimes I just don't feel like dealing with those very few downsides though, but I can accept it's mostly personal preference.
At my age, sometimes I just don't want to deal with:
1. Yet another configuration file (tsconfig.json in this case). When something breaks, having one more place to look at is not something I want. The more extra files like this are needed for the development environment to even work (as in, something undesirable happens if you remove them), the less confidence I have in the project's long term reliability/stability.
2. That same configuration has misleading naming. The `"strict": true` setting should be called `"recommended": true`, or at least `"preset": "recommended"`, because it's not even strict. I would expect this `strict` flag to enable everything to the most restrictive way possible, and let devs disable checks (if) they don't want them. In its current state it doesn't enable strict checks like `noFallthroughCasesInSwitch`, `noImplicitOverride`, `noImplicitReturns`, `noUncheckedIndexedAccess`, `noUnusedLocals`, `noUnusedParameters` (I might be missing more).
3. Related to previous point: Inconsistencies between projects. So I work on one project with strict settings, tsc properly mentions possibly undefined accesses, etc; and then I move to a different project, and if I forget to context switch ("TypeScript config is different here"), I could be accidentally trusting the compiler to keep undefined accesses (and other stuff) in check, when it's not actually doing so.
4. Last time I checked, I couldn't just have a git repo "foolib" that is 100% TypeScript (100% .ts files, zero .js files), and `npm install` that repo on a separate project, and have it Just Work™. There's always extra steps that need to be done if you want to use .ts files from a separate package (usually compile to .js and install that; or using a bundler (read first point again)).
5. Why does the "!" operator even exist (or at least, why isn't there a flag to forbid it (for example the strict flag)). In my experience, using it is just developer laziness, where someone just doesn't want to write proper checks because "it's noise".
---
Those 5 points came off the top of my head so I'm almost certainly forgetting stuff.
It's mostly "death by a thousand cuts" kind of stuff, so sometimes I might not mind, but other times I might not be in the mood to deal with this and heavily influences my decision to go with TypeScript (keeping it approachable to as many people as possible) or a different language/ecosystem altogether.
Yes, I could "just" write a package that I can just npm install and it autoconfigures TypeScript and other stuff for me (and I have done so, for my own sanity). But I shouldn't need to do that, and it's too brittle for my taste.
Earlier quoted context omitted.
You wouldn’t really be able to tell. Figma is often just a tool for working out designs and building up a design system for your site. That later gets translated to your front end by your devs. Figma itself isn’t a styling library like tailwind, etc.
But are the designs lean or bloated. If Figma helps building lean designs it's good otherwise not. Designers tend to put too much useless parts into sites, like unnecessary transparencies and animations.
It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commente…
I'm not against TypeScript, but I don't really see the massive advantage. I rarely see problems that are due to typing, and the downside is usually limited as I keep my JS on the frontend, not the backend. Regular JS/ES6 just flows better.
Also, when you have types it changes how you code itself. When I change a schema or refactor some function, I don’t need to think at all to make sure I’ve updated all the code that depended on the old schema or API; just fire the TypeScript compiler and it tells me everything that needs to be updated.
I’ve also not seen any issues for a long while where I’ve missed some conditional case, because I use discriminated unions with switch statements more, something that looks weird in normal JS but is very useful with types, since it tells me if I missed a case automatically.
Add that I’m managing a team of engineers, and so I can easily make sure they’re also not missing cases either, by setting the convention and having them see the light.
Putting aside other things like for instance always knowing that we’ve validated inputs for API endpoints since unvalidated inputs are the unknown type and therefore effectively unusable; or always knowing we’ve parsed and serialized dates correctly since we use branded string types to distinguish them from any other string with 0 runtime impact; the list goes on.
So yeah, it might just be the case that you haven’t actually internalized what coding with types even means, so you’re unable to imagine how it can help you.