301–310 of 637 posts
It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…
Earlier quoted context omitted.
What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does). SPA: 1. get html from server (1 roundtrip) 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip) 3. get ajax calls from server (1 roundtrip) 4. process answer from server + update page (not a roundtrip, but not zero) Vs traditional: 1. get html from server (1 roundtrip) 2. get resources f…
> For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately. This is literally a core use case of GraphQL. But you probably also want to fan out to preload all of the other user data in one API call: that's the whole point of doing it on the client. If you are trimming the handful of kiloby…
Can you link to a tutorial for this? I'd be most interested.
It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…
We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack.
It's rock-solid, performant, dead-simple and extremely productive to work with.
Why're we throwing away years of learning to build unstable, complex and inaccessible applications?
I'm still bullish on the potential for Web Assembly apps to overtake mobile binaries. And instead of Single Page Apps, we'll have just plain Apps that run in browsers.
Since I assume you know about it a bit more, what is realistically timeframe it could happen at best?
So Google/Chrome or Firefox are the only 2 players with enough incentive to make Wasm an Internet app standard.
Or possibly the next Wasm-first, cross platform browser will come along with a Wasm AppStore?
The browser natively handles internet connectivity, back / forward buttons, refresh buttons, URL management. Additionally, users have been trained to understand the responses, hit the refresh button, and use the back button. Browsers have gotten better at distinguishing between your internet being down and the website being down.
Good SPAs have to rebuild all of that functionality.
Earlier quoted context omitted.
The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…
Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective
I'd be very interested to hear how you solve this, or if it's less of an issue than people might think.
Earlier quoted context omitted.
Not after a post. If you change the form method to get, I believe this is the behavior. There are tons of good reasons to prefer this behavior, aside from just avoiding duplicates. Think of login forms.
Yes, even after POST. Why not try it, right here, on Hacker News. The comment form uses POST. I post this comment and go back and my text is still in the input box. In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.
It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…
Anyway, it's painful when a page won't load or it takes 10 seconds to load for no apparent reason. That's why profilers need to be used, loading indicators within the elements and also there's the trend towards frameworks with small footprints or even to go framework-less.
It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…