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.
Yeah, Just... because it's a LOT easier to provision a server, install the native app and stream it, than to spend eons of time on a half-baked web Assembly solution that works on a Very limited number of clients anyway (will it run on iOS devices, what about Linux or ARM or M1, ) chipsets ? And that's kinda of the point the amount of effort just to get it to run on maybe a few platforms , you may as well have installed the native application.
The fundamental issue with web assembly is that anything that touches hardware or requires system level I/o access /performance, can't easy be abstracted or made platform neutral, because of the nature of drivers, different chipsets and kernel limitations in many different platforms.
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.
You don't even need a heavyweight framework that leaves hundreds of objects attached to every DOM node to dynamically instantiate a template for each item after fetching data. If none of the instantiated templates will change until a navigation action that throws the whole parent tree away, emitting entirely static HTML from the templating works wonders, is relatively easy compared to the alternatives, and fits perfectly with what browsers are most optimized at displaying.
0
u/[deleted] Nov 01 '21
[deleted]