6 ms·
I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify y
by peteforde 8y ago
I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it.
In this thread, there are several claims that it's impossible to write well-organized jQuery. That sounds an awful lot like dogma to me. Also, your inability to write well-organized code says more about your coding and team-management skills than it does about any one approach. Any tech is only as good as the team using it.
A few years ago, Sam Stephenson (who originally wrote the Prototype library, before jQuery was a thing) gave an excellent talk on Turbolinks at RailsConf. I recommend the whole talk (turn it up to 1.5x speed, of course) but at 4:12 he does an amazing job of showing how the SPA path leads to insanity.
https://www.youtube.com/watch?v=SWEts0rlezA https://www.youtube.com/watch?v=SWEts0rlezA
Here's a mental exercise for you: the next time you start a new project, instead of deciding which SPA framework to use, start with an assumption that an SPA is wild overkill for the first iteration of your application - especially if few people on your team have working expertise with the SPA in question. Then see if you can argue FOR the tech. It's much harder to justify something you don't need if you start with an honest conversation about how you probably don't need it. (This works for throwing out CDs, too: start with the assumption that they are all garbage, they all go. Then force yourself to make logic-based arguments for each one you keep. Your outcome will be night and day from if you start with everything in a keep pile.)
- divs1210 8y agoSounds like you haven't been introduced to reagent. https://reagent-project.github.io https://reagent-project.github.io
- y4mi 8y agosounds like you didn't actually understand the parents point.
- peteforde 8y agoOkay, I admit it: I honestly can't tell if you're joking or not. I think that you're joking, but if you're not joking, well, we have different definitions of simple.
- divs1210 8y agoI'm not joking. Spend some effort. Challenge me. You build a UI in your favorite framework. I'll use reagent. Document the code. Compare the code then.
- peteforde 8y agoDude, I've got work to do. You threw down a URL to a framework I don't know that is apparently similar to a framework I don't use and runs on Clojure, which I don't work in and none of my codebases run in. You did that with no context or even taking the time to explain why I would do such a thing. Objectively, there's nothing simple or expressive about the samples on their homepage. Their demos are simplistic (todo?! seriously?) and do nothing to convey why someone would express a complex web app in this manner. It seriously looks like Matrix code to me.
- divs1210 8y agoSo just because you don't know German and I ask you to read some German text, you will say this looks super complex, even if it's a simple line saying "Good day!". Wow! Indeed our definitions of simple are different.
- cm2187 8y agoAs a user my main beef against SPA is that most of the time they break basic browser functionalities, like the ability to open links in a new tab, or using the back button. When the UI doesn’t simply break with part of the content off-screen.
- thesephist 8y agoHaving built some SPA's, I'd argue that at least those two things that you mentioned are the fault of whoever built bad SPA's, rather than issues with SPA's as a whole. It's possible to build an SPA that works well with the browser controls because modern browsers expose a lot of their functionality to JavaScript (like it or not). You can use <a> tags for buttons and links in an SPA (and keep the link functionality) -- you can just intercept the clicks when the link is being opened in the current tab, and you can always hook onto pushState/popState to make the back/forward button work.
- temporaryacc62 8y agoWould you say Youtube works better now as it is fully SPA?
- fny 8y agoThere's an army working on YouTube, and it has the traffic levels to justify the investment. They can actually put in the required effort to ensure the application functions seamlessly and meets accessability standards.
- Rjevski 8y agoIt does not. The SPA is so sluggish I’ve learned to just force a page refresh after clicking on anything because a full page load is actually faster than their bullshit SPA.
- acdha 8y agoIt is an issue with SPAs as a concept because part of that concept is that you’re taking on responsibility for things the browser traditionally did for you. That’s not a bad thing but it’s extra work which someone has to be responsible for, similar to how e.g. using a complex custom widget means you’re on the hook for accessibility rather than the browser vendors.
- GordonS 8y agoAt my day job, I mainly build web apps for enterprise customers, and for maybe 90% of them we use ASP. NET MVC or ASP.NET Core MVC, with a smattering of jQuery and vanilla JavaScript on the client side. This is a tried and tested stack that works well, has a huge ecosystem, and has great development and debugging stories. There seems to be an awful lot of devs now that only know and use JavaScript, consider server-side technologies to be 'old skool', and prefer to use whichever SPA library is the new hotness - but IMO, most web apps just don't have UIs that are complex enough to warrant using a SPA.
- emodendroket 8y ago.NET is just as well suited for SPAs as any other technology.
- pier25 8y agoThanks for sharing the video. It's really good.
- noxecanexx 8y ago+1 for the last paragraph. I used that technique to quell my desire to use event sourcing everywhere
- mercer 8y agoI generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative server-side first approach. That said, it really feels like a chasm that quite often I choose to cross simply because it'll be easier down the line. I've been bitten more than once by server-side-first projects where going full-on client-side with the server-side as an API would've probably been better. Whether it was because I needed a mobile app to communicate with said API, or whether the complexity ended up being more of a client-side thing, the result was often that I had to focus on the back-end as as API and go for the full complexity of a front-end app anyways. I'm enough of a fan of my preferred back-end languages (Ruby, but mostly Elixir these days) that I try to find ways to keep the complexity there, but truthfully I often opt for going for the full complexity of a client-side JS/TS stack because I'm likely to end up needing it eventually anyways. I've looked into things like Drab (https://github.com/grych/drab https://github.com/grych/drab), but ultimately there are many reasons why 'going with the flow' seems like the better solution (even if just because it's so much easier to find JS devs than Elixir ones). So far I'm not confident enough to make any sweeping statements, but from that lack of confidence I tend to opt for the 'safer' option, which seems to be the SPA route much of the time.