Why in the world was marquee removed? It probably does a better job at scrolling than CSS. Look at everything that had to be written just to mimic a fraction of its power!
To make it efficient, you'd also have to add and remove elements out of sight to save memory. Pure CSS doesn't do that.
If the code you have quoted is verbatim what you have tried, seems like you need to extract the parentheses and possibly a single or double quote, depending on the source css. The example source you have given has a single quote.
Asking just because I'm curious... why are you using xpath?
Also, is this for a website you control or for some else's website?
If you're rendering the page (in a browser, e2e test-runner, spider bot, etc...), have you considered running some js on the page to get the image? Something like: const imagePath = document.getElementById('exampleIdOnElement').style.backgroundImage
Asking just because I’m curious… why are you using xpath?
I'm using a service called FreshRSS that automatically fetches RSS feeds. It has a feature that allows you to create custom feeds for sites by scraping the HTML with user specified XPath expressions.
I know that this isn't exactly "web development", but it uses webdev tools, and I wasn't entirely sure where else to post this.
If you’re rendering the page (in a browser, e2e test-runner, spider bot, etc…), have you considered running some js on the page to get the image? Something like: const imagePath = document.getElementById('exampleIdOnElement').style.backgroundImage
JS is, unfortunately, not possible here. I can only use XPath expressions.
This is cool, but it bothers me that the inhale cycle doesn't end with completely filling the circle with blue. I feel unfulfilled, like when the DVD player screensaver doesn't hit neatly into the corner of the screen when it totally looks like it's going to
I think it's because you're not supposed to expand your lungs so much that they feel like they're going to burst.
But if you scroll to the bottom of the css and look at line 69, you can change transform: scale(90%); to transform: scale(100%); to see if you like it better.
Incremental builds are much faster as it often only need to rebuild the specific part that changed. Just re-running the build in VSCode won't help you if the build takes like 5 minutes, but still instant with watch mode.
Hot reload also has some advantages such as not having to reload the page and lose state: it can just update the CSS live so you can quickly iterate on your styles even if you're deep into the navigation at page 10 of a modal window.
We don't need live reload/watch, but it sure is convenient.
Why could a build take 5 minutes? Is it due to the size of your project or the language the bundler is written in (JavaScript being a slower option over Rust)?
The scale of things. Large projects take longer to compile and bundle because they're made out of thousands of files and hundreds of thousands of lines of code.
Yeah, your hello program will go just as fast without a bundler, or a simple bundler. It's when you go big, and use tons of libraries and stuff that it slows down and the advantages become clearer.
That's especially true when using big libraries like React and dozens of plugins for it, frameworks like Next.js, SASS for CSS or CSS in JS, all the JSX, all the TypeScript. It adds up especially if Babel is also involved to transpile for older browser support.
5 minutes is a bit of an extreme use case, but the point is after the first build, live reload would still refresh your code at the same speed. So working on one page you don't need to constantly rebuild the other hundreds of them, just the one you changed. If you target mobile platforms with Cordova or React Native then you also add a whole Android/iOS build + install + restart of the app. The same live reload would work even in that context, making the speed advantage even more apparent.
These things are designed for large enterprise projects, not for your small helloworld sized hobbyist programs.
Depends entirely on the bundler. They all have a watch mode, not all of them do hot reload. Hot reload is cool but full of gotchas, it's a hack but worst case you reload the page anyway. Some probably cache on disk, I think webpack can.
But if you think about it, you either want a clean build for production, or rebuild quickly during development. Watch mode does exactly what you'd do anyway, re-run a build. And IDEs can watch its output to give you error messages.
It's much easier to implement: just emit the code again when the file changes, and let it go through the pipeline. It's already there in memory all figured out, no need to figure a serialization format to put on disk to load back up.
But to circle back to the original question of why use watch mode when you can just rebuild it when saving a file: you're reinventing the wheel, and watch mode scales better and will always be faster. Yes, some people need watch mode.
For decades, outsourcing was happening to India and other east asian countries to cut costs. This happened even under low interest rate for loans.
Now that interests are higher the cost cutting and outsourcing only increase.
My own feelings are that we really should figure out if we want to work for such lowballers who cut us off like parasites at the first sign of trouble.
It would be prudent for workers to seek work in smaller, private companies. While they have the risk of going bust... they're hopefully not laying off people in the same breath as announcing record growth.
Most of that only applies if you're running your website as a public-facing entity, i.e. open to the general public to browse/use or if you're running it as part of a business.
If it's a non-commercial, private-use site you don't need any of those "requirements".
To make this work well with the Fediverse, you'd need to be able to specify your own server (e.g. programming.dev), which is under discussion at https://github.com/fedidcg/FedCM/issues/240.
To make it work in a way that preserves privacy as a value held by many current users of federated social services, yes.
But it seems like it can be implemented as is in any federated service and improve security for 3rd party frontend apps.
Maybe I'm missing something essential, but holding out for a perfect implementation which may not be broadly adapted might be a mistake on a developer's part if they want to provide value to ther service they're developing for.
XHR is absolutely ancient. Like, I used it on Internet Explorer 6 era websites. Using a 3x3 table with images in all 8 outer cells to make rounded corners.
It still works but is so old it can't really be updated. It's entirely callback driven so no async. It's not even async by default if I recall correctly, it just hangs the browser.
The Fetch API was designed to modernize what XHR does, and does so well. Now, a simple get request you can pretty much await fetch(...) whereas the XHR one is probably 20-40 lines of code and most people end up using a library to deal with it, or write their own little wrapper for it. It supports promises natively.You can stream very large files without loading it all in memory. There's nothing XHR can do that fetch can't do, and usually does it better too. For most use cases the performance will be the same, network IO is orders of magnitude slower than JavaScript execution. But the API being better probably does lead to better performance by not doing unnecessary things and possibly processing data as it arrives instead of all in one go when the download is finished.
It's a modern replacement because it's literally what it was designed to be. Try both and it'll be abundantly clear why.
I looked at the waterfall and I realised I had some design images in there at 2500+ resolution that were taking 5s to load and that was interfering with the loading of the JS.
Thanks, I'll make sure to check this tab first before posting next time.
Web Development
Hot