I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this...

Doesn't matter, so don't let it matter to you.

When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way.

I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new.

When that happened I was often able to influence the direction of the work.

All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon.

You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome.

Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.

It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career..

Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one.

Not everyone can spend hours at home to keep up with the industry.

I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them.

I politely declined the position.

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 example. You'd experience the same pain.

The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.

> 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

I predict a bigger react ecosystem. The slide of vue but the raise of the Quasar framework for apps. The rise of Angular once again.

I still can't quite put my finger on why Angular 1 and Vue rhyme, though. It's common wisdom that "If you know Angular, you'll pick up Vue quickly", and it seems to be true, but nobody has ever explained to me why. Is it the state management? Reliance on viewmodels? How they're more complete systems out of the box and can be reasoned about holistically? Help a girl out, HN.

FE is a vibrant ecosystem and the tooling, in my opinion, is some of the best I have worked with as a SE.

We have one guy in the office responsible for all of it, as warm bodies with backbone experience are impossible to find. However, should we decide to employ remote workers, we can easily find developers with backbone.js experience from Romania, Lithuania, India, and Pakistan who would work for a pittance and be grateful for the opportunity.

For your example I'd call it "squares" not because I don't hate it, but I don't think squares has something to do with "component"

Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.

There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.

But I agree, that seems to be my impression. Single Page Apps allow higher quality User Interfaces (if done right), though they do require more work.

But if the comparison is with more traditional SSR sites, React and Vue are also not doing everything the back-end was doing before.

Compared to client side rendering discrete web requests with minimal templates; you usually get much better separation of logic, view, and code than the typical serverside solution.

There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.

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.

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.

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.

I think making information usable is hard. This means that the burden of the development falls on whatever is making the information useful. If you simply can query an API and get stuff back that's valuable because the data is already processed, UI is pretty easy (aka Google). If your backend is returning raw data that needs to be organized and displayed, and users need to be guided through complex processes that are just simple CRUD operations server side, you have a much harder UX/UI challenge. Most things fall somewhere in the middle.

If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA.

Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.

On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.

The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...

Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them.

But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together.

With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.

1. One language - JavaScript

2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing)

3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations

One language, one repo, easy & consistent API production/consumption, no?

Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions).

The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong.

I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.

You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-starter-kit.js.org

There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary:

> Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity.

It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile.

[0]: http://entity-systems.wikidot.com/

If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...

It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want.

We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.

I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner.

Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.)

Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.

Known: we’re definitely rewriting it in two years regardless of this CEO feature

The feature probably isn’t that complicated anyway

Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.

But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside.

I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.

The key being bad programmers dont isolate concerns and good ones do.

MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic.

Clean separation of frontend SPA and backend API made both sides simpler and more robust.

I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.

The key is to design the DTOs (which API endpoints are based on) starting from the API consumer perspective. Business logic on backend is responsible to deal with mapping of DTOs to the domain models and in turn to data access layer models.

This results in most DTOs being "flat" and easy to consume by client.

It sound as though the application was a suitable candidate for an SPA and should have been developed as one to begin with?

We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it.

While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc.

The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. 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.

This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=272...

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 process the result and do something (update a table, display a message, redirect, whatever).

I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders.

You can find an example of this technique here[0]

[0] https://github.com/jbogard/ContosoUniversityDotNetCore

They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?"

So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves.

Recently, I saw Turbolinks [0] which looks like the same concept with way more panache.

[0] https://github.com/turbolinks/turbolinks

[0] https://stimulusjs.org/

Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.

[1] https://intercoolerjs.org/

For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails.

But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking.

So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.

I think the real issue you are dealing with is what others mentioned: rebuilding something from scratch burns a ton of people-hours and money. Asking a bunch of rails developers to lean into FE development is a recipe for animosity and to me it shows in this post.

Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.