[PROGRESS] ES6/ES7 support roadmap

[thednp]

Hello everyone. How you all doin? I want to open a public debate on developing/transitioning towards ES6/ES7 standard(s).

Progress

• we need a new bundle builder (lib/bundle.js) to do ES6/ES7 index.js -> ES5 bootstrap-native.js compilation + uglify work, that's where YOU come in (rollup, babel, promise, whatever you need, bring it), thanks to @midzer we now have a rollup script introduce rollup bundler #326
• debug and fix all issues resulted in removal of manual tokenization or other module import/link related issues
• global object is now BSN = {components:[], initCallback(), supports[]}
• Toast destroy() and dispose() methods are supposed to do the same
• rename destroy() to dispose() method for all components
• custom file headers // BSN | author | License style header for .min.js files
• remove bower, all old code, code cleanup
• rework polyfill.js for ES6/ES7, include it later into the rollup grinder
• we need a full documentation for V4 page, the future main page of the project
• wiki updates
• evaluate and discuss code structure to find opportunities for new features and code quality improvements (constructor, private & public methods, etc)

Initial Notes

• the main focus is going to be mainly V4, which means V3 development will come to an end
• at the point where we have BSN V4 modernized with ES6/ES7, V3 main file will be renamed to bootstrap-native-legacy.js and moved to a BSN-V3-legacy branch
• after BSN 3.0 stable release, our V3 will still be available on CDN links only for versions ^2.0.27
• following the above, the main demo will switch to V4, with the addition of proper guidelines
• the new documentation should include solutions for highly dynamic applications, I noticed devs ignore the wiki (probably it's not well organized?)
• manual memoize/tokenization (Eg: element[styleString] comes back to element.style) will go away for easier module "connectivity",
• following the above, JavaScript API strings (Eg: offsetTop, marginLeft) will all be removed, but essential utilities will remain untouched such as styleTip or event related utilities like emulateTransitionEnd and on, off
• the expected size of the bootstrap-native.min.js will get back from ~20kb to around ~40kb, but the gzip size will decrease by about 7-10%
• we open the opportunity to debate/suggest prototype structure per component (what's going public into this or what stays private)
• all the above mentioned changes will surely require major changes to the build scripting for ES5 compatibility
• developer PRs are highly encouraged, but ONLY after a prior discussion

Please join, I need to know your key points, availability and any suggestion.

This is a draft, expect changes

[midzer]

Heyo,

tbh I'm in no hurry with ES6/ES7 code base transition. The real benefit I realize from your post is a gzip reduction which I welcome ofc. Where do you have the numbers from? From my experience libraries tend to get larger, but this is just my observation.

Upcoming Bootstrap v5 might bring additional work to bsn already. We should focus on this task first, I think

[thednp]

@midzer in regards to manual tokenization, check this out #269.

I think BS5 will come with ES6/ES7 sources, no jQuery dependency, and mostly minor tweaks to components for usability, accessibility and hopefully less or no dependency.

As for the hurry aspect, I think it's a good time to gather around and have a little chat about it, put some ideas on paper and come with a plan. We're not competing with original script, we try and make it better in some ways.

[thednp]

I have a first proposal for our components: how about the possibility to enable using Tooltip / Popover simultaneously with other components like Modal, Dropdown, Collapse, Button and Tab.

The solution is simple: we just use a different markup for Tooltip and Popover targets. For instance Carousel uses data-ride="carousel" or Alert / Toast use data-dismiss attribute.
We can just use data-tip="tooltip" and data-tip="popover".

I know this would be quite the difference with the original plugins, but I think it's necessary in order to enable this functionality, so please let me know what you think about it.

[cvaize]

What do you mean "simultaneously with other components"? Do you want to use Modal , Dropdown , Collapse , Button and Tab in Tooltip (in tooltip-inner)?

[cvaize]

I suggest to apply architecture of import of components, with possibility to include in bundle only the components necessary to the developer. Now the bundle always includes all the components. When switching to ES6/ES7 using import Name Component from 'bootstrap.native/NameComponent.js' and changing the approach to stand-alone components we will allow developers to choose which components they will use in the project, thereby reducing the size of the bundle. As a tool for assembling and shaking the tree, I suggest using "rollup".

[thednp]

What do you mean "simultaneously with other components"? Do you want to use Modal , Dropdown , Collapse , Button and Tab in Tooltip (in tooltip-inner)?

Dropdown with Tooltip, Modal with Tooltip, Button with Tooltip would be nice, however Dropdown and Modal may not be needed. I'm thinking of combinations that make sense.

I suggest to apply architecture of import of components, with possibility to include in bundle only the components necessary to the developer. Now the bundle always includes all the components. When switching to ES6/ES7 using import Name Component from 'bootstrap.native/NameComponent.js' and changing the approach to stand-alone components we will allow developers to choose which components they will use in the project, thereby reducing the size of the bundle. As a tool for assembling and shaking the tree, I suggest using "rollup".

No, you can build a bundle with only or except the components you want, while the ES6/ES7 standard will make this possibly easier to create builds. But mostly I agree with your suggestions.

[midzer]

Howdy and Happy New Year!

Great work so far 👍

I'm just working on it to bring rollup bundler into the process. I'm gonna do a PR once I got something ready.

[cvaize]

Started testing es6/es7 code. I use rollup and laravel-mix module bundler. laravel-mix is a wrapper over webpack. At the moment, I want to immediately clarify why to place the initialization code in the components?

When initializing through importing only the necessary components it is not used.

I suggest that you put it in the General initialization file.

[cvaize]

Write when I should start testing the health of all components. I plan to start tests on Chrome, Safary, Firefox, Safary (Iphone 5)(Old browser), Edge, IE11, IE10, IE9.

[thednp]

@cvaize we're looking into ways to include components and their respective utils as well as initialization scripting. What would you suggest?

[cvaize]

Just put the initialization in a shared file.

[thednp]

Are you sure we're not adding it where we don't need it? Don't we need to filter that out if not needed? IDK, I'm just asking?

[cvaize]

I am sure that in the component General initialization when I import it like this is not involved.

[cvaize]

Most experienced developers import only the components they need, and our goal is to ensure that these components do not contain unused code.

[cvaize]

At the moment, this is all, I will conduct performance tests in browsers when you write to me.

[thednp]

I know, but just for me to know: rollup will try and remove unused code or just concat code that modules actually need?

Also how do you suggest we implement options for the rollup? (components to be used, add/remove init/remove)

How about using uglify instead of rollup-minify we use now? I hope we can do custom headers for the minified files.

[cvaize]

I use webpack like millions of people do. Therefore, you should not rely only on rollup. From components it is necessary to remove the code of mass initialization I consider. People are more likely to import the component, put the element in the component constructor, and then manage the created object through its public methods.

[thednp]

@cvaize and @midzer please test latest master and let me know if we can move on to the next part: documentation & wiki updates.

[cvaize]

All right, I'll run tests soon.

[midzer]

According to https://medium.com/@kelin2025/so-you-wanna-use-es6-modules-714f48b3a953#dd9e conclusion we should prefer iife builds over (deprecated) umd builds. Furthermore package.json should have a module field.

I will give more feedback when I finished deep testing master in some of my projects.

[cvaize]

The initial test in Google Chrome I finished, after fixing the bugs found, I will repeat the test. In the current test, I did not consider working with parameters. I'll test them in the next test.

[thednp]

@cvaize my last couple days I've done alotta work and specifically testing component options, since I've changed init object structure, so you'll be surprised there.

@midzer I like how the iife builds look like :)

[cvaize]

Checked the closed issue. I will continue the tests tomorrow, today I can not devote more time to them.

[cvaize]

I will continue the tests tomorrow, today I can not devote more time to them.

[thednp]

Guys what do you think of setting up an auto-polyfill script via babel.js?

[tamb]

I'm kind of in favor of two approaches:

1. completely ignore polyfills and recommend ones needed for specific components
2. transpiling the library down to ES5 and use an autopolyfil script via babelrc.

[swrobel]

Is the webpack loader still required? I ask because, although it's still mentioned in this project's README, it isn't marked as compatible (per peerDependencies) with the 3.x release of Bootstrap Native.

[thednp]

It's not updated, I'm updating the README.md now.

[thednp]

@swrobel do you have any suggestion on what that loader should look like considering the new library code base and build scripts?

[swrobel]

@thednp unfortunately not