I read many times that YUI will load modules dynamically based on need. or based on parent module. Like here it is written
The overlay module will pull in the widget, widget-stack,
widget-position, widget-position-align, widget-position-constrain and
widget-stdmod extensions it uses.
So, how can I determine the final size of data getting downloaded for a web page due to YUI usage.
Actually I was thinking how one can compare the datasize of YUI with that of another library (JQuery).
If you want file size vs functionality comparison, a close approximation based on features would be the simpleyui.js package (though the feature compilation is not 1:1), and be sure to look at gzip size as Tivac said.
Also keep in mind that JS lib file size comparison used as a reason to choose one over another is often a red herring. Your site likely includes a number of images, many of which will easy be larger than the lib and several additional modules. More relevant comparisons would be how the library is structured, what its relative strengths are, what's included out of the box (officially supported features vs 3rd party plugins), its community and documentation, etc. Pretty much any lib will serve your basic DHTML needs, and neither you or your users will notice the difference. Choose what works for you, and helps you build clean, maintainable code that you or your successor won't hate in a few months.
The Configurator will give you a file-size breakdown & automatically selects the needed modules.
Related
Can anyone recommend a library who really support RTL languages such as Hebrew or arabic, and also Supports links, support images, thumbnails/in-place images, Handle large spread-sheets, set filters and page breaks and good performance – very important criteria-
I started to use PDFKit who is really good, but the language support is awful and the data that we work with cannot be manipulated, because of that we need to change the library, the price is not a problem. Someone recommended Docmosis, someone has experience with it?
Thank you very much
Docmosis has customers that have been generating RTL documents for successfully for years. Docmosis supports the image handling requirements you mention and large data sets, but has no direct spreadsheet functionality.
I suggest doing a free trial (please note I work for Docmosis) and asking their support team about specific points of interest. The cloud is the easiest way to test functionality (since you have no install or setup to do) even if you wouldn't choose to use cloud for your actual deployment.
In React, some packages allow you to import Components using either individual assignment: import Card from "#material-ui/core/Card", or via object destructuring: import { Card } from "#material-ui/core".
I read in a Blog that using the object destructuring syntax can have performance ramifications if your environment doesn't have proper tree-shaking functionality. The result being that every component of #material-ui/core is imported, not just the one you wanted.
In what situations could using object destructuring imports cause a decline in application performance and how serious would the impact be? Also, in an environment that does have all the bells and whistles, like the default create-react-app configuration, will using one over the other make any difference at all?
Relying on package internal structure is often discouraged but it's officially valid in Material UI:
import Card from '#material-ui/core/Card';
In order to not depend on this and keep imports shorter, top-level exports can be used
import { Card } from "#material-ui/core"
Both are interchangeable, as long as the setup supports tree-shaking. In case unused top-level exports can be tree-shaken, the second option is preferable. Otherwise the the first option is preferable, it guarantees unused package imports to not be included into the bundle.
create-react-app uses Webpack configuration that supports tree-shaking and can benefit from the second option.
Loading in extra code, such as numerous components from material-ui you may not need, has two primary performance impacts: Download time, and execution time.
Download time is simple: Your JS file(s) are larger, therefore take longer to download, especially over slower connections such as mobile. Properly slimming down your JS using mechanisms like tree shaking is always a good idea.
Execution time is a little less apparent, but also has a similar effect, this time to browsers with less computing power available - again, primarily mobile. Even if the components are never used, the browser must still parse and execute the source and pull it into memory. On your desktop with a powerful processor and plenty of memory you'll probably never notice the difference, but on a slower/older computer or mobile device you may notice a small lag even after the file(s) finish downloading as they are processed.
Assuming your build tooling has properly working tree shaking, my opinion is generally they are roughly equivalent. The build tool will not include the unused components into the compiled JS, so it shouldn't impact either download or execution time.
From a performance/maintenance point of view, is it better to write my custom modules with netsuite all as one big JS, or multiple segmented script files.
If you compare it with a server side javascript language, say - Node.js the most popular, every module is written into separate file.
I generally take the approach of Object oriented javascript and put each class in a separate file which helps to organise the code.
One of the approach you can take is in development keep separate files and finally merge all files using js minifier tool like Google closure compiler when you deploy your code for production usage which can give you best of both worlds, if you are really bothered about every nano/mini seconds of performance.
If you see SuiteScript 2.0 architecture, it encourages module architecture which is easier to manage as load only those modules that you need, and it is easier to maintain multiple code files i.e. one per module considering future enhancements, bug fixes and code reuse.
Performance can never be judge by the line count of your module. We generally maintain modules for maintaining the readability and simplicity of the code. It is a good practice to put all generic functionalities in to an Utility script and use it as a library across all the modules. Again it depends on your code logic and programming style. So if you want to create multiple segments of your js file for more readability I dont think its a bad idea.
I maintain an academic website for myself that duplicates a lot of the material that I also put in my cv. To avoid having to maintain multiple files of the same information, and to keep things in sync, I use tex and bib files mostly, and I generate my cv in latex and use htlatex for the website.
As a project to improve my Haskell knowledge I have been thinking of generating my website with one of the haskell based static site generators. I have easily found several hakyll sites, but only a few yst, and it isn't clear to me what problem hakyll was designed to solve that wasn't being dealt with by yst. I am interested in learning what people see as the comparative advantages and disadvantages of each, and if there is any particular reason why I might want to start with one or the other given my current base of .tex and .bib files.
Disclaimer: I am the author of Hakyll.
What Hakyll gives you is an EDSL on top of pandoc, which allows you to more easily specify how different files should be processed. It is much like a specialized make on top of Pandoc. It also offers some other features which are useful for building static websites, i.e., manipulating URLS and HTML.
I think the main difference between yst and Hakyll is that Hakyll is on one side more customizable (since the configuration is just Haskell), but probably harder to get up and running as well.
I don't know about hakyll, but yst uses pandoc (http://johnmacfarlane.net/pandoc/) and shines in combining a static site combined with a bit of dynamic data in yaml (for example events): it support a sql like mini language to insert these dynamic data fields in a template.
Yst also helps to build a multi-page website, which is a bit more difficult when using pandoc alone.
However, I found it a bit hard to insert other elements in the template which are not supported by yst by default (for example, a table of contents for the page itself).
Additionally, pandoc (used in the background) has become much more powerful with the advent of
the yaml metadata block (http://johnmacfarlane.net/pandoc/README.html#yaml-metadata-block) which lets you insert virtually anything in the underlying template (for me, pandoc has
replaced LaTeX completely as a input format, for pandoc can convert files to both html as well as LaTeX (among others)).
I would suggest you'd consider to use pandoc instead of yst, unless you need that mini sql language feature.
I tried fay-jquery and the included sample test.hs file results in whooping 150 kb of js file.
Even with closure compiling it is still 20 kb.
I understand that it must carry a runtime, stdlib and jquery wrappers with it.
I can tell fay not to generate stdlib (--no-stdlib and --no-builtins flags).
But i do not know how to tell it not to include jquery code.
So my question is, how can i split those static parts into a separate js file and only generate module specific code?
This way large parts of code will be loaded only once (and cached) and i can create many smaller js files for separate web pages.
Yes it's safe to split modules up, as of Fay 0.16 all modules can exist standalone (before that you could still have the runtime and fay-base separate). There are some flags for this, --print-runtime and --no-stdlib. Compile with optimizations (-O, this increases the output size, but closure will be able to minimize it even better).
Also remember that the web server should gzip this. That brings the code size down to 4.5kiB. That's pretty decent, right?
You might want to consider putting all of your javascript in one file, that means a slower initial load but then users will have it cached for future page loads.
The reason the file size is so big is that fay-jquery has a lot of FFI bindings which produce a lot of transcoding information. I think fay-jquery could be optimized a lot here to for instance use Ptr JQuery rather than just JQuery in the types, or by figuring out that a lot of this is unnecessary while compiling, or abstracting the conversions more in the compiler's output.
Another possible issue I realized a couple of days ago is that the output is now in the global scope rather than in a closure, which might mean that google closure can't remove redundant code as well as previously (haven't had time to investigate this yet). The modules generation should perhaps be changed to produce a closure for each module.
Also see Reducing output size on the wiki.