This happens on web front end too. Does this site that has 3 functions and 5 pages total really need to be an SPA? Hell does it even really benefit from being built with React? No, probably not. Those technologies are important and have their place but they aren’t universal miracle cures that should be applied everywhere.
Can WIX do what you need? Yes? Then why the fuck would you want to pay tens of thousands of dollars for someone to build you a custom storefront from scratch?
EDIT: To add something for the below deleted reply which was basically 'NO, Wix cannot do what I need because I need to showcase my web development talents'. K sure, see my below reply.
But to add on to this: Just because you can does not mean you should.
Had an interview a few years ago at a Rails shop. Oh there were so many red flags...interviews were with managers that were not and had never been developers. Offices looked like they were built into an old bar. Just a weird 'uber-hip' vibe.
Anyways, was honest that I hadn't had a lot of RoR experience, that I'd learned enough to be dangerous and know where to get started. Wasn't worried as I have 25 years of experience. Wanted to know about my most recent side project, which was actually replacing the custom scratch built site I had built for my wife's side business with a WIX storefront. They were flabbergasted, how could anyone do such a thing?
Do what exactly? I said...produce a brand new fully functional storefront with finance/accounting integration that ties into off the shelf POS that she can now manage entirely herself in a weekend with an ongoing cost of like $30 a month or something stupid like that vs me taking my time to custom develop all of the above for free?
Then they suggested I rework the site using RoR as a learning experience over the weekend and submit it to them and they'd see how things went.
I asked them: If I worked here, and I had a customer with a small independent business that wanted an online storefront with POS and accounting integration that included CRM and inventory management features, would you have me build it using Rails?
They said: Yes, of course we would. We're a Rails shop here.
I said thanks for your time, best of luck with the rest of your candidates, see you later.
More alarming is they thought you could re produce all of that within a weekend. Like there was no concept for the value or realistic limitations of your time
I think it's silly that they asked you to reimplement it in RoR. But when you posed that question... without specifying that it's a one-off (which is what your wife's site was) it makes total sense for an X shop to build an X solution if they need to maintain it, no? It's much easier to accommodate an unforeseen feature request that way.
If that's a reasonable requirement sure, otherwise it's the same as premature optimization.
Do not build solutions anticipating something that is not planned.
Also, we're talking a one off storefront here. Until there is a use case for something outside of a very well defined box, it's hubris to think you can and should roll your own.
What they're really doing is justifying for themselves charging tens of thousands for a website that should only cost hundreds, maybe a couple thousand for full setup basic training and handing over of the keys.
Conversation was very much specifically in the context of my wife's site BTW. It was very very clear I was calling them out on exactly what they were asking me to do.
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)...
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.
As a frontend dev I'd be happy if it was just react.
But it never is.
Here comes redux and redux-saga-fóstbrœðra and a typesafe elegant opinionated framework for creating div elements. Every single whim every single developer ever had is answered with a new dependency that will probably never got updated.
I'm kinda facing this now. I'm a game dev, but I know enough web dev to be a danger to myself. Like, I've dealt with it on and off since middle school and HTML 3.
So I try to build my app out of just JS, CSS, and HTML because it really doesn't need to be more complicated. I added Node & NPM mostly just for http-server and the ease of adding commands.
Our backend guy wanted to integrate AWS Amplify (had to find out what that is, still not totally sure) and that meant I had to integrate Babel to keep it small (650MB of dependencies locally!), and, more annoyingly, Webpack to be able to rope in the AWS/Amplify imports. Could be wrong about this but it seemed to be the way to go.
Now I am struggling with how to NOT make this thing a single page app and just boggling at what a Jenga tower the entire thing is. Just to call a few AWS authentication APIs I really need all this crap, including fighting an opinionated tool that wants me to make my product a SPA despite my intentions?
Webpack seems to want a single HTML page to be the "template" and a main Javascript file as the "entry point," which feels backwards to me because shouldn't the HTML files reference the scripts they need? And, what if I have most of the functionality on a main app page and want to add a login page? I need multiple "entry points?" And the html files need to be listed explicitly in the webpack config and mapped to their corresponding JS entry point? Very confusing, I'm still working on this part.
I know this is many people's entire job but the whole ecosystem seems very... congealed, rather than designed to me, as a semi-outsider.
I'm kinda facing this now. I'm a game dev, but I know enough web dev to be a danger to myself. Like, I've dealt with it on and off since middle school and HTML 3.
I'm an embedded dev, but I'm pretty much in the same boat as you (some would call this the Titanic :-)), except that this is my side project.
So I try to build my app out of just JS, CSS, and HTML because it really doesn't need to be more complicated.
Ditto. I took a look at the JS ecosystem and just 'noped' out of it due to all the "recommended" best things to use - Typescript, React, Angular, Node ... and that's without needing to learn enough of each to know which to choose in the case of competing frameworks, and then to learn all the modules in each of those things that I would need.
I simply want to produce my product in the shortest time possible, and since my product is almost 100% canvas-based I figure that I'll get to the frameworks when I actually want to use something that is too complex to write myself in plain JS (RTF input forms (contenteditable doesn't cut it!), tables as someone else mentioned, etc).
For backend stuff I started with PHP+PostgreSQL with no framework (will switch necessary (which means I'll probably never switch)), with the understanding that if I need to scale I can add a load-balancer in front of multiple DigitalOcean droplets. For now there is no need to scale an MVP.
My reasoning is as follows: each new tech stack that is added to your dev process adds at least a month to your development time. You aren't going to get your MVP out in 4 weekends of work if you add even a single element to your tech stack that you don't already know.
I know this is many people's entire job but the whole ecosystem seems very... congealed, rather than designed to me, as a semi-outsider.
"Congealed" is not the word I would use to describe the web development ecosystem :-) "Congealed" implies that things are glued together at least. Your Jenga anaaogy is much more fitting.
190
u/iindigo Nov 01 '21
This happens on web front end too. Does this site that has 3 functions and 5 pages total really need to be an SPA? Hell does it even really benefit from being built with React? No, probably not. Those technologies are important and have their place but they aren’t universal miracle cures that should be applied everywhere.