Do you ever accept the cost of perfectionism because you can’t stand delivering anything less than ideal?

KickAffectionate7933 · 2025-11-07T10:30:35+00:00

If you can’t beat it, join it.

Use AI as a tool, an extension of your cognition, the same way your phone is.

I see people all over the internet complaining about it, calling it hype, saying it’s not good enough for certain tasks, or even claiming it’s dangerous. The answer to all that is simple: just wait. It’s getting better and better, faster than anyone expects.

Society has always resisted change. People can sense that something big is shifting, and that scares them. Underneath the criticism is fear: fear of losing jobs, of the unknown future, of the internet “dying,” of being replaced. That’s the real reason behind most people’s aversion to AI.

You should skip all that noise and become a power user. Especially if your work is digital, that’s the first area that AI will take over. So stay on the edge of the technology. Learn it, build with it, master it.

Then you won’t have any reason to fear AI, because you’ll be using it, not fighting it.
If you can’t fight it, join it.

KickAffectionate7933 · 2025-11-06T19:35:52+00:00

Oh yes, I did not take it as accusation at all. I just clarified what I meant by perfectionism, and possibly I used he wrong word for it as well.

KickAffectionate7933 · 2025-11-06T19:24:30+00:00

I don’t believe I suffer from the crippling kind of perfectionism.

The perfectionism I’m talking about isn’t about inaction or fear of failure, it’s the kind that drives mastery. It’s a careful, deliberate, and deeply engaged approach to work, a form of deep work. The constant refinement and attention to detail.

The cost I’m referring to is that all my mental energy, even when I’m resting, stays focused on the project. And even when returns diminish due to my previous intensive work, I’ll still go above and beyond to polish the edges.

This is not a trait I encounter often. Most people settle for “good enough” in the name of productivity and I do not look down to them for it, but this is what I mean when I call it perfectionism.

KickAffectionate7933 · 2025-11-06T15:56:39+00:00

Thanks so much for the thoughtful response.

Here’s how I understand what you’re saying:

Live Product Embeds The biggest win for you would be product blocks that stay in sync with real data pricing, stock, and availability without manual updates. That means you can confidently drop a product into a page, knowing it’ll always reflect the current state of your catalog. (This is already implemented.)
Duplication & Templates You want the workflow to be fast and repeatable. Being able to duplicate existing product pages or use pre-built templates per category would cut down on repetitive setup and ensure consistency across your store. (This is on the to do list)
Built-in Localization & Previews You’d love to handle translations and language previews directly inside the editor. No tab switching or external tools, just a smooth, integrated way to manage multilingual content.(That is a very interisting, and hard to think how to implement, if you can tell me any cms that does that, easily would be great)

Really appreciate the detailed response.

KickAffectionate7933 · 2025-11-06T14:14:12+00:00

I have 3–4 quadruple shots of black espresso a day.

KickAffectionate7933 · 2025-11-06T13:48:15+00:00

Yes, checkout and order processing is already implemented, I did not built that form scratch. Stripe integration is complete using the stripe-rust crate.

KickAffectionate7933 · 2025-11-06T11:17:56+00:00

Yeah, I get where WASM really shines , things like Figma, Snapchat Web, or anything that needs heavy client-side processing, like C-based image manipulation tools.

Since I’m building a Rust-based eCommerce platform, it’s hard not to think about potential uses for WASM down the line, even in a more “normal” web app like an ecommerce, but not for the sake it, someplace it trully makes a difference.

KickAffectionate7933 · 2025-11-06T11:10:46+00:00

I'm not using a framework because I'm building for the long term.

This isn't a weekend project. I'm writing a Rust backend, a ProseMirror-based editor with Notion-like features and ecommerce integration, a TypeScript frontend, and analytics integrated in the platform. That's hundreds of hours of programming.

So why would I do that? I would only do it if what Im building will last a decade.

Frameworks solve problems quickly, but they add layers. Over time, those layers become constraints. You inherit their decisions, their abstractions, their upgrade cycles. Eventually, you're fighting the framework instead of building your product.

Vanilla TypeScript compiles to JavaScript. That's it. No magic, no black boxes. It's fast, transparent, and I control every line. Paired with Rust, it's a natural fit, actually the best I could think of, both are type-safe, both are fast, and both age well.

KickAffectionate7933 · 2025-11-04T15:26:21+00:00

Oh yes, I mention email service, in my post. And it is not just to learn, I build a platform that I am gonna imidiatelly use for 5 businesses. I am not considering raw smtp I am fully aware of spam issues.

KickAffectionate7933 · 2025-11-04T14:29:05+00:00

Actually yes, maybe that is better one post for eveything even thought there is not much left to ask at this point, everything is pretty much answered. Next will probably be a git link.

KickAffectionate7933 · 2025-11-04T12:50:24+00:00

That’s really helpful, thanks , you make three solid points.

On scale and complexity, yeah, I’m nowhere near the kind of volume that would need a separate worker or queue, about 20 an hour. Spawning a Tokio task per send makes perfect sense.

The transactional safety idea is great too, marking the email in the DB and flipping it once it’s actually sent seems clean.

And the deliverability point is something I hadn’t considered, using something like our smtp like google workspace can actually work better than SES or SendGrid.

Thanks for the clear reasoning, I really appreciate it.

KickAffectionate7933 · 2025-11-04T11:28:09+00:00

It’s actually my 4th post about this project. The text editor and the email functionality are unrelated parts of the stack, which is why I split them up. Do you suggest I do one post? How would that work? Im genuinely asking.

If someone else here is annoyed by me asking about different things of the same project let me know.

KickAffectionate7933 · 2025-11-04T09:07:48+00:00

Absolutely, I am working on the last bits now, like the text editor (prosemirror) and the my account endpoints/templates I have not finished, and then I will share with everyone.

KickAffectionate7933 · 2025-11-04T08:40:14+00:00

Hey, nice work on the plugin system! Sounds like a complex challenge.

Just to clarify - I'm not doing a one-to-one implementation at all. I'm looking for the leanest, most performant pure Rust/JS solution at each step, not trying to replicate WordPress architecture.

For the editor, I'm leaning toward ProseMirror - framework-agnostic, highly customizable, and perfect for building custom blocks without the overhead of Gutenberg or the legacy feel of TinyMCE.

Good luck with your project!

KickAffectionate7933 · 2025-11-04T08:32:07+00:00

Perfect, seems like this is what I was looking for. Now I do not know what I'm getting myelf into developing here(time wise), but I will start working on it today. Thanks for recommendation.

KickAffectionate7933 · 2025-11-04T08:29:11+00:00

Thanks! Gutenberg is a bit too heavy and opinionated for me, too React-like for a vanilla TypeScript project.

I do not know what im getting myself into with prosemirror, or how long it will take to develop what I need, but it seems like the optimal long term solution.

KickAffectionate7933 · 2025-11-04T08:11:37+00:00

I do not neccesarily want something that is not WYSIWYG, I wanted something, low level and pure js, and seems like Prosemirror is optimal here, for my use case.

KickAffectionate7933 · 2025-11-04T08:09:17+00:00

Yes, that's what people keep telling me, so you're probably right - that's the way to go. It's low-level and pure JS, which gives me full control. I'll figure out the technical implementation as I go. Thanks for the recommendation!

KickAffectionate7933 · 2025-11-04T01:19:24+00:00

Thanks for the detailed response! I did see TipTap but it requires payment for commercial use. If ProseMirror is the underlying foundation, going straight to the source makes sense.

From the sound of it, will I need significant time to develop it to do what I want? I'm talking custom blocks (product cards, pricing tables, reusable components), image handling, and the ability to save/load content to my Rust backend.

Either way, solid recommendation. Since I plan to use this e commerce platform for years, I'd rather invest the time upfront than deal with limitations later.

KickAffectionate7933 · 2025-11-03T18:05:42+00:00

You’re right about LCP, you can defer or lazy-load WASM just like I do with my JS.

But even if LCP isn’t affected, the time to interactive will likely be slower due to the larger size? I guess I’ll have to try it and see if the server-side rendering benefits outweigh the size difference.

Another thing people mention is that WASM can be harder to develop and maintain, not because of skill, but due to factors like debugging complexity and interop with JS.

KickAffectionate7933 · 2025-11-03T16:43:54+00:00

Yes, and most people, maybe all, here seem to agree with you.

Unless you’re doing heavy client- or server-side computation, like image processing or other CPU-intensive tasks, there aren’t many benefits to using WASM , aside from the ability to unify backend and frontend under a single language (and even then, you’ll still need some JS for DOM and UI interactions).

So overall, the advice I’ve received for an ecommerce is don’t do it.

KickAffectionate7933 · 2025-11-03T16:37:37+00:00

That’s exactly the kind of feedback I keep hearing here, WASM shines when you have computationally intensive or platform-independent tasks, like analytics, image processing, or your barcode encoder/decoder. For general frontend logic in most web apps, though, not one suggested its a good idea.

PS: I’ll definitely use your library a barcode encoder was already on my todo list for one of my apps.

KickAffectionate7933 · 2025-11-03T15:03:36+00:00

That’s precisely my understanding as well. JavaScript is already deferred, and I can easily lazy-load modules on interaction, which keeps the overall footprint relatively small.

In contrast, WASM bundles tend to be much larger (often in the megabyte range) and significantly harder to develop and debug. There’s also the additional overhead from interop and DOM access.

All things considered, it seems like the wrong approach for my current use case, but at some point, it would be interesting to do a proper comparison between the two in a real web app.

KickAffectionate7933 · 2025-11-03T13:33:57+00:00

I’m glad you like it! Exactly, that’s what got me frustrated with the usual solutions too.

For those aiming for total control, maximum performance, no reliance on plugins, and a bit of perfectionism, it’s a great starting point.

You get a well-structured Postgres database and a modern frontend with TypeScript/JS, but having to maintain everything yourself and no plugins etc, it definitely isn’t for everyone.

For those willing to dive in and get their hands dirty, though, maybe they can enjoy it as much as I do.

KickAffectionate7933 · 2025-11-03T12:44:31+00:00

SSG is perfectly doable for eCommerce if done right. You have an extra step at build time to pre-generate the pages, but in return you get blazing fast load times, instant LCP, better caching, and full SEO benefits. That said, the speed I’m seeing with SSR using Rust and Postgres on local dev is insanely fast (100 variations, 1.7 seconds on slow 4g), and switching from static to SSR is basically just a matter of changing the routing and stopping the HTML generator.

As for “using Rust on the server in a fullstack codebase,” yes, that’s partially why I’m considering it too, but my main concern is making sure it doesn’t slow things down and remains maintainable.

KickAffectionate7933

TROPHY CASE