General Improvments

[MeikelLP]

General Improvments

[sizovs]

removing server-side rendered variables from index.pug:

• window.preloadedEntity = move to client-side. Used in direct video links //dev.tube/video/<id>
• window.serverSideError = unused
• window.newVideos = unused
• window.board = move to client-side. Used in leaderboard.
• window.speaker = move to client-side. Used in speaker profiles //dev.tube/@sizovs
• window.brownbag = unused (brownbag functionality has been commented out)
• window.featured = move to client-side. Data for channels, tags and speakers list.
• title – move to client-side
• nightMode - temporarily leave on server-side, as it's not functionally critical
• jsonld - leave on server side, otherwise OpenGraph attributes won't work

[sizovs]

Let's start from scratch and make a more specific roadmap of improvement. No revolutions, small change at a time.

[MeikelLP]

How about different config files for different environments? In development you don't need meta tags so they could be omitted in the config file but must exist in the production.env file. This could be checked via a test.

AFAIK it's not very common to reference hard dependencies outside of the Vue SPA. The common way is to have different environments defined with different environment variables (vue cli docs). I think that this is the right way because the app itself becomes independent and can run without errors in itself.

[sizovs]

Meta tags are not app-wide but are video-specific. Whenever someone browses to a video, the server generates index.html with meta tags specific to that video.

[MeikelLP]

Ah okay so these pages needs to be generated statically? Maybe we should look into Nuxt.js ?

[sizovs]

That would be a pretty big change with its dragons.

Maybe a dev-server can generate a fixed or an empty list of tags?

[MeikelLP]

Yes I see that exactly like you but I think that will be the best way we have to go in the future.

What exactly do you mean? I don't think the dev server (at least the webpack dev server) is able to do this. But I don't know too much about it.

[sizovs]

What exactly do you mean? I don't think the dev server (at least the webpack dev server) is able to do this. But I don't know too much about it.

We can pass data to html-webpack-plugin: jantimon/html-webpack-plugin#747

[MeikelLP]

Ah okay never thought/heard about that: https://github.com/jantimon/html-webpack-plugin#writing-your-own-templates

I'll try looking into it.

[MeikelLP]

Is dev tube an equal use case of this? https://github.com/vuejs/vue-hackernews-2.0/

If yes what do you think about it? https://ssr.vuejs.org/

[sizovs]

No doubt SSR a good thing and has its use cases. Current dev.tube version could have been implemented using architecture similar tovue-hackernews.

[MeikelLP]

So you think it's an reasonable approach to follow right now?

[sizovs]

Yes, it could be. But we'd better evolve the application in small steps, without introducing big and risky changes to the system. I'd start with defining the goal that we're trying to achieve:

1. Define a problem
2. Define a list of possible solutions
3. Choose the best solution (small, cheap, risk-free). If SSR is the winner, why not to use it?
4. Execute

[MeikelLP]

Okay do you have any plans for the first steps towards SSR? Because you know your app better than me. You might know what parts can be altered easily or what parts need a complete rewrite.

[sizovs]

We don't have new use cases for SSR (yet).

[MeikelLP]

Are there parts that can not be rendered server side?

Right now are there certain that could be handled via SSR? If yes it could be possible to incrementally move the whole website to SSR (?)

[sizovs]

It's hard to say without actually moving to server-side: unmoveable parts, if any, will be discovered only during migration.

For now, the website has been developed without considering SSR. I assume that migration will take a significant amount of time, even if done incrementally. That's why it's important to answer the question why before committing to it.

[MeikelLP]

IMO it decouples the server-client or to be more precise it merges them so you only have one to care about.

The ultimate goal should be that the project is simply just a checkout, install packages and run. It may not contain all data equal to the production server but that should be fine. I personally hate it when projects require you to do many steps before I'm able to run the app locally (excluding dev tools/ system dependencies).

IMHO I think that the complexity to setup this project is currently not justifiable. I want to improve that. I currently see SSR as the solution but I don't have experience with it. I can only argue by the theory of it.

Do you have other folks that work with you on the dev.tube project? What do they think?

[sizovs]

I agree that the complexity can be reduced and the ideal way of running the would be checkout&run. But turning on SSR won't magically make the setup easier. As with every migration project, it takes time and effort to accomplish. Our goal is to make setup easier, not to immerse into SSR migration, right?

I recommend understanding what limits the app from running locally and addressing each problem separately. Like outsmarting index.pug variables. Then moving to the next problem, understanding and solving it.

[MeikelLP]

My thoughts were just that we could hit 2 birds with one stone and improve the design of the app overall. IMHO it could be a waste of time if we first fix some minor issues that might be resolved when doing it directly the "correct" way.

Dev.Tube doesn't look too big too have this change. And it could be done in parallel while the app in the current stage is doing like it does right now and then switch to the version 2.0 once its time has come. Just like Twitter did it with their new design.

[MeikelLP]

I just opened a PR where I improve the styling of the page (and remove nightMode as it is). I cannot fully test all possible views as the app is not correctly working locally (firebase and stuff). Can you please provide feedback on #79 ?