Future of the web client: a proposal

[heyhippari]

This is not really a proposal anymore. Development has started in https://github.com/jellyfin/jellyfin-vue/.

To prevent confusion, the original proposal has been edited to reflect the current state of the Vue project. The original text is available through Github's post history.

We will leave this issue open for a while to allow further discussion, but discussion about the implementation of the Vue client should be done in the jellyfin-vue repository.

---

Rationale

The web client has a ton of technical debt and bad design decisions. We have been trying to clean it up for months, but issues encountered during the final phase of the webpack migration due to the inherent design of the client make it clear that a brand new client based on modern technology and using best practices is the easier route to take.

In addition, there is some uncertainty in regards to the migration to Vue. We are not sure which of the proposed routes would work. For reference, the current plan is/was:

• Move to webpack
• Add Vue.js to the existing app in the init script
• Integrate from bottom to top (Replace simple components first, then move up the chain until we reach the router itself)
  OR
  Integrate from top to bottom (Wrap the entire app in a vue-router route, then move each route out into components one by one)

Both approaches have issues, which I'll get into below.

Issues with the current plan

Bottom to top

This approach is very dirty, since we have to manually create and insert the Vue components into the various files, requiring a few lines for each component inserted (See #889 (comment))

It is also likely to break existing features and won't allow us to properly refactor the app until we are very far into the process, leading to potentially non-optimal design and technical debt, even after migration is complete.

Top to bottom

To put it plainly: we're not sure if and how this will work. Theoretically, we can wrap the existing app, with its router and everything, inside of a * route, which will act as a catchall. We could then use a navigation guard to make some translations between the two routers possible.

However, this is completely untested and will possibly require large changes to how the current client works and is organized.

Proposal

Create a jellyfin-vue repository and implement a new client using the already agreed-upon technologies, with a few additions.

Target

No official target. The client will serve as an alternative web client first and foremost. It may or may not replace the current web client at some point in time.

Pros

• Faster client on all platforms
• Allows us to follow best practices from the start
• No technical debt to fix
• We can implement tests from the start
• We can document everything properly from the start
• Clean and modern code, everywhere
• A better and more modern stack is possible (Nuxt, Progressive Web App, Server-Side Rendering, ...)
• No need to migrate to OpenAPI from the current API Client

Cons

• The current web client will see reduced activity (At least @MrTimscampi will be working mostly on the new client)
• We won't have feature parity for a while

Technology stack

• Nuxt.js
  Handles a lot of boilerplate for us: tool configuration, performance optimization of the framework, basic app boilerplate
• Vue.js
  Required by Nuxt.js, chosen by the community as the target framework for jf-web.
• TypeScript
  Using typed-JS from the start, meaning we won't have to move to it at some point
• Vuetify.js
  Current target for some base components (App structure, navigation drawer, buttons, etc)
• Axios
  A promise-based API client that can work with OpenAPI and works both in Node.js and in the browser (OpenAPI Generator has an Axios target)
• Vuex
  Store to share state for the entire client
• ESLint/Stylelint
  Same as the current linters on jf-web. Good, complete configuration from the get-go without any large lint-fix PRs.
• Jest
  Solid test framework available from the start. We can write tests for the web client as we go, ensuring less breakage in the long term.

The tech stack is chosen to remove as much boilerplate as possible and allow for rapid development with well-known, widely-used technologies, while also allowing us a lot of control, should we need it at some point.

Why not react-native

Simply put: that client had a year of development and got very few contributions.

React Native is also not made for web. Web support is secondary in React Native, while for Jellyfin it is very much the main target and our flagship/reference client.

The community has also voted on what framework they would like to see and potentially work on in the future, and Vue.js was the most popular.

As such, it makes sense to work on a Vue client.

[joshuaboniface]

So, my thoughts:

1. I don't like the idea of adding significantly more complexity to the web app, regardless of the reasons. Today it's just static files served by Kestrel or (hypothetically) any arbitrary webserver. I think this should remain our goal and if we have to make some minor sacrifices (like less pretty URLs), so be it.
2. If we are going to go this route, NodeJS isn't a bad solution, but we have to be very cognizant of the Windows and MacOS install base. Will this run for them? We are not a Linux-only app as much as I would like us to be.
3. I never agreed with the split; I do not fundamentally see the "server" and "web" as different things, they both provide "Jellyfin" the vidoe streaming system; we split them for practical reasons vis a vis the Android client. I do think there should be more inter-discussion between server and web teams, not less, especially until API v2 is completed.

[cromefire]

I specifically don't like the following points:

The final client will require Node.js for hosting

Express.js
We can easily add Express as a Node.js server to get more control, if and when we need to.

This introduces a lot of complexity and additional work and shouldn't be need imo

Jest
Solid test framework available from the start. We can write tests for the web client as we go, ensuring less breakage in the long term.

There's also karma and cypress, not that jest is bad, but might want to discuss the options first before fixing it

Vuex
Store to share state for the entire client

Introduces a lot of complexity (especially for non Vue devs) without any real benefit imo maybe something like RxJS or plain js classes ("services") could handle it as good, but a lot simpler

I'm on the go so don't expect this to be my full argumentation, but it should serve as a starting point

[heyhippari]

This introduces a lot of complexity and additional work and shouldn't be need imo

Pretty much all of it is handled by Nuxt. Unless we need to at some point, we don't explicitely need Express. But if we need to, we can dive into it. Otherwise, it's really as easy as yarn start and Nuxt handles the rest.

There's also karma and cypress, not that jest is bad, but might want to discuss the options first before fixing it

Jest is very well supported by Vue and would be what most Vue devs would expect, imo.

Introduces a lot of complexity (especially for non Vue devs) without any real benefit imo maybe something like RxJS or plain js classes ("services") could handle it as good, but a lot simpler

This would mirror the current way it is done in jellyfin-web, which is very dirty for a Vue app. Vuex allows us to have one central point where we can handle all the shared data across the app in a simple way, without it being really dirty.

Imo, RxJS has a completely different purpose. Vuex is there for a specific purpose: handle shared state.

[heyhippari]

1. I don't like the idea of adding significantly more complexity to the web app, regardless of the reasons. Today it's just static files served by Kestrel or (hypothetically) any arbitrary webserver. I think this should remain our goal and if we have to make some minor sacrifices (like less pretty URLs), so be it.

We have challenged a lot of what Emby left us with, but challenging Kestrel hosting the web client never came up.

I think purposefully sacrificing things because of Emby legacy is a bad idea. Properly made, it's basically like running any other app and, in my opinion, if someone can't do that, they shouldn't be using Jellyfin in the first place.

If we are going to go this route, NodeJS isn't a bad solution, but we have to be very cognizant of the Windows and MacOS install base. Will this run for them? We are not a Linux-only app as much as I would like us to be.

Any native dependency would be during build only. The end user wouldn't see any of it.

I never agreed with the split; I do not fundamentally see the "server" and "web" as different things, they both provide "Jellyfin" the vidoe streaming system; we split them for practical reasons vis a vis the Android client. I do think there should be more inter-discussion between server and web teams, not less, especially until API v2 is completed.

The split has been discussed multiple times and I think everyone on the team pretty much figured that a standalone web is the direction we are going it, whether statically hosted or run through something like Node.

I'm not advocating for less discussion. There will always be a cooperation between the main web client (whatever it is) and the server team, and this isn't advocating to change that.

[cromefire]

Pretty much all of it is handled by Nuxt. Unless we need to at some point, we don't explicitely need Express. But if we need to, we can dive into it. Otherwise, it's really as easy as yarn start and Nuxt handles the rest.

Well I'm not talking about the development, I'm talking about the deployment, this adds whole class runtime and it deployment difficulties.

I see 2 solutions here:

Static server

Create a server in a language that statically compiles without dependencies. Here we have Go (golang), Rust, C, D, Graal native image, you name it, ...

I know many people hate go and I also don't like it particularly, but as it brings all the building blocks for such a small http server we'd need in the language, it allows us to just write a few lines and we have a static binary that has http. I needed I'd also volunteer to write and maintain it, it's 90% copy-paste anyway. This approach is a bit more difficult on setup though, then the node.js approach I'd like to provide binaries in this case probably so not every one needs to go sdk or at the very least have a node.js script that downloads the SDK and compiles it transparent to the developer to make it as easy as possible.

Also if needed go can proxy requests easily from it's router, so we could proxy the jf api if needed to minimize the port usage or of course it could go the other way around

Continue the run serve it via jellyfin

This doesn't require a lot of work, but makes us more depended on the server.

[joshuaboniface]

Any native dependency would be during build only. The end user wouldn't see any of it.

That has me a bit confused, would NodeJS be a dependency to run the app on my machine, or is it just a build-time dependency to build a set of static files that could then run under any web server? The former is my concern regarding complexity of deployment here.

As mentioned in chat, I'm very much of the opinion that "do what you want to do" is the motto of the project. I will never discourage a new client, but what I want us to focus on is user stability. Telling someone upgrading from (examples) 10.8.0 to 10.9.0 that they have to rip everything out and completely redeploy Jellyfin isn't a good user experience, and that is what I am concerned with at this point.

[cromefire]

Jest is very well supported by Vue and would be what most Vue devs would expect, imo.

I've also seen other tools. I'd say best tool for the job so let's at least evaluate them before deciding just "because other people do it like this".

[heyhippari]

I see 2 solutions here

Both of these run into the same issue: they rely on the web contributors interacting with technology and languages that are not in the usual skill set of a web developer.

We run into this issue currently. Want to fix something regarding to how the web client is handled? You either have to learn C# and Kestrel or bother someone from the server repo until they get it fixed.

This is far from ideal and the proposal simply puts all the tools back into the team that works on the client, so they have control over the entire thing.

That has me a bit confused

Sorry, what I mean is that Node would be required to run it, but you wouldn't need to build any native dependencies through npm or yarn, which is usually the issue on Windows and Mac.

I've also seen other tools

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

[cromefire]

This would mirror the current way it is done in jellyfin-web, which is very dirty for a Vue app. Vuex allows us to have one central point where we can handle all the shared data across the app in a simple way, without it being really dirty.

Imo, RxJS has a completely different purpose. Vuex is there for a specific purpose: handle shared state.

Well this is for example how angular is handling it and many not web frameworks (it's also sometimes called repositories and other terms, for example on android). Because (and this is where rxjs is coming in) storing state isn't a problem, we have variables. The problem is propagating state and this is where rxjs shines. The problem with the current client and state is 95% separation of concerns and observability. The first is solved by designating a purpose to a repository/service/what-ever-you-want-to-call-it. The second is where typescript helps because you get the observability where a function is being used and what functionality is available through typing and also through rxjs because it defines a few well know primitives that can be exposed (observable / subject) and that allows proper typing (which makes a huge difference to the current client where this event suff is happening and some magic happens some where: emitter.trigger(instance , "event") (disclaimer this is no actual code)).

[cromefire]

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

You mean jest

• https://cli.vuejs.org/core-plugins/e2e-cypress.html (core plugin, e2e, 68.4K/week)
• https://cli.vuejs.org/core-plugins/e2e-nightwatch.html (core plugin, e2e, 32.6K/week)
• https://cli.vuejs.org/core-plugins/unit-mocha.html (core plugin, unit, 45.5K/week)
• https://cli.vuejs.org/core-plugins/unit-jest.html (core plugin, unit, 269.6K/week)

[cromefire]

I'd also like to add a thing I find important to the proposal:

https://cli.vuejs.org/core-plugins/pwa.html

[heyhippari]

I'd be curious if you have a list, because I've looked at this quite a lot and I haven't seen anything as widely used and adopted in the Vue ecosystem as Vuex, for this specific task.

You mean jest

* https://cli.vuejs.org/core-plugins/e2e-cypress.html (core plugin, e2e, 68.4K/week)

* https://cli.vuejs.org/core-plugins/e2e-nightwatch.html (core plugin, e2e, 32.6K/week)

* https://cli.vuejs.org/core-plugins/unit-mocha.html (core plugin, unit, 45.5K/week)

* https://cli.vuejs.org/core-plugins/unit-jest.html (core plugin, unit, 269.6K/week)

Sorry, apparently I can't read 🤣 Yes, for testing frameworks, I agree that there are other tools available. However, Jest seems to be the most common for unit testing.

E2E is basically a pain to do with the separate server, at this point, so this wouldn't be a consideration for now.

[heyhippari]

I'd also like to add a thing I find important to the proposal:

https://cli.vuejs.org/core-plugins/pwa.html

We would be using this: https://pwa.nuxtjs.org/

[cromefire]

Well e2e is why I'm advocating for a test docker image

[cromefire]

Also I like the general proposal, as I've always advocated for doing it right once to just have less pain in the future.

And to most stuff I didn't mention yet:

• Nuxt: investigating
• Lint: definitely
• Vue: Meh, but decided, so 🤷🏻‍♂️
• TS: definitely
• Vuetify: Not fully investigated, maybe some 2nd look would be good, but probably fine
• Axios: Probably not needed (I'm strongly assuming node won't happen), would just generate a fetch-based client (I'm pretty sure that's available)

[Protektor-Desura]

The more complex you make things the more of a barrier to entry it becomes for new developers to come in and join the project. I would take care about making things more complex and adding a ton of toolsets that new developers will have to learn or know in order to contribute. The other thing is documentation on this. Right now I know that documentation is not something most developers like to do but it is needed for new developers to come along later and join the team when older members get burned out in 6 months to a year. But we need more and better documentation for Jellyfin. I would be happy to add to the documentation but I have no idea how to do that or who to work with on it or any of that which again is a problem. The process to join the group should be very clear and very clear what is expected and how to help.

Yes I know that managing open source projects are way different from other stuff. I have been a part of many open source projects over the years and dealt with managing some of them. There are some really good books out there on managing open source projects and running and managing communities as well.

[heyhippari]

The more complex you make things the more of a barrier to entry it becomes for new developers to come in and join the project.

The current client has a really complex and opaque structure, both for files and code. The new client would respect the Nuxt guidelines and employ best practices for everything.
This makes it pretty much a non-issue, since it's a well documented and popular structure and way of doing things.

The other thing is documentation on this

All the tools used have A-tier documentation and are major projects. In regards to documentation, this allows us to enforce documentation from the get-go, making this a non issue as well.

The process to join the group should be very clear and very clear what is expected and how to help.

Joining the org is not needed for contributing. We encourage and help as much as we can when new or occasional contributors show up.

Someone basically notices people who have contributed a lot and have made meaningful contributions, then invites them. That's it, it doesn't bring you much more things than green ticks on some repositories and some internal discussions that are usually mostly memes.

(I pressed the close button by accident, oops)

[cromefire]

Nuxt: investigating

I only had a rather quick look at it, but seems to be fine, as long as we say with the traditional, non ssr and non static, SPA mode

[cromefire]

Also the serving part I mentioned doesn't have to be an "either ... or ..." we could support both so we could for example have 4 Packages:

• jf-server: The server
• jf-web: The assets of web, the server can serve those, if found (using SPA middleware)
• jf: Metapackage for server and web
• jf-web-standalone (new): A little static server to serve web independently. This could either depend on jf-web or package the assets inside the binary

[cromefire]

some internal discussions that are usually mostly memes

Well there seems to be a lot of decision making too

[heyhippari]

For info, internal discussion resolved to this:

• jellyfin-web-next would not replace jellyfin-web now or at any predetermined point in time (This is what was planned with this proposal, even if that evidently doesn't come across). If/when it's deemed good enough, it would either continue to live as an alternative web client or would replace the current one.
• There is no time-frame

I will be making a new repository and transferring it to the org as jellyfin-vue to reflect this. My work will then be mainly centered there instead of here, and any contributor is welcome to join in the effort (with the above in mind).

This discussion remains open, of course, but please keep the above in mind.

[cromefire]

as jellyfin-vue

I'd name it jellyfin-web-next then (to make clear there's where a lot of the new development goes to and that it might eventually replace web in the far future)

[cromefire]

I'm also hereby volunteering to help with the implementation once you got the base infra set up

[cromefire]

Nuxt: investigating

I only had a rather quick look at it, but seems to be fine, as long as we say with the traditional, non ssr and non static, SPA mode

It basically seems to be the angular cli (+ builders) equivalent for vue

[joshuaboniface]

as jellyfin-vue

I'd name it jellyfin-web-next then (to make clear there's where a lot of the new development goes to and that it might eventually replace web in the far future)

I want to avoid calling anything "-next" going forward. It will be built as an alternative, not a replacement; if the end result integrates well enough and is superior enough to the default to replace it, only then will we make that call. I don't want to give any false impressions about that, and given our bad experiences with the React client I want to avoid a repeat of treating it like "the new client".

[iwalton3]

I love the idea of a new web client. There is a ton of technical issues that could be solved by a dedicated rewrite, assuming of course enough people work on it. (For instance, race conditions in the UI and standards such as time units.)

I do have two items I would like to see in a new web client:

Easy to Serve

I don't like the idea of restricting the client to only be served by something like Express.js. I currently serve a copy of the web client locally for MPV Shim desktop mode, and requiring something like that would make it very hard for me to embed the web client. A static web client is also great for security, as the only attack surface is the Jellyfin server and whatever reverse proxy you use (if applicable). If the web client is to be the base for TV apps and other constrained platforms, losing the ability to embed the web client could be a considerable limitation.

This is not to say that you cannot have modern SPA features. Something like try_files (Nginx) or mod_rewrite (Apache) to serve the same index.html file across routes is perfectly fine, and most frameworks will work great with it.

Extensibility

It would be nice to be able to add plugins to the web client, for instance the ebook player could be developed as a plugin. This also opens up the ability to make tools like a dashboard with charts/graphs as well as advanced media management tools without burdening the core web client with the code. I know some modern web frameworks with module compilation, extensive global state, and tree shaking make this difficult to impossible, but it should still be considered.

This is also important, as one of the major goals of a web-based desktop client in the future would be to add MPV support without using the cast mechanism (like MPV Shim Desktop), which would require some kind of deep integration with the web client. If this could be implemented as an alternative player plugin, it would be way more practical. Otherwise you're effectively forking the client, which has tons of maintenance overhead.

[cromefire]

Also cross link, if we want also want a standalone web to be possible here's a short PoC for an application server: https://gitlab.com/cromefire_/spa-server it just does the default:

• has a static file with that path? -> serve file
• else does accept html and doesn't have a file extension? -> index.html
• else -> 404

This is just a PoC but it doesn't need any runtime which is one of the problems with the node method

[cromefire]

Also I don't know about vue-router specifically, but you usually can switch between hash and path mode, so when served via jf or an app server it can use paths and if it makes problems in some apps it can simply be changed to hash (via config or variable or query param or so)

[Bitwolfies]

• The new client would not be served through the Jellyfin server (more on this later)

I understand you say more on this later, but from what I can gleem from that this new client will either have to be hosted separately/a downloaded app? I’m not totally sure if that’s what it means.

[cromefire]

So you can even serve the current app as a standalone app, this was about making it as a requirement though, but because of strong opposition, I think this point isn't a requirement anymore

[heyhippari]

Indeed, the client (Who lives over in https://github.com/jellyfin/jellyfin-vue and is progressing fast) doesn't require NodeJS anymore. That plan was changed.

Once you build it, it can be served just like the current web client, though if you wish to serve it through the current Jellyfin server, some changes need to be made to the code of the server)

[mwamp]

Hi,
I'm sorry to throw in my two cents here especially when it seems you guys already started up with Vue.
Did you guys consider Svelte as a web framework for this?

I know it is a less established framework than Vue but my experience with it is that it really makes development easy. For a project of jellyfin's scale I think it's built in state management mechanisms are quite enough.

I guess it would also be easy to use it's brother server framework (Sapper) as a backend for people who are okay with a nodeJS backend and to also build a clean build pipeline to output either a full static app which can be served by any other backend (or even just the web components if preferred)

I just wanted to ask if svelte even came on the table at some point. My main point being that (my personal experience with it) the code quality and ease of development you get with it is really good.

Feel free to ignore if this is off topic at this stage

[heyhippari]

Hi @mwamp. No worries, questions are always welcome, as we wish to be as open as possible on everything we do.

We held a month-long community consultation over in #889 back in March to help us decide which framework the community wanted us to support in the future. While Svelte wasn't considered directly, the decisions ultimately came to a few factors that we can summarize as such:

• Popularity
  We want a well supported framework, with a lot of support from the community and ideally a wide support base. We don't want to have to change our technology stack in a few years because interest in a framework died down. This already limited our choices a lot, since the only really viable options would be Angular, React or Vue.
• Ease of use
  My main goal, as far as selecting technology, is ease of use for contributors. The goal of this is to increase our pool of potential contributor. Making the project use widely known and easy to pick up technologies means we have less of a barrier of entry to people wishing to submit a fix or a feature in the future. This is of course balanced by other aspects, but it's an important consideration..
• API stability
  We wanted to stick with a project that doesn't require us to migrate every new version. Between React, Vue and Angular, Vue seemed the most stable in regards to their APIs. We do intend to move to the Composition API from the currently used Options API, but that's pretty much the only change we should be making for a move to Vue 3.

At the time, one of the considerations was also to be able to migrate in-place, meaning converting jf-web to our chosen framework. This limited us further in our choices, due to not every framework being able to support such a thing.

Other things came into play, of course, but these were the main parameters.

At the end of the day, as explained above, jellyfin-vue is currently seen as an alternative web client and not a replacement for the current one. It's basically a bunch of contributors trying something else for a while to see where it can go. This may be reconsidered at any time, depending on the evolution of both clients, but that's where things stand now 😃

Contributions to existing clients are always welcome and, of course, anyone is encouraged to make their own (and we're happy to help via Matrix or help you promote clients with a blog post and a Reddit thread).

[s0urcelab]

@MrTimscampi Hi~
Even though your guy decide to migrate to Vue, i still wanna give a try to build a React client.
As you mention above, client will be hosted by nodejs independently, i'm confused about 2 things:

• Is jellyfin fully functional with pure API?(separation of front-end and backend)
• Which way should i choose to familiar with jellyfin-web APIs? document? or every request from chrome Devtools?

[dkanada]

1. Yes, every request goes through the API on the server.
2. We have an initial OpenAPI document somewhere by @crobibero that should help a bit.

[Bitwolfies]

At the end of the day, as explained above, jellyfin-vue is currently seen as an alternative web client and not a replacement for the current one. It's basically a bunch of contributors trying something else for a while to see where it can go. This may be reconsidered at any time, depending on the evolution of both clients, but that's where things stand now 😃

This is sort of what worries me, the fact that this isn't yet trying to be a replacement just yet, more of an experiment which is fine, completely throwing out the current client for a as of yet untested and unproven replacement would be a move as bad as Emby closing its source. But everything I've seen about the current client is that its a complete mess, which is evident, considering if it wasn't you wouldn't be creating a replacement. I guess I'm just wondering if your mindset is "Well we might be bulling something to replace the current client" or "We need a replacement client, this is the start of that, it might fail, but we need a replacement." and if it's not the second one, why not? While its true anyone can go out and build a replacement client, this is being made by a core team member with the intention of being an official replacement, or as official as an open source client can get.

I really really hope I'm not coming off as rude or an asshole or anything, I just want to understand what the goal of this is, and if the end goal isn't to replace the main client, why the effort isn't just spent there.

Thanks for everything you do Timscampi, this 100% would not be what it is without you, and everyone else who contributed, really sorry if this comes off bad at all, I have nothing but respect for what you, and everyone else does here. :)

[dkanada]

It's not a replacement because we have a set of features that will take an extremely long time to reach with a brand new client. Our primary goal is to avoid breaking the current user experience, so obviously we can't just implement 70% of the features and call it good enough to replace the existing web client.

This is most definitely an official project that aims to create a modern client for browsers, that's not in contention. The reason we don't want to call it a "replacement" is because we don't want to completely abandon the current web client for a project that would probably take over a year to reach feature parity.

Also, just because this web client exists doesn't mean the other one is immediately useless. The purpose of this client will probably change over time, perhaps we will decide to declare it the official successor, or maybe just continue to push it as an alternate client with different goals. My guess is that if we ever completely deprecate the existing web client, jellyfin-vue will indeed be the replacement. In general though, I think that both will exist as parallel projects for quite some time.

[heyhippari]

The opening post has been edited to reflect the state of the things as they stand currently. Hopefully this prevents some confusion in the future for people finding this :)

---

I guess I'm just wondering if your mindset is "Well we might be bulling something to replace the current client" or "We need a replacement client, this is the start of that, it might fail, but we need a replacement."

Officially, we don't want to commit to something that might not happen. We already had a false start with the React Native client, so proclaiming a new client this early feels wrong. We also don't want to attach a specific version or date to a new client, because who knows if/when that happens. It just sets expectations that we may or may not meet.

Unofficially, my mindset is the second. I've made it quite clear that I think we'll lose more time trying to beat this into submission than implementing something new. However, I'm bound by what the team wants, so I can only speak and work for myself 😃

As @dkanada says, the Vue client is still a long time away. We've got some of the very basic features down quickly (Home screen, library navigation, basic item details, authentication and video playback is in the works). But there's a ton more to go, and who knows how long that'll take. Until the client is viable as a day to day driver, I'm expecting activity over there to be limited.

I really really hope I'm not coming off as rude or an asshole or anything, I just want to understand what the goal of this is, and if the end goal isn't to replace the main client, why the effort isn't just spent there.

No worries. As I said before, questions are always welcome 😉

This is all a voluntary project, so I can't really force people to go work on something else 😄 I can only move myself to another sub-project and hope people follow.

Thanks for everything you do Timscampi, this 100% would not be what it is without you, and everyone else who contributed, really sorry if this comes off bad at all, I have nothing but respect for what you, and everyone else does here. :)

Thanks, it's always appreciated 😉

[ldexterldesign]

Disclaimer: I don't have a major issue with the design

Hi all,

Sorry if this has been answered somewhere else or I've completely overlooked it in this issue but Is this a redevelopment or a redevelopment AND redesign plan?

"Feature parity" is mentioned a few times here...

Personally, thing is, I don't care about parity. I don't care about a bunch of jellyfin features and I'd rather not wait >1 year to experience the same thing. I've never felt emby/jellyfin has been good (enough) for consuming anything but video.

The main reason I invest CPU cycles in jellyfin instead of mpv for video is that:

• it's in the browser and I have a browser on every device (so I can share with myself/family/friends)
• it visualises my system files as pretty pictures
• it tells me what I have/haven't watched (a couple of times in as many years I've created collections/playlists - I still don't remember the difference between them)
• it scrapes my viewing to trakt (i.e. plugin)

"Simple" additions like full hotkey support (inc. player) would go a long way towards better UX out of the box

I see your kanban but please consider putting untechnical user stories somewhere so users can vote on what users want priority-mapped

I would hope an MVP can appear, for example with the features above, in <1 year, then someone like myself can drop into the project with a vested interest in contributing or learning some of the tech' stack to make a contribution (have done basic vue but currently in svelte land)

Hope to hear back

Sincerely

[dkanada]

@ldexterldesign we already have an MVP available at jellyfin-vue that has video playback in an open pull request and lots of other features. You could probably start using it as a proper client very shortly, and adding features is much easier than with the current web client.

[ldexterldesign]

Hi @dkanada, thanks for reply. For a play, is a docker container too much to ask at this stage (happy to help)?

[heyhippari]

We already have a Dockerfile in the repository, though it is largely untested.

We are focusing on the main features first, so being able to visualize your files and playing them. I'm not doing votes for priority, because we run the risk of things being prioritized in the wrong order and I personally think that it's a terrible way to run a project.
When doing project management (Which is essentially what I'm doing on jellyfin-vue, along with implementing it), you have many things to consider (Which features are dependent on others, which have a higher priority for functionality, etc).

I do intend to start making it more available once a few things are working. Most notably:

• Basic video playback
• Session reporting

This is to ensure that you are able to watch videos in the client and that your progress is reported to the server, which I consider the bare minimum for a usable client.

We are doing some pretty heavy redesigns on a lot of how the client looks and work, since the general consensus among the team is that we have a lot of really bad UX decisions that are holdovers from Emby. We're also trying to give Jellyfin more of its own identity along the way.

The kanban is only to track the features that Jellyfin Web has and that we need to implement to essentially be a reference client. The release plan is to make preview releases as major features get completed, to get user feedback along the way. More info will become available as we reach closer to that first preview release :)

[ldexterldesign]

2011 - Elements of User Experience,The User-Centered Design for the Web and Beyond - Jesse James Garrett - Pearson Education

Prioritizing Requirements

Collecting ideas for possible requirements is not hard. Almost everyone who regularly comes in contact with a product—whether they are inside the organization or outside—will have at least one idea for a feature that could be added. The tricky part is sorting out what features should be included in the scope for your project.

Sometimes a strategic objective will result in multiple requirements (left). In other cases, one requirement can serve multiple strategic objectives (right).

It’s actually fairly rare that you see a simple one-to-one correlation between your strategic objectives and your requirements. Sometimes one requirement can be applied toward multiple strategic objectives. Similarly, one objective will often be associated with several different requirements.

Because the scope is built upon the strategy, we’ll need to evaluate possible requirements based on whether they fulfill our strategic goals (both product objectives and user needs). In addition to those two considerations, defining the scope adds a third: How feasible will it be to actually make this stuff?

Some features can’t be implemented because they’re technically impossible—for example, there’s just no way to allow users to smell products over the Web yet, no matter how badly they might want that ability. Other features (particularly in the case of content) aren’t feasible because they would demand more resources—human or financial—than we have at our disposal. In other cases, it’s just a matter of time: The feature would take three months to implement, but we have an executive requirement to launch in two.

In the case of time constraints, you can push features out to a later release or project milestone. For resource constraints, technological or organizational changes can sometimes—but, importantly, not always—reduce the resource burden, enabling a feature to be implemented. (However, impossible things will remain impossible. Sorry.)

Few features exist in a vacuum. Even content features on a Web site rely on the features around them to inform the user on how best to use the content provided. This inevitably leads to conflicts between features. Some features will require trade-offs with others in order to produce a coherent, consistent whole. For example, users may want a one-step order submission process—but the tangle of legacy databases the site uses can’t accommodate all the data at once. Is it preferable to go with a multiple-step process, or should you rework the database system? It depends on your strategic objectives.

Keep an eye out for feature suggestions that indicate possible shifts in strategy that weren’t apparent during the development of the vision document. Any feature suggestion not in line with the project strategy is, by definition, out of scope. But if a suggested feature that falls outside the scope doesn’t fit any of the types of constraints above and still sounds like a good idea, you may want to reexamine some of your strategic objectives. If you find yourself revisiting many aspects of your strategy, however, you’ve probably jumped into defining requirements too soon.

If your strategy or vision document identifies a clear hierarchy of priorities among your strategic objectives, these priorities should be the primary factors in determining the priority of suggested features. Sometimes, however, the relative importance of two different strategic objectives isn’t clear. In these cases, whether features end up in the project scope all too often comes down to corporate politics.

When stakeholders talk about strategy, they usually start out with feature ideas, and then have to be coaxed back to the underlying strategic factors. Because stakeholders often have trouble separating features from strategy, certain features will often have champions. Thus the requirements definition process becomes a matter of negotiation between motivated stakeholders.

Managing this negotiation process can be difficult. The best approach to resolving a conflict between stakeholders is to appeal to the defined strategy. Focus on strategic goals, not proposed means of accomplishing them. If you can assure a stakeholder with her heart set on a particular feature that the strategic goal the feature is intended to fulfill can be addressed in some other way, she won’t feel the needs of her constituents are being neglected. Admittedly, this is often easier said than done. Demonstrating empathy with the needs of stakeholders is essential to resolving feature conflicts. Who says tech workers don’t need people skills?

Hope it's useful

Sincerely

[Maxr1998]

We already have a Dockerfile in the repository, though it is largely untested.

I've been using it since it was merged and I didn't face any issues, fwiw.

[heyhippari]

For an update, some small issues have been fixed with the Docker image and we should build it and upload it to Dockerhub automatically pretty soon.

[ldexterldesign]

@Maxr1998 @MrTimscampi 👋 jellyfin/jellyfin-vue#256

[thornbill]

Closing this since development on a new client based on Vue has started in https://github.com/jellyfin/jellyfin-vue/.

In the meantime, bugfixes and incremental improvements will continue in this project.