I can’t comment on this one specifically, but SVG animations take notably more CPU usage to render/animate in Chromium browsers compared to GIF or WAAPI. And they block the main thread for at least some animations.
Readit Newsramones13 commented on SVGs that feel like GIFs koaning.io/posts/svg-gifs... · Posted by u/cantdutchthis
ramones13 commented on Microsoft Dependency Has Risks blog.miloslavhomer.cz/p/m... · Posted by u/ArcHound
If you ever want to go all out with a musical light show, I have some recommendations here: https://aluhrs.com/blog/holiday-lights-electronics/
For your specific question, Wally’s Lights is great, and like others have mentioned, something running WLED to control them is a great choice.
> Vanilla HTML, CSS, and JS
This is a non-answer. It only really is an admissible solution if you're just working by yourself. React solves real problems when building web applications. If you use vanilla HTML, CSS and JS, you're going to have to solve those same problems. How are you going to do it? How are you going to manage state? How are you going to synchronize your state with the DOM? How are you going to organize your components?
Teams that use vanilla HTML, CSS, and JS end up eventually building an internal, buggy, half-implemented, undocumented version of React.
I didn’t say don’t use libraries at all. There’s a wide spectrum between rolling your own everything and putting a massive abstraction layer framework between you and the platform.
(Sorry, somewhat copying this, since I responded to a similar point elsewhere.)
This is not practical advice for the vast majority of software engineering teams.
Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.
Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.
My experiences don’t really align with yours - most people are playing “follow the leader” with tech - “X uses Y, so we should to” and that’s it.
To your point though - use the platform. Vanilla HTML, CSS, and JS. All of that will be reusable no matter where you pivot and not lock you in to a pattern that might not work well for where you land.
Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have.
One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. Yes, there are a few specialized domains where this will matter. No, you probably don’t work in one. Greater leverage can almost always be derived from improving the backend.
The second reason the author says is that it’s based on a legacy eventing system which supports IE. The author goes on for quite a while to say how bad this is, but I question the assumption it’s predicated on: the legacy eventing system never bothers me, and it doesn’t create issues visible to my users. As far as it seems to me, this argument is akin to saying that React hasn’t bothered refactoring an old part of the code base. Yes, that’s not great, but it hardly strikes me as a reason to drop a framework entirely.
Finally, the author doesn’t actually give a prescription as to what to use instead of React. This is, personally, where the argument really falls apart. React does make a set of tradeoffs, I don’t deny that, but most alternatives I’ve seen make a worse set of tradeoffs that shift more work onto the engineer. Of course, since the author doesn’t actually highlight any alternative, we can’t have a discussion about what you’re trading away, but I suspect that the author makes no proposal because he knows that any alternative would immediately be shot down as obviously worse than React.
To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be).
Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things like landing or contact pages.
Cool project, a mild pet peeve with this type of thing - I have to read 75% of the README before I find out what it even does. The first bits make a huge assumption about what the reader knows.
This might be a stupid hot take, but I am surprised that so little of web UI exist outside of the browser. I mean why bootstrap or other frameworks are not managed by browser ecosystem? Why millions of people how to download same frameworks over and over?
There’s a pretty thorough post covering this here - https://infrequently.org/2022/03/cache-and-prizes/
ramones13 commented on AI copilots are changing how coding is taught spectrum.ieee.org/ai-codi... · Posted by u/Brajeshwar
ramones13 commented on AI copilots are changing how coding is taught spectrum.ieee.org/ai-codi... · Posted by u/Brajeshwar
Early 2023, when everyone started using chat GPT for coding, I thought it would be a big boost because it enabled us to quickly employ a large number of people in a project regardless of language or framework.
An year into the project I am forced to revise my opinion. When browsing my code-base I often stumble in abstruse niche solutions for problems that should not have existed. It was clearly the work of someone inexperienced walking through walls in an AI-fuelled coding frenzy.
Having an oracle that knows all answers is useless if you don't know what to ask.
I’ve had a project I’ve been doing for ~6 months learning python through Copilot+ChatGPT. It feels like any other project that accrues technical debt, but that debt is just a lot weirder. It was rough at first, but refactoring has gotten a lot better recently with bigger context sizes.