At the last few grams, a small reduction gets very expensive. Helinox are super light, great for hiking and motorcycles. If you’re in a car, you can take a lot more with you.
The initial request size is not a great way to compare frontend frameworks. Next goes into a lot of effort to optimize navigation around your site, and gives you full usage of React in your frontend so you can show amazing things like charts, forms etc.
If the JS files are set to load asynchronously, the initial load should be almost equally as fast, and React should load in the background. Afterwards, additional navigation should be near instant.
Depends how pages are generated. If they are using getStaticProps this is not true because the HTML needs to be "hydrated" with the React runtime which requires javascript. Astro will prebuild the static pages.
Look for a tag like this: <script id="__NEXT_DATA__" type="application/json">
The page will render perfectly fine before it is hydrated when using getStaticProps. To verify , simply run LightHouse in Chrome on a page with cache busting on and look at the screenshot timeline. It will render in a fraction of a second, long before React gets loaded.
This is what client side apps do (e.g. React). They come with their own set of challenges which when not solved correctly turn into downsides. Probably still easier for Wikipedia to do than fixing their backend.
A flame trench would probably be a lot more inconvenient to them. Right now they can freely move around most of the launch pad. This is probably important for their rapid iteration, which is what is going to get them to orbit as quickly as they can. If a big chunk of the launch pad is consumed by a trench, that area becomes inaccessible by their platforms, cranes, etc.
I, a React developer for ~8 years, don’t really remember what useEffect does without the second param. I never needed it, so I forgot. I almost feel it should be a required prop, and I doubt that that knowledge alone would fail or pass an interview.
One of the things about React is that local codebase conventions really influence what parts of the API are high-touch for you.
I too have been coding in React for that long (precisely that long, oddly enough ;D) and I used `useEffect()` in pretty much everything I was doing.
There are reasons for this that are local to the project I was on for most of that time.
And yeah, I'm pretty sure my embarrassing confusion cost me the interview in question.
Coding is a lot like playing a musical instrument, or singing. Without daily practice, you get musty. You can scrape off the must in a matter of days or weeks, but in the meantime, you can be expected to bomb any audition.
This is why it's so good to have something on the go on GitHub. It's not about the star-count, it's about keeping your hand in.
As per this thread: https://news.ycombinator.com/item?id=35192038, I reckon the whole is “creative enough” and would be protected as the developer only used parts and cherry picked and combined what they needed.
> Instead, these prompts function more like instructions to a commissioned artist—they identify what the prompter wishes to have depicted, but the machine determines how those instructions are implemented in its output.
If you commission an artist, the produced result becomes yours and you own copyright on it. How different is it with AI?
The AI did not creatively decide to do something. An order was placed, it fulfilled it, and ownership was transferred.
If you look at library popularity more broadly, you’ll find over longer periods of time only those people enjoy working with actually continue to grow regardless of previous momentum. People really do move on if it doesn’t work well enough for them.
Take React form libraries for example [1], redux-form used to be the most popular by far, was followed up by react-final-form from the same authors so people naturally flocked to that. But that is now clearly seeing a decline as react-hook-form, a library that started from zero, is a lot more pleasant to use.
AngularJS and Angular are really the same product. Angular 1 turned into Angular 2 turned into Angular 15. That’s far from different frameworks, even if in between versions you’re essentially learning a new framework.
