Don't make me think, or why I switched to Rails from JavaScript SPAs

I haven't even tried to setup dev environments for python, php or js on Windows. It is just so easy to use WSL2.

https://www.youtube.com/watch?v=y8OnoxKotPQ

Basically it comes down to magical behavior, and the fact that Rails has way too much of it. Syntactic sugar and DSLs are maybe fine for rolling out new projects, but become burdensome on large codebases. I was on a large project and found myself in goto hell where I literally couldn't trace through the code. It was relying on every magic trick in the book to make the code as small and cute as possible, but failed utterly to provide anchors in the code where "this happens here" or breadcrumbs connecting chunks of code. It was a giant hodgepodge of I don't know what. Really clean spaghetti code I guess.

Now, Laravel has its own warts, but they aren't conceptual warts. For example, the stack traces in Laravel are way too tall, with way too many factories and patterns in the vendor code. I feel that things like the IoC container were not implemented as well as they should be. The goto hell in Laravel happens around stuff like the bootstrap process, registering service providers, queuing, etc. They made some mistakes in scattering those things around instead of handling them in one central place. Pretty much all classes provide 95% of what you need, but adding missing functionality yourself requires learning the entirety of the package (in fairness, this happens with pretty much all platforms). There's a tendency for Laravel projects to not support helper functions or custom classes in a standardized way, so sometimes it's hard to find business logic. Not nearly as hard as in Rails though. But as a whole, I'd take conceptually clean interfaces with mundane implementations and no surprises over magical behavior any day.

Just to not leave anyone out - I wouldn't implement business logic in any Javascript framework. I feel that async basically makes it impossible to do it deterministically. I'm sorry that happened to Javascript and am still in mourning about it, because it had some advantages over PHP in how it treated associative array access with "[]" the same way as object member access with "." which could have been used in PHP to implement copy-on-write everywhere and really set it apart from all other imperative languages. Mistakes were made in both, and Ruby as well, that took them all in directions that I wouldn't have chosen.

I already have my own back end, but sveltekit is all about using their back end stuff. And their back end is 100% all in on serverless functions. If you want to write a more traditional back end and do something like grab private API keys when your service starts up, well sorry no easy way to do that, although there is an active git issue thread with people pretty much begging for the functionality.

Doing stuff like initializing logging libraries and passing them to models, or fetching API keys from secure storage buckets, is such a very common operation in any at-scale app, that I am beyond obscenely surprised sveletekit doesn't offer an out of the box way to do those things.

1. User arrives at a page where a real-time widget may exist. widgets/mywidget.js on that page.

2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers.

3. Done.

mywidget.js could be big and sophisticated -- a multiplayer video game, for instance -- but it is certainly not "strewn everywhere".