In “reasons for going SPA on a greenfield project” I would add:
- Need for a mobile app is close on the roadma and there is an opportunity to build server code in an API first fashion.
You probably don't need a single-page app
431–440 of 522 posts
Re: You probably don't need a single-page app
#432Not very convincing. React was introduced in 2013 and angular 2 was created in 2015. The only server side rendering I'll be doing in the future is with the likes of nextjs or similar.
Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA, or SPA -> SSR is easy (via Gatsby/Next.js). The other direction though, seeing projects grow from SSR -> interactivity/SPA is usually a horrifying display of highly-coupled code spaghettification.
> Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA
Aha, by mistake you corrected your grammar! HNers cargo cult everything, including grammatical mistakes like "an SPA" ( see literally everywhere in this thread). Just say it out loud, "I start with an SPA", does that roll off the tongue? No, neither does, "I'm going to buy an sailboat". However, "It either needs to be a SPA, ..." is totally natural.
While this comment may not seem on topic/useful, it's a useful meta comment -- please don't take offense.
Re: You probably don't need a single-page app
#433Earlier quoted context omitted.
> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then…
I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make…
See also Stimulus [0], from Basecamp.
Re: You probably don't need a single-page app
#434Earlier quoted context omitted.
That's a hell of a generalisation, and it falls down pretty fast when you move beyond CRUD apps. You can easily end up with entire teams whose role is just to babysit Elasticsearch.
No, it doesn’t. Regardless of the backend stack, if you maintain both the front end and the backend, it is categorically less effort to only maintain the backend (ie. just run an API). Half as much effort? 3/4? I don’t know, maybe your UI is a man autogenerated swagger frontend and it’s (43/50) as much effort. It depends... but it is always less effort not maintaining an external user facing UI.
Well, what does your API actually do? If you're e.g. Heroku, your front end does almost nothing in comparison to the rest of your product. Why would running the backend of a globally distributed infrastructure-as-a-service company be easier than maintaining the front end?
Re: You probably don't need a single-page app
#435Earlier quoted context omitted.
SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database. I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.
Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
My experience is the opposite. The interface created in such a situation is the worst of both worlds.
Re: You probably don't need a single-page app
#436Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big…
As a user, I miss pre-SPA days. For all the negatives that SPAs were supposed to solve, there was one thing about those apps, and it's that they were predictable. These days, you never know whether you can even open a link in a new tab, or bookmark it, for that matter.
Re: You probably don't need a single-page app
#437All that complaining serves no purpose. SPA is just another tool in a belt. Where I think it shines is making rich apps that need complex flow and communication. This is where productivity is important and the process is complex and up until recently I would be advocating native desktop app. Now with advent frameworks that help me organize this very efficiently (I use re-frame/reagent with ClojureScript) I can create…
The complaint is that it's a tool that used much more often than is necessary or even advantageous. Just like that old saying about hammer and nails.
Re: You probably don't need a single-page app
#438I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped…
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. This is cute. I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet. What is 60mb c…
It sounds like OP was trying to make a beginner-level sample app in Node.js - is your .NET app of the same nature? Judging by the mention of SQL Server, it's not.
Re: You probably don't need a single-page app
#439Earlier quoted context omitted.
> My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. This doesn't seem like a problem of "MVC vs SPA". The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for examp…
You overlooked this part: > Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks
[deleted]
Re: You probably don't need a single-page app
#440Earlier quoted context omitted.
This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win. That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
Two teams sharing an interface means one team will block the other most of the time if a new feature always requires changes in the interface and implementation on both sides. Doesn't matter if individual development speed increases, overall project speed will suffer greatly.