Hi guys! Very naive questions. I have the following code:
(ns foo)
(def h "Hello")
(js/console.log h)
That output to:
var shadow$provide = {};
(function(){
'use strict';/*
Copyright The Closure Library Authors.
SPDX-License-Identifier: Apache-2.0
*/
console.log("Hello");
}).call(this);
What is the purpose of shadow$provide = {}? Also is there a way to remove the extra comment?shadow$provide is for briding npm deps. guess that could be removed if none are present. feel free to open an issue if you care enough and will never use any npm dependencies in your actual builds
that extra comment is from the closure library/compiler. dunno if there is a flag to remove it, never checked.
why do you care though? I mean this is not a realistic use of cljs, just seeing how much it disappears will fail fairly quickly once you actually use the language/datastructures
Thanks for the answer. I add some context of a potential use case.
Actually, at work I have 95% of the backend written in clj and one project in cljs. There is a node JS project whish is used to serve tracking JS file.
Tracking files are stored in a folder (like a resources folder). These files are in JS but written in a way that are difficult to read and maintain. We use uglifyjs next to compact all the files.
My idea is to rewrite the node JS project to a simple clj server and all the JS template to cljs (better readability).
keep in mind that if they make any reasonable use of cljs they'll be at least ~30kb gzipped (cause of cljs.core and the datastructures). since you asked about a few bytes of "dead code" that might be of concern for you
Yeah the goal is to use the minimum of cljs.core (or nothing and play only with the js/ interop)
then I'd recommend sticking with JS. that code is going to be about as ugly as JS only cljs
Yeah the only advantage I see (using cljs for js template) is the same syntax than the rest of the codebase.
and the macros
well I'd always use cljs no matter what. but trying to not use cljs.core and avoiding most features sounds painful 😉
@jean.boudet11 squint is designed for a problem like this. it is designed to write JS with CLJS syntax while compiling into small output that interops well with other JS files
All while being able to use a stdlib very similar to CLJS
@borkdude yes I check squint but should I use it in production?
well I am and cljdoc is, also https://github.com/nextjournal/clojure-mode/ is using it
Ok I will take a closer look