Aren’t some of these concerns addressed by using css only solutions for things like drop downs and animations? JS has a clear role in web apps but it is probably overused for things that don’t really need it.
stevensonmt
harmon25
I think one of the bigger arguments for something like React, is the very composable and reusable nature of the components. Attempts are being made for similar APIs in LiveView though which might open up the door to some interesting LiveView component libraries/toolkits…
1
LostKobrakai
If those things shall be properly accessible you need JS. Most of the css solutions – while working – are just hacks.
1
stevensonmt
cnck1387
dorgan
I’m already seeing real benefits from being indexed in search engines, it’s not about scale but visibility. As a content platform, SEO is crucial. It doesnt even have that much to do with scale. Not having a worldwide scale doesnt mean you shouldn’t care about your content being discoverable.
What I’m pointing out is that SPA have their drawbacks. Business apps are also not universal. Of course you will make your desicions based on your target and use case . What I’m talking about has to do whith this kind of pain points:
Once you need to serve content that can be indexed and be interactive to users, things get muddy. I don’t want to run a node server to do ssr or go back to being an spa just because the content I serve also has a fair degree of interactivity. And the alternative has a lot of cognitive load derived from the constant switch between Phoenix and js, which is less than ideal.
If your audience has capable devices, which is not the case in many parts of the world.
0
LostKobrakai
harmon25
Yes this is true, but we can probably agree that the vast majority of web apps are not public, and tools built for internal or business purposes with a very small userbase. And possibly sensitive data that has the exact opposite requirement…
This is also true, and if you are in a developing country and building something for say the government, then yea it might be a disservice to your users to build an SPA. But, will the same be true 5 years from now? This depends on what grows faster, complexity/size of SPAs or availability of decent compute device’s + connectivity in the developing world
0
AstonJ
Something I think I am leaning towards doing is having a read-only version of the site shown to bots/non-JS users - like what Discourse does (if you turn off JS you’ll see what I mean). This isn’t something new mind, vBulletin was doing the same thing over a decade ago and out of all the forums back then they were almost always consistently ranking higher.
When I think about how I want to build apps moving forward, I think I want to separate, with different versions for no-js, desktop web users, mobile web users, mobile app users, desktop apps etc. It’s reached a point where these are now sufficiently different and a simple responsive site isn’t really going to do them all justice. This is why I was drawn to Dave’s Elixir course so much - you build the app in Elixir and then use Phoenix for the web layer (or even multiple layers) etc. (There was a good discussion about it here.)
This is something I am thinking about more and more too.
I am reserving judgement for now tho. I am going to finish learning Svelte and then re-evaluate how I feel and how I am think I am personally going to build apps moving forward. Will definitely be keeping an eye on these threads in the meantime.
1
harmon25
I think you should give React another look also, its functional approach and simplicity really shines when combined with Elixir - the context switching between JSX ↔ Elixir is not bad at all. (its honestly no worse than writing eex,leex templates…)
I pretty much only use map, reduce, filter and relatively simple string manipulation in JS - all of which is immutable and feels quite a bit like piping stuff between Enum functions. And event handling is just passing around simple function references, to onChange, onClick etc props…
As long as you use arrow functions - problems with this essentially disappear. I do recommend understanding why though.
You can get very far with just react-router, and setting up React with phoenix is 1 additional babel config/plugin, do not even need to touch the webpack config.
Couple other recent additions to react, like Hooks - really changed everything.
Drop something like Blueprint in the mix - and you can have a damn near production ready prototype in a day or two…(it comes with a built in hotkey API that is decent) NVM it uses a decorator…they need to add a hook API…
Another package that covers all data fetching and global state concerns is react-query. Have not actually used it, but am considering it for the React integration for whatever Redex/LiveData become..
recoiljs also deserves an honorable mention - if you do need global UI state its a pretty nice way of achieving it, without complexity like Redux I have also not used it but came from some facebook engineers so should be OK…only problem is they use the term Atom - which is very much NOT the same as an erlang atom…
React performance is something that is improving with each release - it might not be as fast as Svelte - but its unlikely svelte has any room for improvement - the react team has been working on interesting things like concurrent mode - when that becomes stable - lots of large React apps will be faster with just a simple npm update This all kinda ties back to the huge amount of engineering that has gone into it - if SPAs are a naïve idea - probably would have realized by this point we were just digging ourselves into a deeper and deeper hole… OR maybe we just don’t realize it yet 
1