https://netsuiteprofessionals.com logo
Join Slack
Powered by
Our company has been discussing the recently updat...
# suitescript
s
Our company has been discussing the recently updated status of Moment.js: https://momentjs.com/docs/#/-project-status/ We are considering whether to keep using it, or move to alternatives such as js-joda. Does anyone have any experience with that, or can recommend alternatives (or ones we should avoid)? Two of the reccomended alternatives, Luxon and Day.js depend upon 
Intl
, so we have ruled them out
e
First I'm reading about either of these things; is 
Intl
not supported in 2.1?
s
Last time I tried to use a package that depended on it, it told me Intl was not defined. That was about 2 or 3 months ago (in 2020.1). That was in a server-side script. It would probably work in a client script with most modern browsers.
I haven’t tried it again in 2020.2
m
It works for me in 2.1 not sure the issue
e
I get 
Intl is not defined
on 2020.2 in a 2.1 UE
using 
new Intl.DateTimeFormat("en-US").format(new Date());
s
Is there a NetSuite setting to enable it, perhaps? GraalVM has a flag 
--js.intl-402=true
to enable the Internationalization API: https://www.graalvm.org/reference-manual/js/JavaScriptCompatibility/#ecmascript-language-compliance
🙌 1
I am assuming that is the engine NetSuite uses for 2.1, but not sure if it is specifically documented anywhere
e
I'd guess that's not a layer we can interact with
s
Well, I tried again in 2020.2, and still get Intl is not defined in a 2.1 scheduled script. Given the lack of Intl, js-joda looks like the only actively maintained alternative to Moment.js that might work. It’s also AMD compatible, which should make it easier to work with in SuiteScript.
e
curious question, why do you think you need to get completely away from moment.js? I mean the library currently solves the problems we face into NetSuite related to the poor dates API. Interesting discussing thread btw.
s
We aren’t trying to get completely away from it. We aren’t looking to change existing code. However their own page states:
We recognize that many existing projects may continue to use Moment, but we would like to discourage Moment from being used in new projects going forward.
The main reason is our company’s preference to use actively maintained projects over dead ones wherever possible, for security and stability reasons. Having said that, if we have looked at the alternatives and nothing fits our needs like Moment, then we may stay with it. We are thinking of what’s best for future development.
w
There is a node package and a polyfill for Intl
s
I've used date-fns.org
s
I have not been able to get the Intl polyfill to work. We don’t transpile our code, and the node packages aren’t compatible with NetSuite’s RequireJS directly. I haven’t spent any time trying to overcome that, since I have no other need for it. I just tested js-joda with SuiteScript 1.0, 2.0, and 2.1, and it works for all versions. The file is a bit larger than moment, but it runs in less than a second.
date-fns seems like it would be a pain to use without webpack to put everything into a single file. It has over 100 separate libraries, each for a narrow purpose. I like date-fns qutie a lot, actually, but so far have only used it in node projects for our other applications (not NetSuite)
s
I haven't used it [date-fns] in production, but would probably just deploy it all to a well known location and import just what I needed in each script?
momentjs on the other hand is pretty big as a single lib, though I still use momentjs as our 'standard'. Also I've had NS engineers tell me the time to load scripts is trivial compared to the other Java machinery involved and not to worry about bundling or minimizing JS at all.
s
That’s good to know. Yeah, the js-joda file is 445 KB, but I can’t discern any difference in time between it and moment. Both run in a few hundred milliseconds. I suspect NetSuite overhead will always be the biggest performance killer.
As for minifying (or even GZip’ing) JS files, the main purpose is to reduce download times in client side scripts to the browser, and even then it would mostly impact users with slower connections. For a server side script, I imagine it can handle large files without any problems ( as long as nobody is using 350 MB JavaScript files like this person: https://github.com/graalvm/graaljs/issues/58 )
😬 1
s
hah, aye 350MB is extreme and there certainly can be a case for minifying client scripts specifically - though I'd want to measure that before taking action. NetSuite downloads a ton of stuff already - it's possible scripts we're creating and associated libs are generally small by comparison? Most libs come with a minified version so one could just use that in the file cabinet.
3 Views
Open in Slack
PreviousNext
Powered by