231–240 of 257 posts
Earlier quoted context omitted.
Never start with Webpack. Use Vite with a template and go from there.
I'd make the exact opposite suggestion: Always use WebPack. There will be a package in the future that has a particular WebPack configuration to make; and you don't want to figure out how to do that in another bundler.
Earlier quoted context omitted.
They are. At this point it's a completely different language with its own stack, as far as I know that will be a core component for the forseable future. Now they also have modern PHP and some other languages alongside with hack from what I understand.
I don’t think there’s any vanilla php in use at meta
https://medium.com/@aarthimanikandan2006/does-facebook-still...
Earlier quoted context omitted.
More like if AI leads to spam or if guns kill people. The latter one is harder if you only have a knife instead of an assault rifle.
You seem to have a fundamental misunderstanding of what Figma is. Your question would be better answered if you took some time to look at figma, rather than looking at the designs people create with figma.
On mobile I have a limited data plan and the speed isn't always the best and on many pages I have to wait because beside the ads I have to download 3, 5, 10 or even more MB of data just to get pages where button, links and headline are undistinguishable because of recent design decisions.
Seems to me these tools are worthless in the end, if you are a user. After bootstrap it went pretty much downhill.
Earlier quoted context omitted.
Remix. Vite done right, mostly pre-configured out of the box.
Vue, Nuxt or Svelte are even better. No need to waste time and energy with React and it's peculiarities. However, if you want or must React, then Remix, hands down.
Earlier quoted context omitted.
I really wish browsers had continued to develop a "use strong" mode for JS. It sounded like there were significant challenges, but curbing some dynamism in order for more predictable optimisation sounds like a great tradeoffs for production-quality apps.
Yeah, I wonder where that performance increase actually comes from. This[1] lists their optimizations. My guess is mainly the integer optimizations. And I guess making sure that functions are always called with the same argument types. The other optimizations is already done by the JITs. [1] https://evanw.github.io/skew-lang.org/
Earlier quoted context omitted.
k8s is not allowed to use in the most projects utilizing the internal stack, at least yet. In fact, it hasn't reached to the feature parity level necessary to replace any big projects running on Borg.
If other companies can run big projects on Kubernetes, so can Google.
Earlier quoted context omitted.
It's not that it's bad. But sometimes the project and the team are not that big that its qualities matter. And you lose a little bit of readibility with type-intensive code. And nicely written TypeScript looks awesome, but badly written TypeScript can be a huge mess, as it can with any language, but TypeScript purists sometimes forget that the language is just a part of a nicely written and designed system.
I would describe typed code as more readable, not less. I take “readability” to mean ease of understanding, not how much my code sounds like written english. Not knowing what the type of something is makes understanding harder.
I wonder if some engineers were sad to see Skew go.
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 don't use it because the compiler is just too slow; waiting 2.5 seconds for even simple files is a massive pain. I want the old "CoffeeScript experience" where you compile stuff on-demand in development and output errors in the webpage or stderr. It works very well, is low complexity, and requires almost no effort. But you can't as it's just too slow.
esbuild doesn't typecheck so it's not an option. And hugely complex background builders are, well, hugely complex, it's not an option.
TypeScript-the-language may be nice, but TypeScript-the-tooling is not particularly great.
And even if this was solved: any build step will add complexity. The ability to "just" fetch /script.js and "just" edit it is quite nice. This is also why I've avoided CSS pre-processors since forever (needed a bit less now that variables are widely supported).
Of course different projects are different and for some projects these downsides are less pronounced. There is no one perfect solution. But there are definitely downsides to using TypeScript.
They don’t really mention the ongoing developer experience impact (even if it is outweighed by the popularity of TypeScript) of losing Skew’s niceties, they just talk about the one-off transpilation of them when migrating the codebase. For example, the fact that it’s easy to end up with files that need to be imported in the right order in TypeScript, or things will break; or the fact that destructuring is slow and so…
I was definitely sad to see some features of Skew go. For example, operator overloading and integer types. But the move was ultimately a decision the whole team made, and I agree with them that it was the right one.