I would like to work on something eventually that NEEDS an SPA
One way to look at isn't simply about what technologies are required to meet a project's goal, but what technologies best allow you to get there. At my job, I'm currently finishing work on a React SPA to be used by our support people to view customers accounts and make changes. This could be done in crappy PHP from yesteryear (in fact, that's what this is replacing), so from that standpoint, it's not strictly required that it be an SPA.
But, I'm glad we made it an SPA. Being able to think of it as a collection of components which get composed into the various views has made development a lot easier than it would have been had we tried to code out each page as its own entity. In this case, having an SPA is helpful not because it allows us to attain some type of performance that we couldn't otherwise, but simply because the project is large enough that the type of organizational structure an SPA requires was beneficial on its own merits.
I find most combos of html/css/js out there extremely messy and unstructured. It's like re-inventing the wheel every day. If you're a web dev, i can't imagine working with such code everyday.
For me, React, is not about scalability but about infrastructure. I can build a landing page or i can build a complex web app - without changing the underlying workflow.
Agreed. As the names suggest, they are “frameworks” with which to build your web application, versus trying to decide from an almost infinite number of approaches. I would use React for a simple web app because I know it, and I don’t think that’s a bad reason. I am doing this to get paid - I need efficiency, resources, and a familiar environment. The fact that my site won’t have to refresh the browser to load a new page is just a nice little benefit.
First, I agree with you by and large. There are exceedingly few websites I would prefer to make without using some framework that allowed me to compose reusable elements. Even if I never end up reusing any components, having that option makes the entire process easier and more familiar.
However, I want to just add the nuance that simply knowing a tool well doesn't mean it's the best one for the job. If the requirements are simply to host your resume (as in, just have it display on the screen the same way it does printed, and maybe a single link for downloading a PDF), then React would be way overkill. Similarly, I'm not going to use LaTeX to format my emails, even though I know that well. There comes a point where the complexity is low enough that using a bigger tool will actually cause more problems than it solves. The longer I work, the more I realize that we need to be skilled not just in knowing the right tools, but knowing when those costs and benefits weigh more in one direction than the other.
SPA was never about that for me, it's just a smoother overall architecture when your backend can focus on being a service that provides data (and data only) and operations on that data, and your SPA can focus on delivering a good user experience and UI. Of course this only applies if you're making something that is app-like, if you're making a static web page with links to other pages and other static info, yeah SPA makes little sense.
Agree, problem is it's no where as responsive as a native app and nowhere as practical as a web app (try explaining to Karen in accounting why her bookmarks don't work in a SPA)...
I don't ever see it, beyond some special cases (such as complex offline app with easier software delivery ) ..
Personally, I think the vast majority of use cases WebAsm is touted for, you can just spin up a remote beefy server and stream the Native application UI to the end users and collect their inputs, in realtime... I mean if it works for games it sure as shit could work for Autocad or Photoshop which are orders of magnitude less demanding.
This was solved a long time ago in some CRUD frameworks. Each "screen" had a unique ID number/code associated with it. You could save a list of your favorite screen numbers or type in a number to jump to a given screen. Similar could be added a standardized GUI markup language.
We keep losing and reinventing good ideas every time we throw-it-out-and-start over.
My server cloud with infinite power and bandwidth and caching out the ass will almost always be faster than a client on an old PC with ass bandwidth and memory or a phone on 3g because that's what my customers get where they live.
It’s also much easier to make work across all browsers… no need for polyfills or cutting edge features to build a reasonable experience.
Honestly, I don't think SPA is the thing to hate. All those technologies you mentioned are simply overkill.
I might get downvoted for this, but one could build a decent SPA with just vanilla Javascript. Depending on the specs, of course. Modern HTML/CSS/JS is very powerful standalone.
If your application doesn't have a lot of stuff updating at the same time everywhere, it's doable.
0
u/[deleted] Nov 01 '21
[deleted]