Complete Revamp

[mohdomama]

Presently the tech-stack of the site is HTML+CSS + vanilla JS.
This should not go no. We need to switch to a modern framework.

Any of the following will be good enough:

• Angular
• Vue
• React

[mohdomama]

@prateekj117 @pnijhara
Assign people to this. Also guide them please!

[prateekj117]

@mohdomama The site functionality seems totally static. I think it would be better if we just use jekyll or hugo or some other static site generator along with some prebuild theme and add some tweaks to that for any specific UI changes we want.

[mohdomama]

No. The functionality is limited because we have such an outdated tech-stack. We need it to be a bit more feature rich. Login, role management, etc. will be good. Also this site should be used for club notifications. I was thinking of VUE+Firebase or something similar.
If we start with a modern framework, we will create a good base for future members to add more functionality. IMHO.
@prateekj117

[prateekj117]

@mohdomama True. But building a feature-rich site needs maintenance. And I am afraid that like some other clubs' website, it would just become a dead project. I think it would be better if we keep the site functionality minimalistic. Just to showcase our project and to read more about our club and to contact the club members. If we switch to a more feature-rich website, I am afraid it won't be maintained afterward and we won't even have a website to showcase our club (which is very much required during fundraising).

[mohdomama]

Maintenance is an issue we generally face with SSR sites. Thats because SSR requires server maintenance. Bleh.
But frontend frameworks like those mentioned above are actually static site generators. They ultimately convert your site to HTML CSS JS and get served as static site. But they provide the scope of adding functionality. If required.
I think we should create a minimalist site (as you have mentioned) with a modern framework for now. This will be a like a skeleton for now. If someone wants to add functionality in future, they will have a good base to start with.
@prateekj117

[mohdomama]

Also, its ultimately for the present members to decide. If it seems an extra burden, drop it and focus on competitions instead.
@prateekj117 @pnijhara @Khanitachi decide and close this issue if you thinks so.

[prateekj117]

@mohdomama I get the point that SSR sites require a whole different level of maintenance but I don't think a website with whole Auth and role management setup won't require maintenance just because it uses a client-side framework and Firebase. Static sites won't require maintenance. Just because a website uses client side rendering doesn't mean it won't require maintenance.

[mohdomama]

I think we should create a minimalist site (as you have mentioned) with a modern framework for now. This will be a like a skeleton for now. If someone wants to add functionality in future, they will have a good base to start with.
@prateekj117

[prateekj117]

@mohdomama Hmmm, if our short goal is having a minimalist site, we can go with this approach. But for static sites, I would vote for jekyll or hugo as it has some really good themes already. Let's wait for other people to drop their views.

[mohdomama]

Okay sure. If thats what you want to go forward with. Its completely okay.
But still, you will need to assign someone and guide them
@prateekj117

[prateekj117]

@mohdomama Sure. I will try my best to guide everyone. But I want @pnijhara to drop his views as well. And then carry forward with whichever method we all choose.

[prateekj117]

@mohdomama Had a conversation with Areeb bhai, he said we could also use Vuepress with Vite, as this gives the functionality to add dynamic components afterward in Vue.

[pnijhara]

I was about to write about Vuepress. However, I have seen Vuepress be used mostly for generating Documentation. I cannot say much about Vite. However, we definitely should look for Vue + Firebase type project. For that, we can make a separate Web-Dev Team. I was totally against this website from starting. I love the work of IEEE-AMU and OpenRoboclub, though they have used vuetify which made the work simpler. We can go for some other CSS Frameworks.

[prateekj117]

@pnijhara Aren't these two websites an example that these projects are not maintained afterwards?

[pnijhara]

Who said IEEE-AMU is not under maintenance? Well, I cannot speak about PopoClub(they have their own internal matters because of hierarchy) but it was well maintained till the time Haider used to code for them.

[prateekj117]

Popoclub's website was made to use notifications and all. And no one maintained it to the level it needed maintenance, and no one is using it's feature.

Same with IEEE Website. It won't be maintained after you are gone. Small features can be maintained. Even big ones can. But unfortunately they are not in most cases.

[pnijhara]

But that's not the point we should think about. Our priority is to complete the task and too with best practices. It's up to the new team to continue with the project or to discard it.

[prateekj117]

We are thinking of building it for the future team only. Plus I don't think I will agree with just thinking of doing it as a task even when it might not have any significance in the future whatsoever.

Anyway, if more people think we should go with that, we will.

[mohdomama]

@prateekj117 concerns are genuine. Say if we develop a notification API, it might not be used in future, etc.

But the point is, we can also make minimalist websites with good frameworks. If someone wants to add features, its unto them. They have something to build upon.

[syedjawadakhtar]

But building a feature-rich site needs maintenance. And I am afraid that like some other clubs' website, it would just become a dead project. I think it would be better if we keep the site functionality minimalistic.

Since @prateekj117 was not present in the meeting held lately, I would like to drop my views regarding the maintenance of our website.
My idea was that since AMU-OSS every year continues to train freshers with web development and open-source techniques, why not outsource their members on a yearly basis for complete maintenance of our website, instead of recruiting a specific team in AUV ZHCET. This will give students a platform to gain experience and thus resolving the problem of maintenance of a feature-rich website. The only requirement will be assigning responsible points of contact from each club for regular communication for resolving the issues.
In return, the AMU-OSS can portray their work on their website and AUV ZHCET can acknowledge AMU-OSSs help - thus enriching intra-college club collaborations.
Would like to have @prateekj117 views on this.

[pnijhara]

I had a chat with Areeb Bhai regarding involvement of AMU-OSS. According to him, it would not create any difference. I completely agree with him and I take back my words of starting a new website from scratch. Rather we should focus on implementing new features in the current one. Like if you want to implement notification feature in the website, you can import Vue components in it. Since the website is static, it should be server-side rendered with a minimum JS.

Again if you want to work from scratch it would be better to take help of some static site generators.

[pnijhara]

I now completely agree with @prateekj117's comment #20 (comment)

[mohdomama]

Since the website is static, it should be server-side rendered with a minimum JS

Is SSR the right terminology for static sites?

Rather we should focus on implementing new features in the current one

You say this when there is already substantial amount of work done on previous site. I don't think that's the case here. All we have is a theme downloaded from somewhere and we just threw in our content.

Again if you want to work from scratch it would be better to take help of some static site generators.

It will be difficult to add additional functionalities if we go with static site generators. Lets say we want login in the future, and we are using jekyll at the moment. It will be painful to integrate jekyll with firebase or something.

Also, it will be good to have additional features like RSS aggregator, etc. We might write our blogs on medium or something and aggregate them here. This will be comparatively easy with some JS framework like Vue, React, etc.

Further, creating a clone of our current website in Vue/React/Angular is hardly one week work.
The advantage of this that we are ignoring, again and again, is that if someone in future wants to add some additional features in this site, they will have a good base to start with. Say two years down the line, we can incrementally add new features to the site. Will not be that easy if we are stuck with jekyll.

Now coming to AMU-OSS, almost all of the members of AUV computers are members of AMU-OSS as well. We don't teach/discuss web dev here at AUV. It was just a suggestion to bring AUV-web(and probably app in future) under AMU-OSS. The advantage is that AMU-OSS will have a project that is actually being used by many people. Something nice to showcase. We will have a real life project for new AMU-OSS members to work on. We can open issues for students to participate in hacktoberfest, etc.
But again, its just a suggestion.

Rather than personally talking to him, lets bring @iamareebjamal here.
All yours Areeb bhai. Its your area of expertise.

[iamareebjamal]

Can I see the current site? Where is it hosted?

Got it

[pnijhara]

auvzhcet.in

…

On Mon 24 Aug, 2020, 10:06 AM Areeb Jamal, ***@***.***> wrote: Can I see the current site? Where is it hosted? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJSG3WTA66G2O3YXWONVJELSCHU4ZANCNFSM4PWWZMGA> .

[iamareebjamal]

Also, before writing my detailed opinion sometime later today, I want to mention that I didn't say SSR is better for static sites, I said SSG (Server Side Generation) is better. For example, the current site is just HTML CSS and some JS, JS isn't used to render the page, HTML is already generated (by hand). This conforms to the principle of least complexity. You shouldn't be rendering HTML on server on client if it can be rendered/written on build time. And since the site is mostly static, this is true for it. You can just move from manually writing the HTML to generating it at build time but the basic principle is this - if something can be done in just HTML + CSS, it should be done using just that. If something can be done without server, it should be done without server. You don't need server for anything other than notification, so it shouldn't be used for anything else. You don't need server for anything other than auth, so your entire site should not depend on the choice of framework just for the sake of auth, because all of the site can be created without needing auth (I'll expand on how you won't even need auth in the detailed post). If something doesn't require rendering on runtime (client or server), which this site doesn't, it shouldn't use that and should be generated on compile time. If most of the site doesn't need an interactive/reactive component, it shouldn't use one. If only one widget needs to be a React/Vue component, that should be the only React/Vue component on the page, not the entire site.

[pnijhara]

Also, before writing my detailed opinion sometime later today, I want to mention that I didn't say SSR is better for static sites, I said SSG (Server Side Generation) is better.

I interpreted wrong. Apologies for that.

[syedjawadakhtar]

Did anyone decide about the framework?
Cuz a lot of content/pages has to be changed/added as well... should I start opening new issues for this?

[mohdomama]

@syedjawadakhtar you can open issues.
Please don't close this one, all these conversations will help anyone who wants to revamp the site.

[iamareebjamal]

Please check this out - https://twitter.com/zachleat/status/1306993015072993280?s=20