181–190 of 215 posts
Earlier quoted context omitted.
Yeah, that's how I ended up using prisma... until I realised they didn't have joins All this aside, knowing something is in Rust tells me: - It's fast - It's maintainable (imagine the same project but in C)
prisma not having SQL JOINS for a ling time is how I know I should just ship it when it comes to my projects.
Earlier quoted context omitted.
You need to use some kind of automation to fingerprint your files for optimal caching. Where applicable there simply does not exist a better caching strategy than fingerprint plus Cache-Control: immutable
Well but I might have a hundred files, only one of which changed. The 99 other ones are still in the browser cache and don't need to be re-(down)loaded. If I bundle everything, then I have to scrap and reload everything, which is probably great for the final user, but not the developer actively modifying it.
Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases.
While the JS ecosystem continues to be a huge mess, the solution to the problem is not LESS software development ("Just stop making more bundlers & stop trying to solve the problem - give up!"). Or even worse - solve the problem internally, but don't make me hear about it by open sourcing your code.
The huge amount of churn and development in this space has a good reason... it's a desperate attempt to solve the problems that browsers have created for web developers. Fact is that most business has moved to the web, a huge amount of web development is needed, but vanilla javascript can compounds and compound in complexity in the absence of a UI framework and strict typing. So now you've added transpilation and dependency management into the mix - and the user needs to download it in less than a second when they open a web page. And your code needs to work on at least 3 independent browser engines with varying versions.
SwiftUI devs are not a more advanced breed of developer than web developers. So why don't you see a huge amount SwiftUI churn and framework/compilation hell with native iOS development? The answer should be obvious. These problems are handed down from on high
The browser/internet/javascript ecosystem despite its glaring warts is actually one of the most amazing things humanity has created... a shareable document engine grew into a global distributed computing platform where you can script an application that can run on any device in less than a second with no installation. Not bad.
Feel the need to push back against the predictable nay-saying in here. Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases. While the JS ecosystem continues to be a huge mess, th…
People often scoff at complexity in frontend projects, but they need to handle various types of accessibility, internationalisation, routing and state including storage of those, due to its popularity it's also very frequently an attack surface. With advent of newer technologies (I don't just mean web Dev ones), that's been put into the browser as well, which compounds complexity even more. There's various authentication and authorisation standards most things need to handle as well (not isolated to JS, but it's also not free of it either). Not to mention the versatility and complexity of DOM and CSS that are some of the the most complex rendering engines with layers of backward compatible standards. Like you mentioned already, these engines are all subtly different. Also you have to handle bizarre OS+browser quirks. And things can move between displays with different DPIs, which can cause changes in antialiasing. There's browser extensions that fuck with your code too. Then there's also the possibility that the whole viewport can change. Networks change. People want things to work online and offline so they don't lose work while on a train... While working in an environment that wasn't explicitly designed to support that.
Christ, I'm exhausted just typing this. Most these people complaining probably barely understand what they're complaining about
Earlier quoted context omitted.
Is this how other people feel about NextJS? I've been trying to keep an open mind about it, but its entire design seems so antithetical to what I'm trying to accomplish. Is there a better mainstream alternative? From what I've seen NextJS is pretty commonly used.
The mainstream alternative is still to not have a "backend-for-the-frontend". If you use something like Rails, django, nodejs, use React connected to them. Or directly to something like supabase. NextJS is the extra complexity nobody needs. It is marketed as the solution to slow starts but React is slow so the solution is terrible over-engineered. A much better fix is to remove React and use something that is already…
Earlier quoted context omitted.
We have bundlers because for a long time we didn't have a module standard due to browsers hanging on to their minimal and simple model of `script src=`. Even now modules are pretty minimal fare. Plus there's all the transpiling and asset transformation, but hey we should all be using document.write and not those "bloated" frameworks on top of JS, right? Maybe jQuery if we want to get really bougie?
A bundler is necessary evil and should be thought of and developed that way. Not celebrated. There should be like two or three flavors, e.g. like Cpp compilers (gcc/msvc/intel), ideally with a big corp backing and they should be rock solid and not change much. The amount of bundlers I've seen in my time is borderline obscene. Nowadays it's even worse, as every javascript framework developer's actual secret fetish is…
I've managed to cut down build times from ~1min (sometimes up to 3, but I couldn't even tell you why) when using Webpack and Babel to less than 200ms using just Rsbuild.
So, I welcome the improvement! The fact multiple people/orgs felt the need for this clearly means they felt the pain of slow builds too.
Earlier quoted context omitted.
If you don't have any external library (e.g. npm) dependency you're golden. Unfortunately, this means that you now have to write all your code from scratch, which is ok if you're writing a very light website, but it's unsustainable if you do anything non-trivial.
Plenty of npm dependencies are published as browser-compatible standard JS modules.
Earlier quoted context omitted.
prisma not having SQL JOINS for a ling time is how I know I should just ship it when it comes to my projects.
It's probably just me, but I read this sentence over 3 times and I still don't understand what you meant. Care to explain?
I meant that Prisma got so much traction despite not supporting JOINs early on.
And then there's me postponing projects because 80/20 doesn't cut it for me. I need to get each and every feature completed before launching.
Feel the need to push back against the predictable nay-saying in here. Announcing with Rust in the title is not because of a hype train, it's a way to communicate that this bundler is in the new wave of transpilers/bundlers which is much faster than the old one (Webpack, Rollup) which were traditionally written in Javascript and painfully slow on large codebases. While the JS ecosystem continues to be a huge mess, th…
As someone who highly values minimalism and simplicity in software, seeing another web bundler paraded around as if it's something to celebrate does not spark joy.