We’re pleased to announce that the early access version of Sencha ExtWebComponents is now available. ExtWebComponents provides hundreds of pre-built UI components that you can easily integrate into your web applications built with any framework, or no framework at all.
Table of Contents
ExtWebComponents Early Access Highlights
- Harness the power of big data with the powerful Modern Grid, which includes Grid Filtering and Grid Locking capabilities.
- Allow your users to slice and dice data with the Pivot Grid ad-hoc report builder component.
- Create beautiful, dynamic applications with the 115+ Material design inspired components including Chips, Multi-select Combobox, Color Picker, Tabs, Dialogs, Sheets, Menus, Toolbars, and Lists.
- Develop for all screens and environments using responsive layouts.
- Build easy-to-use data entry forms using the extensive collection of form fields.
- Add interactive scheduling functionality to your app with Calendar components.
- Add stunning data visualization capabilities to your app with an extensive collection of charts and D3 visualization components.
- Compress and optimize application builds with the provided Webpack plugin.
- View ExtWebComponents Kitchen Sink examples for hundreds of components.
Try ExtWebComponents Early Access
- Download the ExtWebComponents Early Access trial
- View the ExtWebComponents Kitchen Sink examples or download from github
- Read the Getting Started Guides for ExtWebComponents:
Learn More
We invite you to join us for a webinar on May 8th at 10am PDT / 1pm EDT / 6pm BST to learn more and get an in-depth preview of how to use ExtWebComponents. Register here: https://www.brighttalk.com/webcast/11505/357554
Share Your Feedback
We’re looking forward to seeing the awesome web applications you create with ExtWebComponents! We value your feedback and hope you will tell us about your experience by completing our survey, so we can continue to improve the trial user experience. We also invite you to share your feedback in the ExtWebComponents forum.
Congrats on the release. However, looking at some of the code, I’m very worried about the quality of this product. Using a setTimeout to work around timing issues is what you do when you first start coding. I would turn down paying customers in order to never touch this product.
Hi Mitchell, just wanted to update you on the feedback you gave on the router – we have refactored the router to eliminate the timers, and have also created a separate npm package for the router, since it is not part of the ExtWebComponents product, it is a simple router form the Kitchen Sink sample app.
I have started a forum post on this – please comment there with any feedback
https://www.sencha.com/forum/showthread.php?471738-added-new-ext-web-components-router-package&p=1324704#post1324704
Marc
Mitchel, Thanks for pointing that out – I see it in our simple router that we implemented for the Kitchensink – that router shouldn’t need the setTimeout – not sure why it is there – I will investigate.
Also, the router is not part of the ExtWebComponents product – just a simple vanilla router used to showcase using ExtWebComponents without a framework – it makes sense to remove remove it from the npm package – which will be done for the GA, in not sooner
Ok, that was one example. If you’d like another: https://github.com/sencha/ext-web-components/blob/ext-components-7.0.x/packages/ext-web-components/lib/base.js#L11
Didn’t get too far on that file before giving up on reading it.
Also, zero linting. This is really a big issue. Not only does it catch some issues people have had but it also attempts to keep code styles in sync between people. It’s simple to setup, configure and run so why not?
Idk why the tests are in a different package but at least there is something that says tests.
Who is using console.dir all over? Feels like they don’t know the difference with console.log but that’s nitpicking I’ll admit. Although seeing those console.* checked in makes me wonder if people know about setting breakpoints (I assume you all do tho).
Working on teams with mixed experience, things like pull requests are great for code reviews and allows a more senior person to help a more junior person. Once that senior person merges code, that code belongs to them too.
Mitchell, totally agree on the linting – we had some issues correctly incorporating it into the build but i believe we have figured that out now -https://github.com/mgusmano/ext-web-components/tree/ext-components-7.0.x/demos/eslint-demo. That will be incorporated into the builds soon.
BTW, never too nitpickey on things… console.dir seems to work better with objects and it acts just like console.log for strings… helpful in cases … (nothing like debugging with breakpoints, totally agree with you…)
As you are pointing out, since this is an Early Adopter version of the product, we know we still have some work to do but overall the product is working quite well and we really wanted to get an Early Access release out to customers and prospective customers – and this is the type of feedback we want to make the product the best it can be.
Being the Product Lead Architect – I am very open to feedback like this – and if you or anyone else has any feedback on the product, I am listening
I do value input from very knowledgeable people like you – keep it coming – even open to having a webinar soon for anyone who works with the product and would like to share feedback – let’s see how many people we have with feedback and if it makes sense I will make it happen
Marc
Don’t forget about console.table.
https://developer.mozilla.org/en-US/docs/Web/API/Console/table
ahh yes, need to start using that! thanks
Congratulation guys.
thanks! looking forward to your feedback
Marc
Is ExtWebComponents a stand-alone product (i.e. separate from ExtJS)?
If so, will it be possible to purchase a single license of the product, or will this also be subject to the deplorable five license pack? (by “single license” I mean a real perpetual license that gives you the right to develop and maintain the code without having to pay any fee, obvious or hidden).
Thank you in advance.
Yes, ExtWebComponents (just like ExtAngular and ExtReact) will be a stand-alone product (along with also being a part of the Ext JS Enterprise License).
And the really great news is that, with version 7.0, we will be offering an ExtWebComponents single developer perpetual license!
(and, we will also be doing that for the ExtAngular and ExtReact products).
Keep your eyes open for a blog with announcements of the release of ExtWebComponents and Ext JS version 7.0 – its coming soon…
Great news !!!
I think it should be part of the PRO also not only enterprise, every new enhance is part of the Enterprise and what about the other customers. for me as a freelance developer is hard to keep up with see so much new stuff i cannot get because i have to upgrade my current pro license or paying more and also renewals each year ? end lets say if i have stayed since version 4 really i have paid like 3 year of no crucial upgrades, just bug fixes which should have been since the initial release of the version.
And also as Mitchell pointed out errors it seems is not going to be a so stable release with so many code flaws,
You need to make things more accessible for everybody , not just trials, that’s the reason so much opensource frameworks are gaining much power each day.
but hey its just my POV.
The download link doesn’t work. I have tracking content blocking on. Disable it, please.
Tried it out on other browsers the situation is the same even though I don’t have content blocking on other browsers.
Which link are you having trouble with?
https://www.sencha.com/products/extwebcomponents/evaluate/earlyaccess/
Sencha likes their tracking codes, I can’t use Brave and get to this blog, results in a 504 error every time.
They never asked me for a consent. So I believe it’s kind of illegal.
Works for me. I’m responding using Mac brave-browser Version 0.63.55 Chromium: 74.0.3729.131 (Official Build) (64-bit)
Hey, very nice article. I came across this on Google, and I am stoked that I did. I will definitely be coming back here more often. Wish I could add to the conversation and bring a bit more to the table, but am just taking in as much info as I can at the moment. Thanks for sharing.
On-Demand Mobile App Development Company
Spammer
Glad to see ExtJS moving in a progressive direction.
I examined the DOM of color picker example, and the actual ext-colorselector DOM node has no contents in it and it’s 0 height and width. The actual Color Picker is rendered separately from it, elsewhere, and is just normal ExtJS code.
Could you please elaborate? I mean, if I run a DOM query on ext-colorselector I will get just a useless node; the entire color picker exists elsewhere. I’m not a pro in WebComponents, but this doesn’t seem right…
afaik all these integrations still use Ext JS fully under the hood. It just tells Ext JS to render in some DOM node and Ext JS still handles it as if you used renderTo or render(). The color picker being rendered elsewhere is how Ext JS manages floating components. Go to the modern kitchensink, open a floating things (like a popup or a select/combo) and then watch the #ext-global-floatWrap node (it’s a direct child of the body, course with these examples they are within an iframe now).
also, when you use ExtWebComponents at the ‘root’ of your application, the product takes advantage of the Ext JS viewport – which then means that the entire Ext JS tree of components is under the viewport div. That does not have to be the case – as Mitchell states, components can use the ‘renderTo’ approach, which is exactly what happens when you add an ExtWebComponent somewhere on your page under some html element
I examine the DOM objects and I do not see any shadow DOM node. That makes me wonder if ExtWebComponents supports shadow DOM ?, If yes, there are some examples published? Thank you.
These web components are just a bridge meaning Ext JS takes care of the rendering within the web component, the web component basically just gives a way to receive props (configs) and an element for Ext JS to render in to. This is important because the compiled CSS isn’t any different than if you were to just use Ext JS and are global styles… which cannot get into shadow DOM.
Thanks for the feedback, I understand some trade-off, especially in what it does to the application of styles and the shadow DOM.
But exactly, that’s what worries me, shadow DOM is the key feature in the new web standard (I know the technology very well, and I have big projects developed with it, and I’m really interested in incorporating extjs for certain parts. I’m working with webcomponents from Polymer 0.5).
But what would happen to the interoperability ? (is the great assumption of the concept of modularization of the technology of ‘components’) if I tried to use the components of ExtJS contained in an element with shadow DOM and is not supported ?
That is why I want to know more about the present or future of extwebcomponents in relation to support shadow DOM.
And regardless of the opinion, of whether in certain cases it is necessary or not … I prefer to be the one who decides when necessary.
Now my question is simpler, ExtWebcomponent supports or will support shadow DOM or not ?
Thanks
Initially we did create a shadow DOM and used that for the parent of the components, but that required the CSS to be available to the shadow DOM as well – meaning that the entire Ext JS theme needed to be added to the shadow DOM for each component. This resulted in the theme being downloaded in duplication for every EWC component you used on the page – not an ideal scenario. There is a recognition in the community that the Web Component spec doesn’t ideally support ‘shared component’ models -0 this is a pretty good article describing the issue…
https://www.smashingmagazine.com/2016/12/styling-web-components-using-a-shared-style-sheet/
let me know if there is a use-case for you that is not being met by us not using the shadow DOM – I would like to discuss this with you
Marc
Hi Marc, I know the article and all the technical arguments. In some things I do not agree, for example in solving the problem of the style, eliminating shadow dom. For me, shadow dom is a key feature, and differentiates a custom element from a true web components.
Conceptually, a component have a fixed interface, and requires a level of encapsulation that would be guaranteed by shadow dom.
Beyond that, if shadow dom is not supported, true interoperability can not be achieved (otherwise the argument of using the component with ‘any framework or library’ is weakened).
I commented in my previous message what is the case that I need: Use extjs components mixed with components from another source with shadow dom. Today I do not find it possible to add an extjs component inside a component with shadow dom due to its dependence on a global style.
Currently one way (among others) to solve the styling problem is using CSS variables. Of course that requires a complete rethinking and a good refactoring of the design guide, but it is the right way, because it avoids the polluting of rules and promotes the true spirit of focusing on a component as the main element of technology (versus and traversal to libraries or frameworks).
Please Marc, consider in the roadmap the support of shadow dom. In fact, Extjs licensing model could be more atomic and include more offers per package of components, or per component … (just as Apple revolutionized the music market by offering the purchase of 1 song… licensing for 1 or n components…).
Thanks
Claudio
Cladio, thanks for your thoughts on
EWC – yes, we will look at ways we can support our components living in the shadow DOM and also utilizing our themes…
We are working on the next version of Ext JS that will be utilizing the latest JavaScript innovations (import/export, classes, etc) and also providing for a much more modular architecture – also including theming/css variables would help the issue of isolation for our Web Components – thank you for the thoughts – I welcome any ideas they help us make EWC the best components for the Web Components spec
Marc,
Even though I left in the past extjs, I believe that you have a great product to be taken to webcomponents, and I think that if you solve the isolation via shadow dom and the visual themes, will be a strong competition and a commercial alternative.
In the community of web components (I am in the group of slack that founded polymer) is felt a great void of commercial and high quality alternatives for webcomponents in business web apps.
For those of us who come from a school of pure object technology (Smalltalk) We say that an object in a system has an organic relationship with it, not fixed its interface or collaboration contract strictly (vs componente definition). However in the user interface layer, the widgets and views are perfect objects to be components (objects with fixed interface: interchangeable, modular, interoperable), and that’s where I think the opportunity lies to exploit this new technology, ideal for user interface products. (*)
If you accept suggestions, please try to orient the mainstream of the product to the standard webcomponents, and vanilla js and html, without strong compromises with implementations that respond to a wave, which today are and tomorrow disappears (without detracting I speak of react, angular, etc).
I think that you are going to have a lot of refactoring work to alleviate (lightness) the widgets of features that exceed them (*) conceptually mutating from object concept (legacy extjs) to component concept. (may be you can offer thats features as a complement in the context of a complete use of extjs as a library or framework, of course it has its value).
I understand that on the way you are going to have to deal with a legacy code, on the one hand I hope that commercially, we clients have the patience to see the evolutionary changes, and the other I hope that you the enterprise, do not waste that patience, so a win-win situation.
Being an old client of extjs and suffering a bit of displeasure for some inadequate commercial policies from sencha (imho), nevertheless I still have hope that you can correct the way because it is always very useful and healthy to have a competitive market with high quality products, and I believe that the new wave of web components will give you a great opportunity to lead it from the commercial field.
Kind regards
Claudio
a very detailed and meticulous lesson, it really has a lot of values, I will learn a lot thanks
I tried ExtWebComponents. Very great application. with many good features and attractive. I really like this app.