mybb2
mybb2 copied to clipboard
mybb
Evaluate the possibility of removing jQuery as a dependency.
We currently rely on jQuery for some extremely simple tasks (such as selecting elements and hiding/showing content).
We should evaluate whether requiring a large library such as jQuery is really necessary and whether we can trim some fat with either our own code or with lightweight alternatives.
While I agree we should try to avoid large libraries jQueryis a kind of standard and required by a lot of useful Javascript scripts.
Interesting article why Zurb foundation switched from Zepto back to jQuery: http://zurb.com/article/1293/why-we-dropped-zepto
As long as it's only used to eg select elements we possible could drop it. However as soon as we need some kind of library it would be best to use jQuery IMHO
I disagree with this. As @Stefan-ST has previously said a lot of useful javascript scripts rely on jQuery.
But if we don't use them internally there's no point including it by default.
IMO it would be cool if nothing depended on jQuery, even if you include it for ease of use for beginners.
But if we don't use them internally there's no point including it by default.
Correct, however right now most of our 3rd party scripts require jQuery: https://github.com/mybb/mybb2/blob/d312ba51e33824becbce3e5e33c6358e10eda981/gulpfile.js#L18
The thing about jQuery is that having integrated into the forum system by default is worth a lot to the admin and devs in terms of potential. Yes, it would be easy for an admin to include jQuery, but speaking as a developer, if I wanted to use some jQuery plugins with one of my MyBB plugins, I'd have to deal with support threads helping people to install jQuery-- or automate its installation and have to deal with support threads helping people to remove one of the two header includes.
jQuery is king right now and will be for a while, it seems. It is a safe bet in my opinion.
but editor not will require jquery? Editors that I know mostly uses jquery as dependency.
Not all editors are dependent to jQuery: Quill is so far the best Open Source editor I've ever seen and I had started working on a Markdown parser for it, which was the only thing missing and preventing me to launch it as a 1.8 plugin.
However, I am pretty much with @WildcardSearch. Being a developer, it's hard to maintain a package for something which does not have jQuery already in place, and so would be the core code IMHO.
There's definitely a better way to approach this than stuffing jQuery in there just because it's easy on devs. Maybe a JS library manager. Either way is assuming an admin customizing templates can't include (Or find a tutorial on how to include) something as popular as jQuery (No technicality here, literally copy + paste) really the right thing to do?
Honestly it would be better if plugin devs could just list jQuery as a dependency of the plugin and it would be installed when the plugin is.
Honestly it would be better if plugin devs could just list jQuery as a dependency of the plugin and it would be installed when the plugin is.
Do you remember how many support posts Euan got when he used jQuery in MyAlerts 1.x when MyBB was using Prototype? The amount of people who couldn't check the header include to make sure jQuery wasn't in there twice was ridiculous.
I may be wrong for saying this, but I just don't have a lot of confidence in even marginal intelligence from the general populace. I've seen too much. #scarred
You can include jQuery by default, but you should not use jQuery for simple tasks, where Vanilla JS is definitely a few hundred times faster.
http://vanilla-js.com/
It might only be used for simple things now, but will that always be the case? It really depends on what we're planning to do for 2.0 down the road.
Modern forum software are using more and more JavaScript to enrich the user experience, especially in the new ones like NodeBB. This doesn't mean that MyBB 2.0 should have an instant messenger instead of PMs like they do, but they are a good source of inspiration.
Speaking of editors, they have an interesting approach for an editor. There are two panes. The left one has buttons on the top for things like bold, and all that.
You type the mark-up on the left pane, and you'll see a live preview on the right. Something like that might be easier for us and admins to customise than a WYSIWYG Editor which does all sorts of black magic to get things done.
@Azareal Things like this can be done without jQuery so it's inconsequential. I think the main issue at hand is which is more new user friendly. The main three options in my mind are "No jQuery", "Include jQuery but don't use it" and "include and use jQuery".
Remember I also hope to have a JavaScript manager like we have for Stylesheets, wich will hopefully allow scripts to have dependencies such as jQuery, which can be pulled in locally or from a CDN or elsewhere. I've still not decided how this will work or look like, but it would be very nice to have.
If the core doesn't have jQuery, but an admin/theme author needs it for a script, that script would be added via the JS manager in the ACP, with a jQuery dependency defined and in that case jQuery would be used. Obviously this only works if all admins/theme authors/whatever use the JS manager API to manage all scripts, but since 2.0 is from scratch, we can hopefully get that into people's heads.
I'm a fan of how Codepen handles it with easy includes for popular libraries.
Storing resources/links with themes and allowing them to be added easily through an interface seems like a fine solution to me.
@Eric-Jackson Codepen is one of my inspirations :smile: Audentio used to have a similar plugin for 1.x too.
Pure Javascript might be a good alternative, although it really depends on whether we use the newer features or not. It can be pretty tricky to get by without jQuery on older browsers, and jQuery is a nice convenenience even today, although it is losing it's value.
I try to avoid jQuery whenever possible, except when I have to put a lot of work into putting an alternative into place. A mixed approach might confuse developers though.
@Azareal we're already transpiling ES6/Typescript so browser compatibility isn't an issue. Nowadays "old browsers" isn't too much of a thing thanks to npm (Or more specifically Babel) anyway.