Results 1 to 2 of 2

Thread: A look back on a migration project from classic 4.2.5 to modern 6.7.0

  1. #1
    Ext JS Premium Member tangix's Avatar
    Join Date
    Mar 2010
    Stockholm, Sweden

    Default A look back on a migration project from classic 4.2.5 to modern 6.7.0

    Arrived at Milestone 1 (MS1) of one project of porting an Ext JS 4.2.5 project created in Sencha Architect to Ext JS 6.7.0 modern (open tooling and developed in PHPStorm) and just wanted to share my thoughts with the community.
    This project is a quote-generation system for energy calculation. The system is well localized, supporting 12 languages. It features a fairly complex UI due to the number of input variables (125+ fields) and configuration options that are linked (i.e. select A and you have access to options B and C but not D). The results are shown as tables and graphs. Data communication is AJAX and the plan is to keep the backend as-is for the new UI.

    MS1 was to have the input parts of the application running in modern, with all the same input options and selection logic. MS2 will be to have the results shown and MS3 is to get the full tool-chain working.


    The goal for the migrated project is to have an application using responsive design to accommodate tablets (phones not feasible), to have an application that can be themed for the different customers and use Sencha Test or similar to test the full application.

    I have found the modern toolkit very stable and solid. In Ext JS 4.2.5 we had to work-around several of layout issues when displaying and hiding options. So far (knock on wood) I have experienced zero issues related to layout or display of containers and fields.

    Open tooling on the other hand is a mixed blessing. I develop on a Mac running macOS 10.13.6 and homebrew to manage packages such as npm. The Sencha IDE plugin to PHPStorm is used. The project was initially created with extgen from the original 6.7.0 release.
    I have spent days recovering from broken open tooling environments, troubleshooting dependencies in package.json and changes in webpack.config.js. Having npm maintained by homebrew means that npm will be updated! Several times the node_modules folder has been nuked after completely breaking down. Running npm install then gives you updated versions of dependencies and this creates issues. Most problematic has been updates to webpack since these required changes to webpack.config.js. Webpack is way outside my comfort zone and it took hours digging through the documentation to understand the required changes to the extgen generated webpack configuration.
    Handling Ext JS updates has also been a challenge. I started with Ext JS when it was released. Getting the update to to install was a complete mess and required me to create a brand-new project using extgen and copy over the application source. Turned out to be changes to webpack.config.js that extgen created but this was a day’s work lost. Open tooling works otherwise fine and I like the way “npm starts” works and how quickly it generates new version.

    The main problem currently with modern is the lack of components that you are used to from the classic framework – for example RadioGroup! Hacking around these limitations is tedious and time-consuming. The worst thing is that you lose confidence in the modern framework and worry about the next missing thing you will trip on. Yes - it could be argued that it was bad research before selecting modern over classic, but with so many releases one would think that the feature-set would be on-par between the frameworks.

    Another huge problem is the lack of documentation for modern with many links broken on the docs site. Much of the documentation is pointing to outdated information (especially theming) and the information around open tooling is scarce and fragmentary. Digging through external npm and webpack documentations is painful and an efficient way to waste valuable time.

    We are now struggling with the close to non-existent support for localization (dates, number format, error message etc.). The classic framework contains support for 47 languages and modern 8 languages!!!! None of the languages we use are included. I am lost for words to express my disappointment to why Sencha hasn’t ported the rest of the 39 locales from classic to modern, especially since the hard parts (research and translations) have been done for classic!

    The modern theme is appreciated and easy to work with. So far only found a couple of minor issues with the theme have been found. The Fashion CSS integration looks promising but here the lack of documentation will be a problem.

    Looking forward for comments from the community as we are pushing forward to MS2.


  2. #2
    Sencha User
    Join Date
    Sep 2007
    Phoenix AZ


    Thanks for posting your experience with the port.
    It would be nice to hear from Sencha.... but we get the standard crickets. It appears they are not even spending any time on the forum.
    As a small business owner I find this crazy. They have a resource that gives them insight into how they are running their organization and where they can make improvements and it goes ignored.

    I have not made the move to open tooling. I am waiting for more detailed documentation. I don't have much experience with nodejs or npm and I don't have the time to figure it out with trial and error.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts