I wanted to ask if you’re open to gradually move the codebase and -structure to a more modern way of handling things. Some suggestions I can think of:
moving dependencies and autoloading to composer
namespace classes (basically, change things to conform to PSR-2 and PSR-4)
manage JS dependencies with NPM
use a build-proccess for JS and CSS (e.g. utilizing NPM and Webpack)
introduce routing to reduce entry points (optimally to a single index.php)
I think doing this slowly and gradually would make tt-rss more future-proof and invite more contributions by other developers. I highly recommend this book and would love to work on modernizing tt-rss myself as it’s something a personally rely on.
I was making a suggestion, not saying “it must be like this”. Manually copying dependencies into a lib folder and having no idea about security related updates is just not a very future-proof concept.
This is not about NPM. I was just adding in NPM to handle the JS dependencies you obviously have. I’m also not a fan of the 10k dependencies that “modern” NPM projects come with. That has nothing to do, though, with using NPM to get security updates to JS-libraries that are used and having those defined in a central file instead of manually downloaded and copied into a folder.
Anyway, forget all the JS-related stuff. My main focus was on the PHP-related things, especially this:
moving dependencies and autoloading to composer
My question was, if you were open to such improvements. If not, it’s all good, you could have just said you’re not interested in additional help or new ideas instead of pulling this passive aggressive bullshit.
Hey. It’s all good. I’ll continue to use and like ttrss just the same. I just thought of ways how I could contribute. As modernizing legacy PHP codebases is my bread and butter, I thought I might offer that.
I didn’t mean to offend you and your code, I just wanted to offer what I have.
If you care, I’d love to hear what problem(s) you have with composer and why you consider it bad.
Is that sample code really just wiring a button to an event listener? Is that the canonical React way to do it? There needs to be a major advantage to jumping through all those hoops, otherwise, why would anyone bother?
My proposal had nothing to do with writing shitty code. Modernizing a codebase has nothing to do with writing shitty code (like what you posted). Modernizing doesn’t mean “make it more complicated than it needs to be.” That’s enterprise-syndrome code you’re thinking of.
What I proposed was moving from unmanaged or manually managed dependencies to using dependency management (for a start) and I specifically asked you what’s wrong with that (i.e. composer).
That’s in your head. Can you point me to where I proposed using a framework or changing the programming language?
You can insult me if that makes you feel better. I came here because I think TTRSS is a cool project (which implies that I respect your work). I have since been told that you’re not open to contributions in several personal emails.
It’s totally fine to run an OSS-project as a one-man-show. You might want to leave a note somewhere, though, that you’re not intrested in contributions other than bugfixes.
i’m not sure how i ended up writing an essay re: your post but the gist is i feel that your approach is not fit for tt-rss and its development. the end.
i also feel that library culture and everything related to it breeds terrible developers as illustrated above so i don’t want to personally partake in it but that’s really beside the point.
this is literally what you’re proposing - this whole thing is complicating stuff for no reason.
the tools you’re talking about might be great for some bootcamp nu-developer whose hello world app has 3500 dependencies because of cancerous npm culture there’s a library for every little thing. tt-rss doesn’t suffer from this problem and development approach. there’s a manageable amount of third party code which is like 90% dojo, that is precompiled in a certain way and bundled for a reason.
e: tbf it also might be justified for some fuckhuge software project with many developers which tt-rss is not and never will be. it’s a niche tool for nerds, everyone else uses twitter.
for tt-rss the end result would be either complicated deployment with more required external dependencies or me needing to generate easy to deploy tarballs so normies who have no idea about any of those tools (not only composer and npm but css compilers that you proposed) could unpack tt-rss on their shitty hosting and it would work oob.
please try to understand that tt-rss is not my job. it’s vastly easier for me to not deal with any of this shit, partly because i’m not functionally retarded and can just edit the stupid css file or w/e in vim if need be. also, i don’t feel that switching, for example, autoload systems just because i could probably use it for this one external library and it’s “more modern” while i have stuff working right now is justified.
i can easily see how the whole thing might feel archaic to some starry eyes 20 yo kid (not implying it’s you) but that’s what works for me.
see, there you go implying again. and yet somehow not everyone has difficulties with their contributions and ideas being accepted.
you said legacy, not me. by definition, “denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use.”.
First of all. thanks for taking the time to explain.
It would actually make things easier, no matter what size of project
Okay, I can understand that point. You’d definately need to supply tarballs for easy installation. I wouldn’t call a 2-line “build-script” to create those complicated, though. As you can imagine by now, IMHO the benefits far outweigh the extra complication of creating that tarball. Your “small” project has more dependencies than many enterprise-projects I’ve worked with. composer is just simplifying things there, not complicating.
I was talking about the implied usage of frameworks and other languages, not the legacy code. I see how such a comment sounds condescending and I’m sorry for that. For me legacy is a word without judgement. Things like not using composer or having that many entry-points to your app instead of using some kind of routing is legacy PHP (in the view of the wider PHP community including PHPs creators). Forget all the other stuff I said (build-process, npm, css-compilers)… that’s just personal preference and has nothing to do with legacy PHP. Neither does if you write procedural, functional or object-oriented code.
Anyway… I’ve taken too much of your time. Thanks for explaining. It helped me understand why you don’t want composer, even though I still think you should use it.
i have stopped doing point-releases and daily tarballs because maintaining an updater (i can’t force tar zxfv on users on a daily basis) is too much effort as opposed to git pulling from time to time which is optimal both for me and for users (they run uptodate code with minimum effort, i don’t have to decide when to tag point-releases etc). therefore i need the dev tree to be functional oob.
maybe i should have started with that but i really hate all this npm garbage too much to not rant about it when an opportunity presents itself. :shrug:
btw, tt-rss does use (very simple) routing for almost everything and it’s mostly OOP. it’s not MVC though because of reasons.
The easy middleground would be to just include the composer /vendor dir in git. That way people can use what the pull out-of-the-box without needing composer and you can use composer for easy dependency updates. Many people do that for exactly your reasons.
composer != npm.
That’s what I meant before… MVC is often just overkill… not going that route is a design decision that has nothing to do with legacy PHP.
I’m not dakira, but the proposal would help very little in terms of deployment. It would even complicate it unless additional things (like an installer or a pre-flight check script or similar) are be added. npm also adds a new layer of complexity where you’d have to ensure each server has a working Node.js installation, and the correct version to boot. The way it is now, the developers make sure the codebase includes all its dependencies (both PHP and JS) so end users don’t have to worry about any of this.
The advantages would be mostly in standardizing development, if anywhere at all. But as fox already said doing this would be much more helpful for very large projects with large teams, or a project with some experienced and some inexperienced developers working together. The frameworks can help bring everyone’s code in line.
Composer might improve dependency management, but that’s not even guaranteed. Just because you have Composer doesn’t mean you automatically have all your dependencies constantly updated and working. Usually you can’t just let end users update the dependencies either because you don’t know if newer versions break your software (not every library uses SemVer properly). Thus TT-RSS devs would have to verify things on every single dependency update anyway, and they already do this now by managing dependencies by hand.
None of that would change. As I discussed above with @fox, from the user-perspective no composer usage would be necessary.
Although it is in my original suggestion in the top post, lets concentrate on composer and forget npm and such. On correction, though: npm and nodejs don’t belong on the server if you use them for js/css dependency-management and compilation. They only live on the dev-box. Running npm run prod compiles and minifies all js and css dependencies into one app.js and app.css respectively. That’s all the server (and user) ever sees.
The proposition would be to keep it that way. Just include the composer /vendor dir in git and everything stays the same for the user.
As discussed above with fox, the advantage would be in dependency management because that’s what composer does, nothing else. With the number of dependencies ttrss has, that would be a pretty big gain. Standardizing development is not the goal here and wouldn’t be achieved by just using composer. At no point did I even talk about using a framework. I prefer them for my own projects but if they’re not needed/wanted composer makes it at least easier to use and manage external dependencies.
From the dev perspective it would (usually) just be this:
Instead of manually downloading and extracting every single dependency. IF there is a problem with a library that doesn’t follow semver, you’d run into the exact same problem when manually updating. With composer you just set the version of that library to what last worked and run composer update again.
Nothing in the codebase would need to change for this (except for the autoloader-snippet), nothing would change from the user perspective. The only thing that would change is that fox would save time which he claims he doesn’t have.
The same is true for managing JS/CSS dependencies with NPM but in that case I totally understand @fox s disdain (it does work nice but pulling in 10k dependencies to reformat some CSS is just wrong).
tbh i pretty much only update libraries if there’s a security shitstorm like it happened with phpmailer, otherwise as long as things work properly why bother. i don’t get paid to repeatedly check if some library guy broke more than he fixed in a new version (that is if there’s a possibility of an update in the first place, several libraries tt-rss includes have dead upstream).
the only exception was dojo which required a lot of tinkering but was overall a solid improvement, i see no reason to go and check if qr code generator or whatever had an upgrade, who cares, it does what it has to right now.
Developers that want to play with all the neat shiny new toys, without any consideration about what it takes to actually USE the end result… fah. At some point, as an end user, it becomes too much trouble to use their glitzy new shit.
I do web development and server administration. I use software that, like TT-RSS, the developer just includes what he or she needs. I unzip or git pull and I’m done. I also use software that uses Composer. I have also used NPM and nodejs.
The way TT-RSS is done is by far my preferred method. It’s simple. Easy to use. No need to update dependencies unless there’s a need (security, updating to remove deprecated PHP functions, etc.).
I agree with most of the comments in this thread that support keeping things the way they are. These newer tools are shiny and pretty, but I have yet to see what they bring to the table. In some situations I’m sure they’re useful, but in the majority of the stuff I do it simply adds complexity without providing any real benefit. Why bother updating a list of dependencies in a file when I can just drop the necessary (and known working) library in a lib directory and continue on my merry way? Seriously, what am I gaining by having to install Composer and run it everytime I want to update? I see no benefit to this at all. Maybe in a large project where you have a myriad of developers, but as fox once mentioned, TT-RSS is pretty much done. It’s been around for a long time and it works. Why change for the sake of change when this actually works and works well? (That last question is rhetoric.)