Strongly suspecting the answer is no, it would be a nice feature to be able to cache the compiled code from Babel standalone, so that the browser only compiles the code once (until the source changes). Possible?
Example:
<script type="text/babel">
// React component made with JSX. Can it be cached as it is *after* compilation with Babel?
</script>
Related
Suppose that you have a Scala.js project that compiles meaningfully to browser JavaScript, Node.js, and JVM.
Now imagine that in the browser, part of the application runs in the window while another part runs in a web worker.
Can SBT bundle two versions of the source code? One version has a main class for the browser window, while the other has a different main class that runs the web worker code?
If so, how would you configure this?
Please note that the project depends on JavaScript native libraries and webpack.
I'm doing exactly that in one of my projects, but with a main-class only for the JVM. The browser loads the transpiled scalajs-code and a small hook method, triggered by a js-file, initializing the core, with different parameters. This does work for Webworker and Frontend-thread and even for a SharedWorker
This could look like that:
importScripts("client-fullopt.js");
importScripts("conf/app-config.js");
MyProject.WebWorkerActorParent.initBackend(myProjectConfig);
MyProject.WebWorkerActorParent.addWorker(this);
at the frontend it could be a global script import and another initialization routine.
<script src='client-fullopt.js' />
<script>
MyProject.WebWorkerActorParent.initFrontend();
</script>
Of course, nothing prevents you to additionally create different subprojects in sbt, that all use the same, common library-project and bundle their specific needs for the target platform in a separate project.
I am working on the SAPUI5 application with normal ES5 code and using grunt-openui5 to create the Component-preload.js file to deploy to CRM system. Now I am planning to use ES6 style coding but we need to support an old browser. Therefore, I need to transpile it down to ES5 and then create the Component-preload.js file. Now my concern with this approach is when I debug the production issue, everyone gets it right, I want to debug my ES6 file, not ES5 file.
Any help or guidance is very appreciated.
One way to have a transpiled, debuggable preload file and separate ES6 based source files is probably to use the sap-ui-debug=true URL parameter option. Instead of the normal files, it will try to load -dbg.js versions of everything. This for instance is what the SAP WebIDE generates:
If you can set up your build set so that the original, untranspiled files are copied as -dbg versions, and your preload picks up the transpiled ones you might be able to make it work.
Here's the section of the SDK documentation that'll give you some more background information: https://openui5.hana.ondemand.com/#/topic/c9b0f8cca852443f9b8d3bf8ba5626ab
I am using Play Framework 2.5 and ReactJS and I would like to be able to use importin my .jsx files but it seems like I am not allowed to do it because it throws an error in the javascript console saying that import is not recognized.
I added the sbt-reactjs to my build.sbt and I see that ReactJS compiles files each time they are changed, however I still have this importerror.
It can be really problematic as my application will grow because the components will become bigger and for example I would like to divide my navbar and to have Nav.jsand NavItem.js and I want to be able to call any component I have created in any *.js file of my application.
I have heard about babel that could transpile my code in pure javascript code but I would like to have more information about it, more precisely, can it works with Play (ie. will the files be transpiled during the assets command ?).
So my question is: Can I use the import with only the libs I have installed or do I have to add something else to my build.sbt ?
Thank you for your time
Well, from searching on the net, there seems there are lot of ways of doing it. I also ran into same problem. The best example I found was to use webpack for building the jsx files. The following git repo has all u need.
https://github.com/nouhoum/play-react-webpack
I'm developing in CoffeeScript and want to start to use Underscore.js. I know that any JS library will work in CoffeeScript.
Online there is the regular UnderscoreJS and also a CoffeScript version. Are there any difference in implication of the two? Is it perfectly ok to use the underscore JS version for my CoffeeScript needs?
You'll want to use the JavaScript version. The CoffeeScript version was likely just the author playing around with CoffeeScript, which makes sense since he is the author for both CoffeeScript and Underscore. Also, the CoffeeScript version introduces a compile step (assuming you are using this in the browser rather than on the server with node.js).
As another option, check out Lodash. It is a drop-in replacement for Underscore and for many reasons is the better option. It just released v1.0 in the past few days.
Usually when you are developing in Coffeescript, you are going to need something to compile your various Coffeescript files together to Javascript so that a browser can run it. How you want to use the library determines which version you will use.
Option 1: Manually add the Underscore library (in JS form) as a <script> tag in your page and also add your compiled coffeescript as a <script> tag. Quick and easy dirty way to get things to work, but results in a buildup of <script> and <meta> tags as you add more libraries/styles to your page, and spaghetti code.
Option 2: Use a tool to compile all your Coffeescript and CSS into a single JS/CSS file, which you then reference in your HTML. Then you would use the Coffeescript form of Underscore and compile that with the rest of your code. This is the approach I use, with the additional advantage of being able to use tools like npm to manage dependencies. Additionally, it allows you to have a test web server that compiles your code in real time as you edit the Coffeescript. Check out my post on using hem, npm, (and Spine).
For option 2, something else you can check out is requireJS.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...