151–160 of 637 posts
SPAs are good for that, because you just have to develop it once, instead of 5 or 10 times for all platforms.
SPAs are bad for traditional websites that deliver content.
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.
SPAs only suck as much as we suck. Just admit that SPAs are like any other tool, and if we're going to swing back to apologizing for goto-statements (something I don't necessarily disagree with) then we can't at the same time act like SPAs are a mistake in and of themselves. We collectively continue making mistakes and instead of owning up to our collective lack of craftsmanship, we are blaming the tool.
Only when we shed the mindset that informs us that computer "science" is actual science might we then be in enough touch with reality that we seriously impose some standards upon ourselves to address our clumsiness.
I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side…
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 presentation and logic. The only state is its own. It does not handle an entire web app as a SPA, no Redux, prop drilling, it's just the idea of a reusable component as an HTML tag. Same with VueJS and all. If we restrict ourselves to that we're in the good path.
If there was already an HTML tag for your own specific problem, wouldn't you just use it in your traditional server-rendered app? A `` tag that does exactly what you want. Or a `` tag. We should create just those components, either in React/VueJS/Whatever or in vanilla JS Web Components, and live with the rest as we used to.
We're basically saying that some parts of our apps are too difficult to mix and match state management, and we should offload all of the state to one of the two sides. In some rare apps indeed all of the state should be on the front end, but the use cases for that are just not as big as they're made out to be.
I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…
Quoted post unavailable.
True, but irrelevant. I have written an OS GUI, including full file system support, in the browser that performs faster than native OS GUIs. My biggest learning from this is talking about performance in a job interview is the fastest way to kill the interview. Performance, like security, requires trade offs that deviate from comfort. If the common developer is insecure comfort is the only thing that matters.
JS hiring expects the following: React components, 2-6 weeks of JS practice, the ability to use map/filter on arrays, and CSS. If you overshoot that you begin to enter unknown territory that intimidates other developers. The better you are the less employable you become as the further from the bell curve you drift.
If you are wondering why this is or how we got here the answer is trust, or the lack thereof. In software there is a long standing bias: if you can see it visually its worth less. I have been doing this work for more than 20 years and that bias predates my work, so its been around for a while. Bias is continuously reinforced by the lack of standards in software hiring and the inability of employers to train their employees.
This lack of trust means that employers do not trust their employees to perform original work and likewise the developers don't trust each other. This is why absolutely everything, I mean this literally, is a downloaded NPM package, because the developers will trust an anonymous stranger to write original code before they trust anyone they know. There is all kinds of excuses to qualify this, of which some are bizarre and nearly all lack any kind of merit.
This is why its irrelevant what the browsers provide. Its baked into the framework, an NPM package, or ignored.
SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked. Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.
Not so. IBM mainframe systems (3270 terminal based) that ran most of commerce for a long time are basically the same paradigm as a web browser. Send a form to the smart terminal (GET), wait for the response with the field values (POST), send another form. In fact there are adapters that literally turn these applications into websites by translating the forms into HTML. Commonly seen when you need to do something like…
Earlier quoted context omitted.
He was just unable to follow and understand the trend, and thinks that therefore the whole industry made a MISTAKE :D
`
Earlier quoted context omitted.
> Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works fine, but then you get to browser navigation and you're screwed, because none of this works out of the box if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken…
> Where in this process did you need to start adding navigation via JS? Did that functionality really require JS, or was it implemented that way just because other parts are JS, and the trend was continued? Could you have used Stimulus controllers to manage functionality on the page itself, but when it came time to navigate to a new page, just done a basic browser redirect? In my specific example, the navigation itse…
> you need to hook into navigation APIs to handle backing into a partially-filled form after submitting to rebuild the UI to reflect the state before the user hit submit
Was this a hard requirement for the feature or just a nice-to-have? I understand why you'd want that behavior ideally, but it also seems the sort of thing that adds much additional complexity for a problem that isn't (at least in my eyes) severe. Having people re-fill things isn't too much of an ask, I think, and if it's something crucial, it might be better served with a preview page that allows additional changes. Or a "Make changes" link that redirects to a page that can load from the submitted state. There are easier ways to handle it than manually controlling navigation.
But yeah. If the behavior is a hard requirement from the business/product side of things, then using an SPA is no longer an architectural decision made for technological purposes, but is a feature requirement from beyond. And that's a whole different matter.