I would favor an API over sending Razor-generated HTML. This both reduces development effort and allows for multiple frontends.
The API would be executing common REST requests. Responses would be in JSON or any other common object notation (I think we have decided for Google’s “structured data” or the like?).
Site performance may benefit as well - a common prejudice against such an approach is that it would increase download size. This is not necessarily true. Highly repetitive HTML most likely results in a higher download size than the non-repetitive object notation we use.
Furthermore, using client-side JS allows us to take advantage of dynamic loading and the like.
I believe that on most common, and even budget devices, performance wouldn’t drop noticeably if going with this approach.
Scrapers etc. will also benefit: They can directly access the API and needn’t query semantically useless HTML which is mostly visual design.
First, almost nothing has been implemented yet. In my opinion (1), switching the Tech Stack is still feasible.
I don’t like C# either, mostly because of the horrible documentation. However, I don’t know any better option. I think PHP or Node.js would be terrible, Go has awful error handling and I’ve never used Ruby for websites before.
Making one of these single page applications, where everything is requested from a REST API, is very difficult to get right. Most of the time it hinders productivity because your client has to communicate with the server after each click. This can be done properly, but again, it’s difficult go get right.
I don’t understand what you mean by “multiple frontends”, a mobile app? If that’s what you mean, I don’t see much of a use for it, just make the website responsive.
(1): Notice that I haven’t implemented anything myself, yet.
By multiple frontends I mean that backend and frontend are properly separated.
We will have one “default” frontend. But users are free to implement their own websites, making API requests and displaying them the way they want to.
I don’t like C# either. I’d be throwing Java & Groovy into the mix. Rust looks promising as well.
I do like it if a website provides an API, however, I don’t see why this is needed for Codidact. I don’t see a scenario in which it would be useful to e.g. embed a question into another website or something of the sort. The only other use I can think of is a mobile app, but I think there was the consensus to make the website responsive (citation needed), thus a mobile app seems redundant.
Java is such a “powerless” language, it lacks basic abstractions and it carries much outdated stuff around. Rust does look promising, not sure if many people know it though (that’s not a language that one can master in a few days).
I don’t like C# either, mostly because of the horrible documentation. However, I don’t know any better option. I think PHP or Node.js would be terrible
I support moving away from C#. I think Node.js is a really good option. Many more people know JS and can contribute. JS is also really quick and easy to learn so we can definitively get more contributors.
The biggest argument made against node is scalability. Node.js can scale! It is used on many website that get more traffic than Stack Exchange and works extremely well. Node.js doesn’t do as well when heavy CPU work is involved. For example, server side photo or video editing. But we are not doing that. I believe Node.js is the right route.
I can also link tons of articles talking about how Node.js does scale and works well. I can also link a bunch of open source websites and close source websites who use Node.
We’ve had this discussion elsewhere (several times, actually). I don’t seem to be able to find an easy link right now, annoyingly.
Using an API requires client-side JavaScript, which a significant proportion of users still don’t have enabled by default. That’s an instant cut off for a proportion of our audience, whereas rendering HTML server-side has no such drawback.
It’s still possible to change our tech stack, but not to client-side generation.
First things first: there will be a REST API that allows anyone to develop a frontend in whatever language they want.
The decision to implement the frontend using the Razor engine was made following early suggestions and careful consideration from senior developers from our project, weighing in the pros and cons of alternative approaches like dynamic, JS-based frameworks. Most of these discussions reside in our Discord server and with enough patience and searching skills one can find and evaluate them.
Hint: these search terms returns some of my manifestations about this (and their surrounding discussions ofc): from: Marc.2377#8601 razor or from: Marc.2377#8601 frontend (1, 2, 3).
This decision is now established for Codidact and we’re now past the point of revisiting it, I’m afraid. Those who find this to be a deal-breaker may look around for existing alternatives that follow a different design choice - they certainly exist, or experiment with forking our core implementation and seeing how it goes.
My 2¢ (and I’m sure of having said it many times, in different forms): Development can go faster, not necessarily because a JS/TS frontend framework allows for faster development, but by the fact that way more people are familiar with these languages - which, in my *humble* opinion (I mean it), is not necessarily a good thing) than with C# and particularly Razor. But I’ve seen enough code in the wild to assert, close to 100% certainty, that the end result will not be near as good.
We’re aiming for polished, professional “works well everywhere” and especially maintainable.
Razor it is. (in other words: Razor is, currently, a great fit. A better choice might present itself in the future. I look forward to that day. But in the meantime we’re well covered.)
What I notice right now is that our devs are not okay or are not happy with C# (including me) and would want it to change right now because if we didn’t then we won’t be able work with the full potential. I mean we have to build this and if we are not happy with our tech stack then how will we even be productive?
We looked into this when we first had this discussion; again, I can’t find the link right now, but it’s a significant enough proportion that we can’t just dismiss those users. We need to offer a good enough experience without JS enabled that those users trust our platform enough to enable JS for it.
I am building a node.js proof of concept. If anyone wants to join me they can. I will post the link soon. I am not trying to compete with Codidact in anyway. Ideally Codidact would adopt this.
That was a discussion 2 months ago, and people were happy with it.
And development has started now.
The people who are not happy with it are probably newer members here.
However, if we change the tech stack every time a new wave of members from another language comes in, we’ll constantly be designing the perfect system in the sky.
At this point, the only reason for changing the tech stack should be because some deal breaker is found. (Which is improbable because of all the ground work that has been done already).
Not because a couple of members would prefer a different tech stack.
Using an API requires client-side JavaScript, which a significant proportion of users still don’t have enabled by default.
This is not accurate. ES5 is widely supported. It should also be noted that those running IE 8 or lower are probably not interested in using Codidact. We can’t support everything - that’s simply not worth the development effort.
I am not opposed to generating static HTML. But it shouldn’t be the “default”. We should first build a REST API and then - eventually - search for a way to generate static pages.
I did not intend to start a discussion about changing the entire tech stack, but at the very least Razor.
@jbis I might want to join you. I think that the Codidact documentation & specification is certainly good, but I don’t like the direction the implementation is taking.
I think we should have multiple implementations. A NodeJS dev will probably never contribute to the C# implementation and vice versa. So they should be able to each try on their own, and in the end, we can chose the “best” implementation and officially “advertise” it.
Not enabled by default doesn’t mean the browser doesn’t support it. It means the user doesn’t allow it by default.
I usually have JavaScript disabled. Yes, it means that some web sites won’t work out of the box. Some (like Twitter) will offer me to go to a different interface that gives me the content without JavaScript. Some will just display a white page or a bunch of links to JavaScript.
There are enough web sites that work well enough with JS disabled. There are a few where it is obvious that JS will be needed (e.g. there’s AFAIK no way to show video without JS), so if I know that the site offers that type of content, I’m more likely to enable JS for that site. But in general, if a site required JS merely for reading, I’ll just go elsewhere. I generally need a good reason to enable JS on a site (and an even better reason to enable third-party JS).
Now I can’t tell how many other people are that way. But I know for sure that I’m not the only one.
Can search engines render a certain amount of Javascript and therefore work “anyway”? In some cases, yet. But far better (for a bunch of reasons) to provide content “ready to index”.
Deep Links
It is possible to make deep links work with a pure Javascript/API based view. But it gets complicated at times. Providing a full HTML output makes it easy as the server takes care of the URL evaluation and provides actual information instead of “a blob of Javascript code and hand off the parameters and hope that everything renders correctly”.
Alternative Output Formats
While already decided, despite my requests , to not have native PDF output as MVP, at some point I hope we will have that as an option (PDF link on each content page to produce a clean, repeatable, nicely formatted Letter/A4 page in PDF format to archive, email or print). That is currently very hard to do in Javascript. Trust me. I’ve looked. A lot. And I’ve always ended up generating the PDFs server-side.
Accessibility
I can’t say for sure, but I have a hunch that a pure HTML page (even if it benefits from Javascript for user interactions) will work far better with screen readers for the blind and other assistive technology than a Javascript-based page.
Gotta be honest: starting up alternative implementations and casually dropping links feels a lot like “my way is best way join me”, whether or not that’s how it’s intended, which is… not particularly helpful.
For better or worse, .NET Core is our chosen stack. Would I choose something else if it were up to me? Yes, I would. Do I think .NET Core is the best possible choice? No, I don’t. Then why am I defending it, I hear you ask? Because core decisions cannot be up for constant re-debate by every new wave of folks joining. The only good reasons to change a core decision are (a) we find a dealbreaker, or (b) there’s widespread consensus for change despite setbacks.
I see neither of those here. If that’s what you want, start a thread and create consensus for change.
Transparency: I’ve deleted a post, above, that linked an alternative implementation. See above for reasoning: it’s unproductive to have this debate all the time.
I’d like to weigh in here as an experienced developer who primarily writes in JS.
I currently can’t contribute to the backend in this project because we are using .net.
…so what? Our goal is to build a robust back end not get as many devs involved as possible.
Whilst moving to RoR would be nice for my ego because I could contribute more, I don’t think moving right now is the right way to go. There were a lot of discussions about this and this is where we netted as a team. I voted for RoR and .net won. So I put on my big boy pants and contributed in other areas I have experience in.
We have to be able to make decisions as a team and stick to them otherwise we won’t make this project work. We can’t. There are too many decisions to make. And more decisive ones than this.
At the end of the day, contributing as much as you can will help us go further than complaining about tech stack. At the end of the day this is MVP. If we need to rewrite later we can. Although I highly doubt we will need to. Rewrites happen all the time in our industry. It’s how we have jobs
My personal opinion is that SPAs over complicate things for little to no benefit, except in the case that truly rich client-side interactions are a requirement. A Q&A website is not such a site, and traditional server-rendered HTML would be my strong preference.
It’s just as easy to correctly architect a server-rendered application to separate backend and frontend concerns as it is to do so with an SPA.
, to not have native PDF output as MVP, at some point I hope we will have that as an option (PDF link on each content page to produce a clean, repeatable, nicely formatted Letter/A4 page in PDF format to archive, email or print). That is currently very hard to do in Javascript. Trust me. I’ve looked. A lot. And I’ve always ended up generating the PDFs server-side.