yiisoft / yii2-gii

Yii 2 Gii Extension
http://www.yiiframework.com
BSD 3-Clause "New" or "Revised" License
202 stars 192 forks source link

Re-write Gii JavaScript not to use jQuery #282

Open samdark opened 7 years ago

samdark commented 7 years ago

In 2.1 we plan making core jQuery-free and it would be cool if extensions would follow the same path.

githubjeka commented 7 years ago

Why need to do this for a tool which used usually in a developer's environment? I see no reason to spend force on this.

samdark commented 7 years ago

Because we don't want jQuery to be required anywhere. Including development environment not to force people to fetch it from package managemer.

githubjeka commented 7 years ago

Make sense, but ... IMHO to easy fix this issue(package managemer) you just include js packet in to the tool. In future you need just update jquery, instead your supporting for javascript code for different browsers and cases of memory leaks.

samdark commented 7 years ago

Yes, that's an option.

rob006 commented 7 years ago

Twitter Bootstrap requires jQuery - are you going to make Gii also TB-free?

klimov-paul commented 7 years ago

Twitter Bootstrap requires jQuery

Twitter Bootstrap does NOT require JQuery by its nature. You can use it without JS part. However for yii2-bootstrap - it is a matter which should be resolved in the future.

rob006 commented 7 years ago

TB has jQuery in dependencies: bower, npm. So we will install it anyway or hack dependencies to skip jQuery.

Also I don't get why jQuery is a problem here. Why TB JavaScript and CSS is OK, but jQuery needs to be removed?

klimov-paul commented 7 years ago

https://github.com/twbs/bootstrap/issues/22748 https://www.npmjs.com/package/bootstrap-without-jquery

rob006 commented 7 years ago

@klimov-paul Sorry, I don't get what you want say by this. Right now TB depends on jQuery (see my previous coment), and I hope you don't want to replace official bootstrap package by some random fork.

klimov-paul commented 7 years ago

Currently we started the developement of v4 for a while, so it's a bit earlier to begin to remove jQuery as dependency.

But we thought about removing it for a next major release.

klimov-paul commented 7 years ago

Bootstrap itself can function wihout a JS, during customization you can disable it. There is a common requirement of usage Bootstrap without JQuery and several 'fork' solutions exist already. Actually having mandatory dependency on JQuery at Bower/NPM is a mistake on Bootstrap behalf. Still thier authors consider removing it in future releases.

rob006 commented 7 years ago

Dropping jQuery may happen, but not in v4. Bootstrap v3 was released in 2013, and we still not have stable v4, so it may take some time before getting official jQuery-free Twitter Bootstrap...

And using fork may create issues with duplicated dependencies - Gii will use fork, some extension will use official package, and we have 2 bootstraps instead one...

klimov-paul commented 7 years ago

It may also happen that yii2-bootstrap will drop mandatory dependency on Bower/NPM for bootstrap extection, as it more likely developer will re-built actual CSS from source *.less or *.sass, which should be included in his project source (vendor folder can not be used for this). Thus while enabling Bootstrap, Gii or Debug developer should choose, from where he wishes to pick up Bootstrap CSS.

klimov-paul commented 7 years ago

Also note that Gii has a console version, which does not require any CSS/JS dependency. Thus actually you do not need web interface to use Gii at all. Actually there could be a demand to have 'web free' Gii version.

klimov-paul commented 7 years ago

Dropping jQuery may happen, but not in v4. Bootstrap v3 was released in 2013, and we still not have stable v4, so it may take some time before getting official jQuery-free Twitter Bootstrap...

This is the matter of demand. Usually developers do not mix Composer and Bower dependencies into a single one, like Yii does. Thus they do not consider this dependency as a problem, since it is easy to bypass. However this matter is just the same as https://github.com/yiisoft/yii2/issues/9525 . In the era of ReactJS, Angular and so on CSS framework should not depend on jQuery. There is no persistent enough developer to ask for it yet.

Also it seems that Bootstrap major versions are coming out faster then Yii ones...

klimov-paul commented 7 years ago

However, the fate of Bootstrap is better to be discussed at yii2-bootstrap. As for this issue itself: while I admire @samdark's optimism, I am not sure this goal can be reached.

There several major JS feature related to Gii web interface:

These are not a trivial matters, implementing them without usage of major JS library will cause a lot of effots. It may actually end in creating our own JS framework...

The form-related JS issue should be solved at yii2 repo. basing on solution like: https://github.com/yiisoft/yii2/pull/13839

klimov-paul commented 7 years ago

https://github.com/twbs/bootstrap/issues/23204

rugabarbo commented 6 years ago

I understand your desire to make core jQuery-free: https://github.com/yiisoft/yii2/wiki/Roadmap#client-side

But I don't understand why the next steps is needed for the 2.1 core version (according to «Yii2 Roadmap»):

?!

Why?

yii2-gii and yii2-debug are separate extensions, they must have their own roadmap not associated with the core roadmap. Why core version 2.1 requires these changes of gii/debug extensions?

samdark commented 6 years ago

Because there's no sense in releasing framework w/o these two tools.

rugabarbo commented 6 years ago

Why?..

It's just extensions. For example, I've been using Yii without them for many years.

rugabarbo commented 6 years ago

These extensions are usually placed in composer.json in require-dev section: https://github.com/yiisoft/yii2-app-advanced/blob/f9100a0f15e0c4c53db77bac1559d6e29304b0eb/composer.json#L22-L28

I generally do not see a problem in that development tools require jQuery. It's crazy to complicate the development of development tools with the desire to have super clean jQuery-free code. This is not the core. These are just development tools.

samdark commented 6 years ago

Well, that's correct. It's not a huge priority.

rugabarbo commented 6 years ago

Well, that's correct. It's not a huge priority.

If so, then we need to remove these items from the core RoadMap. At least remove them from the requirements for version 2.1...

samdark commented 6 years ago

Done.

schmunk42 commented 6 years ago

Something to consider, Gii is a completely stand-alone module, it would be OK if it depends on jQuery, since you won't need it in the frontend or backend of your production server.

The debug-toolbar is included in frontend and backend, even if it's just during development - it would be nice if it would be jQuery free.

samdark commented 6 years ago

Exactly the reason why these issues were created.

cronfy commented 6 years ago

Me too who does not understand why to remove Jquery from Gii.

Gii is a separate module with completely own html layout. It does not intersect with user's html layout at all. It may safely use any JS/CSS libraries he wants not affecting any user's application page.

The only problem is that in application (in vendor/) only one version of Jquery can exist. If Gii requires, say, Jquery 3.3.1, but a user installs in some future Jquery 4.0.0, they will conflict.

But this can be easily solved by removing Jquery dependency from Gii's composer.json, and bundling Jquery with Gii's src/ instead. Then Gii will use it's own Jquery, not conflicting with user's Jquery in any way.

Same thing with bootstrap etc.

I do not understand why Yii developers should spent time on developing their very own javascript framework just for Gii, if they can solve this problem in this very simple way, use Jquery and be happy.

schmunk42 commented 6 years ago

The only problem is that in application (in vendor/) only one version of Jquery can exist. If Gii requires, say, Jquery 3.3.1, but a user installs in some future Jquery 4.0.0, they will conflict.

This is a also very important regarding client-side package management, maybe "the" reason to use native npm.