411–420 of 533 posts
Earlier quoted context omitted.
You haven’t had to deal directly with JS on front end since Dart released over 10 years ago
Does anyone use Dart without Flutter? I've never seen it used separately.
Earlier quoted context omitted.
You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript. The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.
That's still state on the frontend, which the commenter claimed sites don't need.
Is this article comparing apples and oranges? For example > loading the entire homepage only takes one query [if you're logged out] You can do this with Next.js SSR - there's nothing stopping you from reading from a cache in a server action? They also talk about Vercel hosting costs, but then self host Rails? Couldn't they have self hosted Next.js as well? Rails notoriously takes 3-4x the resources of other web frame…
Yep! It'd be possible with Next.js. The difference is how it's organized. In Next.js with RSCs, we were fetching data for each part of the page where it's used (trending books, Live events, blog posts, favorite books). Each of those could be their own cache hit to Redis.
One advantage of Rails is the controller. We can fetch all data in s single cache lookup. Of course it'd be possible to put everything needed in a single lookup in Next.js too, but then we wouldn't be leveraging RSCs.
I tried self-hosting Next.js on Digital ocean, but it crashed due to memory leaks without a clear way to understand where the leak was. Google Cloud Run and Vercel worked because it would restart each endpoint. We have more (and cheaper) hosting options with Rails.
Earlier quoted context omitted.
If your axiom is ‘JS is fine’ then yeah. It isn’t, though. TS is much closer to ‘fine’, but still can’t avoid some dumb JS decisions.
I've been a professional programmer for ~20 years and worked in a variety of languages on a variety of different types of projects, and Typescript with Bun is mostly just fine. It lacks some low level primitives I'd like to have available for certain projects (e.g. Go channels), and the FFI interface isn't as nice as I'd like, but it's basically serviceable for for a very broad range of problems. You should still kno…
Earlier quoted context omitted.
I don’t understand your integration of performance and cloud costs here. “Deployment economy” is also new. Rails has a very strong track record of matching internet scale. Cloud is highly optimized for traditional server applications. From my experience with Next.js - this is the opposite. A lot of deployment components that don’t naturally fit in, and engineering required to optimize costs.
Quite simply: at certain threshold counts of users you will be forced to add many more cloud instances/pods running Rails than you would need running node.js (or Java or go or many others). But it doesn't stop at instances because this will also require more persistent disk / object storage, more logs, more alerts, more notifications from the cloud provider that instance xyz needs to be restarted (due to a firmware u…
Earlier quoted context omitted.
Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…
The curse of being an experienced developer is watching good things go away, and then get re-invented and everyone hails them as a major innovation without any awareness that this has existed for a long time. Someone will steal the good ideas eventually. And everyone will act like it’s the first time this idea has ever come up. I’ve seen it happen a few times now, and each time it makes me feel ancient.
As a side effect this reminds me how much I must not know what I don't know. It's a bit scary.
Earlier quoted context omitted.
I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.
Multiple times in this thread you have been taking the hardline stance that a framework is always necessary while stating that others are saying the same in the opposite direction. In reality, most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed. Further, being against a bloated framework is not the same as being against frameworks. Those…
Having been a web developer for a quarter century, I know how tempting it is (yes, for small projects) to try to just wing it and do everything without a framework, and I know what a tarpit that way of thinking is. If you disagree, then you were certainly welcome to share you own opinion.
Earlier quoted context omitted.
I would use a craigslist skinned amazon.
Really, what would you be looking to achieve? I suppose you could have custom CSS (e.g. via Stylebot) remove 90% of the elements and all but one of the pictures, but would that really make the amazon purchasing experience better?
Even the search box itself lags when typing because somehow the text input is synced to the autocomplete search?
/rant
Earlier quoted context omitted.
No, it’s footgunny and riddled with bugs. Most JS barely works and edge cases just aren’t addressed. I’ve seen undefined make it all the way to the backend and get persisted in the DB. As a string. JS as a language just isn’t robust enough and it requires a level of defensive programming that’s inconvenient at best and a productivity sink at worst. Much like C++, it’s doable, but things are bound to slip through the…
> I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact s…
In C++, there's only one null, nullptr. But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice.
It's not about complexity, although that matters too. C++ is certainly more complex, I agree, but that doesn't make it a more footgunny language. It's far too easy to make mistakes in JS and propagate them out. It's slightly harder to make mistakes in C++, if you can believe it. From my experience.
I keep hearing good things about Rails. What are the downsides, other than learning a new language and framework?
- The Global interpreter lock (GIL) in Ruby is less performant than async thread programming in JS (and some other languages)
- Rails creates a monolith rather than a bunch of independent endpoints. If you have a large team, this can be tricky (but is great for smaller teams who want to move fast)
- How Rails integrates with JS/CSS is always changing. I recommend using Vite instead of the asset pipeline, unless you're going with the stand Rails stimulus js setup.
- Deploying Rails in a way that auto-scales the way serverless functions can is tricky. Their favored deployment is to server of set size using Kamal.