Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)AS
Posts
0
Comments
70
Joined
2 yr. ago

  • SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.

    90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.

    Unless your web site needs to work offline (it probably doesn't), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don't need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).

  • This is the correct comment.

    Martin Fowler called them sociable tests. The only way to properly test your units' behavior is to pull in their dependencies. Isolated tests are useless, brittle and slow to write.

  • Oh wow, aren't you a cranky bitch. I didn't say you "should " do anything, I linked a tool I've constantly been told good things about.

    I bet you’re the type to follow the docker install instructions*, arent you?

    You know what they say about when you assume, you turn out to be an ignorant dipshit.

  • It's a form of Black-Box Testing, essentially you want to validate expected behavior. Implementation can change, but your outcome should remain the same.

    This is a big target for Test Driven Development, since your first step is to write the test with the expected outcome, then you write the most basic implementation, and when you can verify the behavior, then you are free to re-factor to improve implementation knowing your test will tell you if the behavior changes with each internal change.

  • I was there for the first wave of SPAs, I even learned angularJs and Knockout. It did feel like a major atep forward, being able to make highly interactive applications. However, things quickly went off the rails when the tools stopped being about managing heavy client state, and became the default for everything, even when it ment using JavaScript to build extremely basic functionally browsers did natively with html, but extremely worse(e.g. navigation). The modern Web really is a victim of hype and trends.

    Unless your app needs to work offline, or you have to manage dozens of constantly changing client side data points concurrently, your site doesn't need to be a big heavy js framework. My rule is if it looks like Google Maps, you need a SPA. if it looks like Gmail you need REST/HATEOS. and if it looks like google's mainpage, you need a server side rendering.

    At some point you might see the light, and go back to making your websites simpler, but Im not hopeful. Until then I'm building the majority of things with HTMX and alpineJs.

  • You couldn't pay me enough dollars to cover the therapy caused by having to maintain the "flexible" code that added complexity and abstraction for a single use case that was never expanded to handle more.

  • Ignore the weird tribalism over the languages other people prefer to use.

    Just one thing to keep in mind about VB.Net, Microsoft considers it "done". Active development is done, yhe language won't receive any new enhancements anymore, so all the cool new C# features (like pattern matching) will not be back ported to VB.Net.

  • Not testing is crazy. Once you realize you can actually refactor without ever having the fear you've broken something, there's actually opportunity to make rapid improvments in structure and performance. Taking 2 minutes to write the test can save your hours of debugging. Unless you're building a throwaway prototype, not unit testing is always the wrong choice.