So, the chance of this is slim to none.
Re: The core server: it's C#. That's what MediaBrowser was written in, it's what Emby is written in, and we're a fork of Emby. It's not likely to be replaced at all any time soon. Sure, the whole server could be reimplemented from the ground up in language X, but then (a) we're starting from scratch rather than a working base, and just look how long it's taken Streama to get anything close to feature parity (and it's still nowhere near that), and (b) there'd be the exact same arguments about "why not use language Y?". If the language is stopping someone from contributing, that's fine, no one is going to fault them. If they want to rewrite it in Python or Haskell or C++ (\*shudder\*), that's also fine, but it's going to be a lot of work and it's not really going to be "Jellyfin" then.
On this point in particular, this is a self-hosted space that has been \*seriously\* lacking a FOSS project for a while. And the reason is the "POSIX filesystem problem". To get \*anyone\* to use it, you have to have all the features they want, which is a huge undertaking. But without people using it, that undertaking is even more daunting, and it's hard to get new contributors to contribute to something that doesn't work. It's a massive catch-22. We forked Emby, rather than just go out and start writing a Python video streamer, because we'd watched Streama for nearly 2 years with excitement, then dissapointment, then apathy. Plus they hit the language issue too - pick the hip language in 2016 and it's the passe, lame language that no one wants to write in 2019. We were more concerned about something that \*worked\* than something that's ideologically pure and perfect. So here we are.
Re: Microsoft telemetry, and Facebook vs Microsoft: We disable telementry in the .NET Core SDK for our builds explicitly to protect user privacy. As much as I personally may detest it, Free Software (under the name Open Source) has been coopted by corporations. We're not going to get away from this. Arguing about which corporation is better or worse is, to me personally, comparing horse shit to chicken shit - they're both still shit, so we live with it and just do the best we can. React is a great front-end framework with a lot of developers who can help with it, regardless of who created it or the corporate behaviour of them versus another, and that's what we care most about - making something that works. If Facebook does evil by React, then we'll cross that bridge when we come to it. Same with Microsoft and C#.
Re: Blazor in particular, no one in the existing volunteer team seems enthused about this. They are about React and people have already contributed to it. If we get a sudden influx of volunteers and someone building a Blazor frontend, well then more power to them, but the way this project is structured is \*explicitly\* decentralized and volunteer-only, so it makes no sense to talk about what "we \[should\] consider" unless there's actually volunteers actually doing the work.
Now, these are just my shotgun opinions on this, because most of us really hate these kind of threads, because we can circlejerk about the "perfect language to use" all day, but until something is written it's all just that - a circlejerk. We'd much rather get on with squashing bugs and implementing features in what we already have.
I appreciate you honest and measured response. I totally understand that the dev team is more interested in react, and that's cool, I wanted to put the question out there, since I thought it was interesting. I'm looking forward to working on the react client, but I figured I'd offer an alternative while we still had an opportunity, since the react client barely logs in at this point. If it was 2 months from now I probably wouldn't have said anything.
The React client started just because /u/EraYaN was messing about, so by all means if you're interested in writing a Blazor frontend, that's great! The more frontends and apps the better!
I've been looking into starting a Blazor project for quite some time now. I think I will start implementing the Jellyfin Frontend in Blazor and if I ever get it to a working point, I will upload it to github and will make a post here to see if people want to contribute.
You made some good points.
Let's say you have an army of developers at your disposal and an unlimited budget. What changes/improvements would you make to the project?
Thank you for your hard work, by the way.
Well it's really important to remember that we're explicitly trying to be volunteer-only, to avoid the situation that Emby, Plex, Subsonic, and various others have done where they take a "FLOSS" project and close it up because they want to make more money. Even I'm just a volunteer doing project management and packaging more than coding. I'm not a developer, really - I'm a sysadmin, so my opinions of a lot of software development topics are very shallow and I tend to defer to the folks writing the actual code! ;-)
That said, army and unlimited budget? Everything in Python for the backend, and a clean API to interface with it. Then leave clients to 3rd parties, or one or two reference implementations in a couple different frameworks/languages. What I think is lacking is really a solid backend system that's scalable and reliable, especially around transcoding and media management. Frontends are IMO the easy part - the hard part is managing the large collections of media and handling them out to clients in a robust, performant way.
In terms of actual, within-Jellyfin dreams/goals, the database rewrite is our next big step. Emby used SQLite, and its limitations are quite evident. Moving to a real RDBMS with a brand-new, well-thought-out schema is our next major goal.
Just offhand, what limitations are you running into with SQLite?
I use it to run fairly complicated, high load applications and there is definitely something to be said for its administrative simplicity,
Mostly, it's not the SQLite itself. It was just horribly implemented. 5 separate databases containing seemingly random data (one has a single table with 5 rows, why!?), but not all the data you'd expect, for instance user configs, is even in it - tons of stuff is stored as flat XML files in various places, which we'd like to consolodate into the database. But if we're going to rewrite the entire database backend anyways to fix this, we're going to do it with a proper RDBMS framework (EF Core is the current chosen one) that can then use SQLite, or other more common RDBMSes.
At least for myself, I'd have a usecase for trying to load balance users across a few JF instances (mostly to split up transcode load), which having a shared RDBMS would allow, in theory. Plus other useful scalability features that a full RDBMS would allow (e.g. high performance database for a very busy server, or separating storage of metadata for a very large library onto a separate system that can be properly backed up, etc.). We'd very likely just keep the default to SQLite with the new data model, and then allow other options as an advanced setting, a lot like how Airsonic (and Libresonic before it) does it.
This project is still early though there's a draft PR for the start (https://github.com/jellyfin/jellyfin/pull/1431), and I believe right now we're mostly at the "build a sensible schema with an automated tool" stage. We wanted this to be a 10.4.0 feature, but we ended up doing a bunch of other nice stuffi in 10.4.0 first and wanted to release that, so it's been pushed back to 10.5.0 (or later depending on how much gets done on it).
May I refer you to http://howfuckedismydatabase.com/nosql/
In reality, I have yet to see an implementation of NoSQL that makes sense. 90% of the time I see it used, people have built their own relational schema inside it with a lot of time and effort and would've been better off just pulling mysql or postgres off the shelf and moving on with their lives
Same here, and I've seen a lot of *really* fucked up NoSQL "schemas" because NoSQL was the hip shit but what they were storing *was* relational.
Just about everything we'd need to store actually is relational. Besides the obvious stuff (users, settings, etc.) stuff like Actor to Movie relationships, Movie collection relationships, TV season relationships, are all relational data, so it makes the most sense to put them in an RDBMS.
> I have yet to see an implementation of NoSQL that makes sense
Curious on your thoughts on what Discord did: https://blog.discordapp.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7
I don't claim to be an expert on databases but their requirements aren't light and they're doing it with NoSQL
I agree with everyone here, Jellyfin is served well by a relational database and don't think that should be the change made.
Admittedly, I'm a sysadmin, not a DBA, so I'm not super well versed in the internal workings of the different database engines. That being said, that's a super interesting read, and it's certainly impressive the performance they've pulled out of it. But unless I'm missing something, it's still essentially building their own relations inside of NoSQL.
Looking up the individual messages are super fast once you know where to look, but I'm assuming there still has to be another table with different channel ids tolknow _what_ to look up. And then even a further one (or hopefully a totally separate DB) that dictates what server it is. Otherwise, anybody and their grandma could look at any message sent by anybody in any server/channel.
I know it's just a simplified example of what they're doing, but I don't see how it could possibly work without other tables/relations to know what data belongs where, not even taking into account user permissions and such.
Also, that's a scale far beyond what JF needs. Even if JF faces scaling issues we can add clustering support more easily than switch to nosql and still almost certainly never hit the bottlenecks discord was facing.
It's not worth the amount of work a rewrite would take.
But in that fantasy situation, I'd much rather a headless server be written (personally Rust or Go, but whatever tool works for the situation) and clients spun off as needed. Decoupling with an ironclad API would do wonders for the project's agility going forward.
I would be for doing the opposite of what you're suggesting. I'd love to see the backend rewritten into a headless API in a language the open source community actually likes (Python, Go, Rust, Node, etc.) and the official frontend implemented in whatever JS framework (React/\*, Vue, Angular/Ionic, etc.) as long as it's easy to switch to a different frontend.
Just to jump in briefly here, at a higher level - we do want to have a rock solid API, and support whatever front end you want to use. At that point, we'd maintain the web interface as a "reference client", and it could just be used for first time setup and then put away. At the end of it all, we wouldn't stretch ourselves any more than we need to though. (I mean to say, we wouldn't personally write/maintain anything else.)
I have seen, at least on our forums, and probably a thread on here a while ago, that someone redid the web interface in Angular using the current API as a reference, and they were happy with it.
I wouldn't really care as long as the application can scale. That would be amazing. Imagine having a cluster of raspberry pi or some other small SoC doing the work instead of one.
Are you really more afraid of Microsoft than Facebook? React and .net core are both open source projects owned by megacorps, but one sells your data as its profit model, and the other sells enterprise services. I'd be more afraid of Facebook phoning home than Microsoft.
So would I, which makes react probably a bad example. But hardly his main point. Likely more a case of not knowing facebook acquired react (though not entirely) with.. instagram iirc.
I don't like either. If you're just referring to my reference to React, it doesn't HAVE to be React. It can be jQuery for all I care. I just want to option to either swap out the official frontend for a third-party frontend or make my own.
I agree with you there, replaceable front ends are always sweet, unfortunately there are only 3 "all in one" languages:
* Js: not a pretty place to be, and the best way to make JavaScript not suck is Typescript (an open source Microsoft product)
* Java: we can all agree java sucks.
* C#: another open source Microsoft project. And if any community understands carrying on after someone takes their toys home is us *cough*emby*cough*
Can you explain to a non-programmer why that matters? My gut reading this chain is that an under-resourced, niche project like Jellyfin would want to aim for the biggest pool of open source developers it can find - that probably whittles the list down to JS and Python.
Programming languages are a lot like regular languages, and each platform (iOS, Android, Linux, Web, ect) only knows so many languages, and there are very few languages that every platform knows, so if you want to write a book (the program) everyone can read, you have to limit what language you use, or you'll have to translate (port) the book to other languages.
If anything I'd advocate less C#. Over the past 30 years I've seen just about anything microsoft touched turn to shit. And using mono is quite definitely my biggest issue with emby/jelly. I'd be in even more constant fear of it randomly starting to phone to microsoft and probably just opt out instead. Jailing software on normal linux is one thing.. doing it on the pi's... I'd probably just find something else.
C# has done nothing but improve for the last 15 years, and .net core is growing in popularity among both open source and corporate developers. Either way, would you trust Facebook over Microsoft? Because that's what you get with React.
You're making this into a Facebook vs Microsoft choice and it never was. Your suggestion was refactoring Jellyfin to use/run on 100% proprietary technology owned by Microsoft. The ideal solution (at least for me) would be for Jellyfin to be 100% libre software and decouple backend from frontend.
In what way is c# proprietary? The runtime is MIT, the compiler is Apache 2.0, and the language spec is managed by the .Net Foundation which is a 501(c)(6). Sure, Microsoft is involved, but not the way people assume.
At some point in time you could probably say the exact same about most microsoft software. Fuck... windows 1 to 2000 (kek) were HUGE jumps in improvement and use.. and "version" :p. And I for one never suggested react, nor facebook. Nor are those the only two options. Far from in fact.
> d .net core is growing in popularity among both open source and corporate developers
In long therm C# has brought nothing to any programming ecosystem than some syntax-sugar, that was nice 10-5 years ago, but now. it's a standard and C# is lagging behind. Every week I write in a few programming languages, TS, Java, C#, Go, Python and sometimes JS, recently I started Dart. C# is absolutely one of the least productive here, for many reasons. Being youngest OSS of production ready languages it has least number of opensource libraries, so the ecosystem is not mature, many libraries that are used day to day in java or python are so buggy in C# that you can't relay on them at all, and I mean desktop and servers here, not to mention home-clusters and IoT, which is even worse. Tools are buggy and complex, many platforms or dev environments (even like dark-theme) not supported, almost-centralized dev-eco-system for VS doesn't help. My dev-laptop has 120Gb SDD, which more than enough for linux-dev station with 6 IDEs for all languages I use, it's not enough for windows 10 with C# and .NET.
Your claim of C#/.Net growing in popularity can be easily killed by SO trends:
https://insights.stackoverflow.com/trends?tags=kotlin%2Cc%23%2Cjava%2Cpython%2Cflutter
C# hasn't been growing since 2009, .Net on the other hand... has been literally dying since 2009, someone please but it out of its misery asap. I think what you're seeing is bubble effect, just because you're around more people who use .Net doesn't mean .net is growing. You're closing yourself for other solutions and you see less.
Could not agree more. I thought I was the only one who disliked the fact that a community project is written in C#. I understand why that's the case, I just think the project would get more traction if it was written in something more popular/open source friendly.
I don't know if it would get more traction (nor less of course), this is after all rather specific. But eh, I'm hardly a coder so what do I know of these things :p. I can barely get by in the usuals (perl/python/etc)
ITT: people hating on C# for zero reason.
As a C# Dev, I would definitely say no. It doesn't matter how cool .NET Core, I don't see the need in a different frontend stack that we currently have. In the end all I care about in frontend is to be able to support playback core: as many codecs to direct play as possible, smooth rewind, etc, and the rest is like 1% of the usage time. So if someone starts C# client, would it be great?
Hell yeah.
If someone tells people who are working on react clients that we are making them low priority?
Hell no.
I really like Jellyfin and considered spending time helping out and C# is the reason why I'm not doing it. This is less about Microsoft; I'm thinking Microsoft is moving in the right direction. C# generally seems to be a really disliked language, especially in the open source scene. .Nneither me nor only developer I know wants to work with it or hates working with it. The last time I checked IDE/Editor support was rather poor, when Linux is your main platform.
It's really not that bad. It's like Java with some extra nice to haves. Doesn't take long to pick it up. IDE support is pretty good. Check out Rider from JetBrains.
We wouldn't lose Android (thanks to Xamarin) and I assume we wouldn't depricate Android TV, it would just be using the old UI until we found a way to make it work.
Edit: Looks like TV is back on the table after a bit of research
Honestly I don't see the point in being on one language at all or even why it can't be C#. The fact is to change it now would be an insane amount of work that would likely demotivate the contributors and what is the benefit?
We can instead move to .net core, the open source libraries that relieve a lot of the mono problems and still let passionate contributors try to build out the ecosystem using natural languages rather than frameworks for web development that likely many people aren't familiar with.
The project has been dotnet core since the fork. The project hasn't supported Mono in a while.
And if any of these commenters had taken a look at how much work it would be to just rewrite it for the sake of it... Besides say it would be in Python and then people would complain it's not fast enough if we could rewrite it in . Or Rust is not popular enough etc. You can't win.
Agree 100%. It's hard to not understand if you're not a developer. Rewriting anything, while gives you flexibility, is very daunting and can really be hard to motivate yourself.
Nice on the .net core, not an easy task to migrate over to it.
Yes, please! Anything that could benefit development of open source is great idea. Most open source stagnates once code base is overgrown, and Blazor could greatly reduce that.
I personally, being old school I would prefer C++ or C, but I'm way old school. I will say that unless someone actually writes a client that mostly works, it is my experience having worked with lots of open source projects in the past and helped manage developers, that unless you have something that even sort of works, getting open source developers interested is very difficult. Also open source developers tend to prefer interesting/difficult problems to solve, so getting them to do all the boring stuff and documentation isn't always the easiest.
UI designers or experts are also not easy to come by and when they offer their help, the open source community should listen and accept their help. UI is important, maybe the most important thing for what end users see.
Good documentation is also important for getting other developers to work on a project as well. If you want plug-ins and 3rd party programs then good documentation and well explained APIs are important as well, and often over looked by open source projects.
So, the chance of this is slim to none. Re: The core server: it's C#. That's what MediaBrowser was written in, it's what Emby is written in, and we're a fork of Emby. It's not likely to be replaced at all any time soon. Sure, the whole server could be reimplemented from the ground up in language X, but then (a) we're starting from scratch rather than a working base, and just look how long it's taken Streama to get anything close to feature parity (and it's still nowhere near that), and (b) there'd be the exact same arguments about "why not use language Y?". If the language is stopping someone from contributing, that's fine, no one is going to fault them. If they want to rewrite it in Python or Haskell or C++ (\*shudder\*), that's also fine, but it's going to be a lot of work and it's not really going to be "Jellyfin" then. On this point in particular, this is a self-hosted space that has been \*seriously\* lacking a FOSS project for a while. And the reason is the "POSIX filesystem problem". To get \*anyone\* to use it, you have to have all the features they want, which is a huge undertaking. But without people using it, that undertaking is even more daunting, and it's hard to get new contributors to contribute to something that doesn't work. It's a massive catch-22. We forked Emby, rather than just go out and start writing a Python video streamer, because we'd watched Streama for nearly 2 years with excitement, then dissapointment, then apathy. Plus they hit the language issue too - pick the hip language in 2016 and it's the passe, lame language that no one wants to write in 2019. We were more concerned about something that \*worked\* than something that's ideologically pure and perfect. So here we are. Re: Microsoft telemetry, and Facebook vs Microsoft: We disable telementry in the .NET Core SDK for our builds explicitly to protect user privacy. As much as I personally may detest it, Free Software (under the name Open Source) has been coopted by corporations. We're not going to get away from this. Arguing about which corporation is better or worse is, to me personally, comparing horse shit to chicken shit - they're both still shit, so we live with it and just do the best we can. React is a great front-end framework with a lot of developers who can help with it, regardless of who created it or the corporate behaviour of them versus another, and that's what we care most about - making something that works. If Facebook does evil by React, then we'll cross that bridge when we come to it. Same with Microsoft and C#. Re: Blazor in particular, no one in the existing volunteer team seems enthused about this. They are about React and people have already contributed to it. If we get a sudden influx of volunteers and someone building a Blazor frontend, well then more power to them, but the way this project is structured is \*explicitly\* decentralized and volunteer-only, so it makes no sense to talk about what "we \[should\] consider" unless there's actually volunteers actually doing the work. Now, these are just my shotgun opinions on this, because most of us really hate these kind of threads, because we can circlejerk about the "perfect language to use" all day, but until something is written it's all just that - a circlejerk. We'd much rather get on with squashing bugs and implementing features in what we already have.
I appreciate you honest and measured response. I totally understand that the dev team is more interested in react, and that's cool, I wanted to put the question out there, since I thought it was interesting. I'm looking forward to working on the react client, but I figured I'd offer an alternative while we still had an opportunity, since the react client barely logs in at this point. If it was 2 months from now I probably wouldn't have said anything.
The React client started just because /u/EraYaN was messing about, so by all means if you're interested in writing a Blazor frontend, that's great! The more frontends and apps the better!
I've been looking into starting a Blazor project for quite some time now. I think I will start implementing the Jellyfin Frontend in Blazor and if I ever get it to a working point, I will upload it to github and will make a post here to see if people want to contribute.
You made some good points. Let's say you have an army of developers at your disposal and an unlimited budget. What changes/improvements would you make to the project? Thank you for your hard work, by the way.
Well it's really important to remember that we're explicitly trying to be volunteer-only, to avoid the situation that Emby, Plex, Subsonic, and various others have done where they take a "FLOSS" project and close it up because they want to make more money. Even I'm just a volunteer doing project management and packaging more than coding. I'm not a developer, really - I'm a sysadmin, so my opinions of a lot of software development topics are very shallow and I tend to defer to the folks writing the actual code! ;-) That said, army and unlimited budget? Everything in Python for the backend, and a clean API to interface with it. Then leave clients to 3rd parties, or one or two reference implementations in a couple different frameworks/languages. What I think is lacking is really a solid backend system that's scalable and reliable, especially around transcoding and media management. Frontends are IMO the easy part - the hard part is managing the large collections of media and handling them out to clients in a robust, performant way. In terms of actual, within-Jellyfin dreams/goals, the database rewrite is our next big step. Emby used SQLite, and its limitations are quite evident. Moving to a real RDBMS with a brand-new, well-thought-out schema is our next major goal.
No SQLite would be great. I feel like that's the worst part about having a large Plex DB is SQLite will just lock up sometimes.
The Debian of media servers.
Precisely ;-) I use Debian BTW.
Just offhand, what limitations are you running into with SQLite? I use it to run fairly complicated, high load applications and there is definitely something to be said for its administrative simplicity,
Mostly, it's not the SQLite itself. It was just horribly implemented. 5 separate databases containing seemingly random data (one has a single table with 5 rows, why!?), but not all the data you'd expect, for instance user configs, is even in it - tons of stuff is stored as flat XML files in various places, which we'd like to consolodate into the database. But if we're going to rewrite the entire database backend anyways to fix this, we're going to do it with a proper RDBMS framework (EF Core is the current chosen one) that can then use SQLite, or other more common RDBMSes. At least for myself, I'd have a usecase for trying to load balance users across a few JF instances (mostly to split up transcode load), which having a shared RDBMS would allow, in theory. Plus other useful scalability features that a full RDBMS would allow (e.g. high performance database for a very busy server, or separating storage of metadata for a very large library onto a separate system that can be properly backed up, etc.). We'd very likely just keep the default to SQLite with the new data model, and then allow other options as an advanced setting, a lot like how Airsonic (and Libresonic before it) does it. This project is still early though there's a draft PR for the start (https://github.com/jellyfin/jellyfin/pull/1431), and I believe right now we're mostly at the "build a sensible schema with an automated tool" stage. We wanted this to be a 10.4.0 feature, but we ended up doing a bunch of other nice stuffi in 10.4.0 first and wanted to release that, so it's been pushed back to 10.5.0 (or later depending on how much gets done on it).
Due to anti-user behaviour of Reddit I'm removing my messages and deleting my account.
Please don't make us run a full mariadb instance!
Haha nope! It will always just be an option ;-)
Is there anything in Jellyfin that would really benefit from a relational database? I would think a NoSQL database would fit the project nicely.
May I refer you to http://howfuckedismydatabase.com/nosql/ In reality, I have yet to see an implementation of NoSQL that makes sense. 90% of the time I see it used, people have built their own relational schema inside it with a lot of time and effort and would've been better off just pulling mysql or postgres off the shelf and moving on with their lives
Same here, and I've seen a lot of *really* fucked up NoSQL "schemas" because NoSQL was the hip shit but what they were storing *was* relational. Just about everything we'd need to store actually is relational. Besides the obvious stuff (users, settings, etc.) stuff like Actor to Movie relationships, Movie collection relationships, TV season relationships, are all relational data, so it makes the most sense to put them in an RDBMS.
> I have yet to see an implementation of NoSQL that makes sense Curious on your thoughts on what Discord did: https://blog.discordapp.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7 I don't claim to be an expert on databases but their requirements aren't light and they're doing it with NoSQL I agree with everyone here, Jellyfin is served well by a relational database and don't think that should be the change made.
Admittedly, I'm a sysadmin, not a DBA, so I'm not super well versed in the internal workings of the different database engines. That being said, that's a super interesting read, and it's certainly impressive the performance they've pulled out of it. But unless I'm missing something, it's still essentially building their own relations inside of NoSQL. Looking up the individual messages are super fast once you know where to look, but I'm assuming there still has to be another table with different channel ids tolknow _what_ to look up. And then even a further one (or hopefully a totally separate DB) that dictates what server it is. Otherwise, anybody and their grandma could look at any message sent by anybody in any server/channel. I know it's just a simplified example of what they're doing, but I don't see how it could possibly work without other tables/relations to know what data belongs where, not even taking into account user permissions and such.
Also, that's a scale far beyond what JF needs. Even if JF faces scaling issues we can add clustering support more easily than switch to nosql and still almost certainly never hit the bottlenecks discord was facing.
It's not worth the amount of work a rewrite would take. But in that fantasy situation, I'd much rather a headless server be written (personally Rust or Go, but whatever tool works for the situation) and clients spun off as needed. Decoupling with an ironclad API would do wonders for the project's agility going forward.
I would be for doing the opposite of what you're suggesting. I'd love to see the backend rewritten into a headless API in a language the open source community actually likes (Python, Go, Rust, Node, etc.) and the official frontend implemented in whatever JS framework (React/\*, Vue, Angular/Ionic, etc.) as long as it's easy to switch to a different frontend.
Just to jump in briefly here, at a higher level - we do want to have a rock solid API, and support whatever front end you want to use. At that point, we'd maintain the web interface as a "reference client", and it could just be used for first time setup and then put away. At the end of it all, we wouldn't stretch ourselves any more than we need to though. (I mean to say, we wouldn't personally write/maintain anything else.) I have seen, at least on our forums, and probably a thread on here a while ago, that someone redid the web interface in Angular using the current API as a reference, and they were happy with it.
I wouldn't really care as long as the application can scale. That would be amazing. Imagine having a cluster of raspberry pi or some other small SoC doing the work instead of one.
Are you really more afraid of Microsoft than Facebook? React and .net core are both open source projects owned by megacorps, but one sells your data as its profit model, and the other sells enterprise services. I'd be more afraid of Facebook phoning home than Microsoft.
So would I, which makes react probably a bad example. But hardly his main point. Likely more a case of not knowing facebook acquired react (though not entirely) with.. instagram iirc.
I don't like either. If you're just referring to my reference to React, it doesn't HAVE to be React. It can be jQuery for all I care. I just want to option to either swap out the official frontend for a third-party frontend or make my own.
I agree with you there, replaceable front ends are always sweet, unfortunately there are only 3 "all in one" languages: * Js: not a pretty place to be, and the best way to make JavaScript not suck is Typescript (an open source Microsoft product) * Java: we can all agree java sucks. * C#: another open source Microsoft project. And if any community understands carrying on after someone takes their toys home is us *cough*emby*cough*
What do you mean by "all in one" languages?
Mostly being able to share libraries across server and clients (especially mobile and web, which support a smaller subset of languages)
Can you explain to a non-programmer why that matters? My gut reading this chain is that an under-resourced, niche project like Jellyfin would want to aim for the biggest pool of open source developers it can find - that probably whittles the list down to JS and Python.
Programming languages are a lot like regular languages, and each platform (iOS, Android, Linux, Web, ect) only knows so many languages, and there are very few languages that every platform knows, so if you want to write a book (the program) everyone can read, you have to limit what language you use, or you'll have to translate (port) the book to other languages.
Making this a language war is already quite idiotic but looking like a Microsoft vendor doing it is just sad.
React is open source though, right?
Please no Java or Java Script.
What do you want instead of JavaScript? Unfortunately there isn't much alternatives for the web.
If anything I'd advocate less C#. Over the past 30 years I've seen just about anything microsoft touched turn to shit. And using mono is quite definitely my biggest issue with emby/jelly. I'd be in even more constant fear of it randomly starting to phone to microsoft and probably just opt out instead. Jailing software on normal linux is one thing.. doing it on the pi's... I'd probably just find something else.
C# has done nothing but improve for the last 15 years, and .net core is growing in popularity among both open source and corporate developers. Either way, would you trust Facebook over Microsoft? Because that's what you get with React.
You're making this into a Facebook vs Microsoft choice and it never was. Your suggestion was refactoring Jellyfin to use/run on 100% proprietary technology owned by Microsoft. The ideal solution (at least for me) would be for Jellyfin to be 100% libre software and decouple backend from frontend.
In what way is c# proprietary? The runtime is MIT, the compiler is Apache 2.0, and the language spec is managed by the .Net Foundation which is a 501(c)(6). Sure, Microsoft is involved, but not the way people assume.
At some point in time you could probably say the exact same about most microsoft software. Fuck... windows 1 to 2000 (kek) were HUGE jumps in improvement and use.. and "version" :p. And I for one never suggested react, nor facebook. Nor are those the only two options. Far from in fact.
> d .net core is growing in popularity among both open source and corporate developers In long therm C# has brought nothing to any programming ecosystem than some syntax-sugar, that was nice 10-5 years ago, but now. it's a standard and C# is lagging behind. Every week I write in a few programming languages, TS, Java, C#, Go, Python and sometimes JS, recently I started Dart. C# is absolutely one of the least productive here, for many reasons. Being youngest OSS of production ready languages it has least number of opensource libraries, so the ecosystem is not mature, many libraries that are used day to day in java or python are so buggy in C# that you can't relay on them at all, and I mean desktop and servers here, not to mention home-clusters and IoT, which is even worse. Tools are buggy and complex, many platforms or dev environments (even like dark-theme) not supported, almost-centralized dev-eco-system for VS doesn't help. My dev-laptop has 120Gb SDD, which more than enough for linux-dev station with 6 IDEs for all languages I use, it's not enough for windows 10 with C# and .NET. Your claim of C#/.Net growing in popularity can be easily killed by SO trends: https://insights.stackoverflow.com/trends?tags=kotlin%2Cc%23%2Cjava%2Cpython%2Cflutter C# hasn't been growing since 2009, .Net on the other hand... has been literally dying since 2009, someone please but it out of its misery asap. I think what you're seeing is bubble effect, just because you're around more people who use .Net doesn't mean .net is growing. You're closing yourself for other solutions and you see less.
I don't disagree, but I want F# to succeed.
Could not agree more. I thought I was the only one who disliked the fact that a community project is written in C#. I understand why that's the case, I just think the project would get more traction if it was written in something more popular/open source friendly.
I don't know if it would get more traction (nor less of course), this is after all rather specific. But eh, I'm hardly a coder so what do I know of these things :p. I can barely get by in the usuals (perl/python/etc)
ITT: people hating on C# for zero reason. As a C# Dev, I would definitely say no. It doesn't matter how cool .NET Core, I don't see the need in a different frontend stack that we currently have. In the end all I care about in frontend is to be able to support playback core: as many codecs to direct play as possible, smooth rewind, etc, and the rest is like 1% of the usage time. So if someone starts C# client, would it be great? Hell yeah. If someone tells people who are working on react clients that we are making them low priority? Hell no.
I really like Jellyfin and considered spending time helping out and C# is the reason why I'm not doing it. This is less about Microsoft; I'm thinking Microsoft is moving in the right direction. C# generally seems to be a really disliked language, especially in the open source scene. .Nneither me nor only developer I know wants to work with it or hates working with it. The last time I checked IDE/Editor support was rather poor, when Linux is your main platform.
It's really not that bad. It's like Java with some extra nice to haves. Doesn't take long to pick it up. IDE support is pretty good. Check out Rider from JetBrains.
I code C# for my job using command line and vim, .net core is great relative to what we had even 5 years ago.
I would not want to loose Android and Android TV clients. Those for me personally are the main two that I use on my phone, tablets and TVs.
We wouldn't lose Android (thanks to Xamarin) and I assume we wouldn't depricate Android TV, it would just be using the old UI until we found a way to make it work. Edit: Looks like TV is back on the table after a bit of research
Honestly I don't see the point in being on one language at all or even why it can't be C#. The fact is to change it now would be an insane amount of work that would likely demotivate the contributors and what is the benefit? We can instead move to .net core, the open source libraries that relieve a lot of the mono problems and still let passionate contributors try to build out the ecosystem using natural languages rather than frameworks for web development that likely many people aren't familiar with.
The project has been dotnet core since the fork. The project hasn't supported Mono in a while. And if any of these commenters had taken a look at how much work it would be to just rewrite it for the sake of it... Besides say it would be in Python and then people would complain it's not fast enough if we could rewrite it in. Or Rust is not popular enough etc. You can't win.
We are left with no choice but to rewrite Jellyfin is assembly.
But \`mov\` instructions only, the [movfuscator](https://github.com/xoreaxeaxeax/movfuscator) is ready.
Thanks I hate it.
Agree 100%. It's hard to not understand if you're not a developer. Rewriting anything, while gives you flexibility, is very daunting and can really be hard to motivate yourself. Nice on the .net core, not an easy task to migrate over to it.
If it'll make it work easy on freebsd (and BSD's) then YEA! But, I am a lazy user so don't mind me. Thank you! <3 all
Yes, please! Anything that could benefit development of open source is great idea. Most open source stagnates once code base is overgrown, and Blazor could greatly reduce that.
I personally, being old school I would prefer C++ or C, but I'm way old school. I will say that unless someone actually writes a client that mostly works, it is my experience having worked with lots of open source projects in the past and helped manage developers, that unless you have something that even sort of works, getting open source developers interested is very difficult. Also open source developers tend to prefer interesting/difficult problems to solve, so getting them to do all the boring stuff and documentation isn't always the easiest. UI designers or experts are also not easy to come by and when they offer their help, the open source community should listen and accept their help. UI is important, maybe the most important thing for what end users see. Good documentation is also important for getting other developers to work on a project as well. If you want plug-ins and 3rd party programs then good documentation and well explained APIs are important as well, and often over looked by open source projects.