Considerations about the tech stack and architecture

[cwellsx]

@ArtOfCode

One way you lose users, the other way you’re doubling the work you have to do.

Might there’s be some standard work-around or best-practice for that too?

There’s what’s called Universal React – for which there are several implementations, “Razzle” et al. – could that be relevant?

Am I wrong to imagine that it is widely used on public web sites now – which, proves there are no remaining technological barriers?

@ArtOfCode

even just custom JS that can do dynamic data pulls and page updates

Yes but then there are those two realms again – i.e. front-end and back-end – which you cited above as objectionable.

I’ve done that in the past using ASP.NET and JavaScript – but I did find it neater and simpler though, to have one source code realm, with React – so the code which updates the DOM is the same language (e.g. TypeScript), and the same library (React), and the same data types, as is used to create the DOM in the first place.

---

@ArtOfCode

Finally and most crucially, SPAs are not something that every developer is familiar with.

That might be the core of it.

Now quoting from another thread, Marc wrote …

@Marc.2377

More or less. As I imagine you are aware, there’s a wealth of existing SE “clone” or similar implementations, each with their own set of pros/cons. We have, since early on, decided that we will build something that is different in that it lasts . You probably won’t find much disagreement in that the current SE implementation works well. We want to do better . Obviously, I’m not saying “perfection from day zero”, but no, I don’t think we want to launch something to be embarassed about either because that might be our doom.

… do you know what that means? Especially “lasts” and “better”?

I imagine some of that is project governance and community relations – so not part of the software implementation itself – but are those, also, “non-functional requirements” for the software?

How does that affect the implementation?

Choosing the stack which everyone knows means you’ll be biased towards using the stack which people started using 10 years ago.

My theory is that the newer stack has become popular for some good reason – and yet it’s not so new as to be bleeding edge – and maybe it’s time to adopt it for some competitive advantage.

Writing for ASP seems to me more like driving a juggernaut than a sports car – oh it is feasible alright – not sure it’s the right size though.

Could it be that choosing it is a case of Nobody Ever Got Fired For Buying Microsoft? Which, 30 years ago was “Nobody Ever Got Fired For Buying IBM” (mainframes)?

I mean, Ok, you have to pick something, and any decision is better than none.

Apart from that, though, I don’t know why people think it’s the better decision – I guess I know ASP pretty well and only beginning to work with non-MS stacks – but there seems to be much less boilerplate to it, so it’s more expressive and flexible and productive – even though I was learning the React-related tooling and designing with it for the first time.

So I don’t really get the decision – why people assert confidently that ASP is the right choice for this project. Yes the MS stack was good enough was SE was first written. Is that (emulating that design choice) what you’re doing? What does “decided that we will build something that is different in that it lasts” and “we want to do better” mean, then? And if you want to compete, then, don’t you want a technological advantage (if there is one)? I’d like to know that – i.e. to share the vision.