[ClojureScript] New Features coming to ClojureScript

[David Nolen]

We have a series of blog posts in the queue that outline several major
enhancements to the ClojureScript compiler that will be available in the
next release. This is the first one in the series:

https://clojurescript.org/news/2017-07-10-code-splitting

Enjoy!
David

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] [ANN] Orchestra 2017.07.04-1 (now supporting ClojureScript)

[Rick Moynihan]

It might be worth including a discussion about when to use this library,
and perhaps indicating that using it might not be a best-practice.

:ret and :fn specs were originally validated by instrument, but this
feature was removed because Rich et al thought it redundant, and that there
were different (and arguably better) tools for validating :ret specs, e.g.
check.

https://groups.google.com/d/msg/clojure/JU6EmjtbRiQ/WSrueFvsBQAJ

For what it's worth I understand why you might want to use this, and it's
nice to have the option if you have a legacy test suite that you want to
incorporate some specs/validation with, but if you're using it you're doing
example based testing and not the generative testing which spec seems
intended to encourage.

R.

On 8 July 2017 at 19:06, Jeaye  wrote:

> Folks,
>
> I'm happy to announce that a new version of Orchestra has been released
> this past week.
>
> # Where to find it?
> https://github.com/jeaye/orchestra
> [orchestra "2017.07.04-1"]
>
> # What is it?
> Orchestra is a Clojure(Script) library made as a drop-in replacement for
> clojure.spec.test.alpha, which provides custom instrumentation that
> validates all aspects of function specs. By default, clojure.spec will only
> instrument :args. This leaves out :ret and :fn from automatic validation;
> Orchestra checks all of them for you.
>
> # What changed since 0.3.0?
> ClojureScript support!
>
> # Any more info?
> You can read my call to arms for instrumentation here:
> https://blog.jeaye.com/2017/05/31/clojure-spec/ Also, some notes on
> porting Orchestra to ClojureScript, which extend to porting Clojure
> projects to ClojureScript in general, here: https://blog.jeaye.com/2017/
> 06/30/orchestra-cljs/
>
> # When should I use it?
> I strongly believe we can benefit from this instrumentation throughout the
> entire development cycle, so I recommend both your tests and your
> developments builds use instrumentation by default. If any functions
> misbehave, you'll know immediately and you'll have the context to find out
> why.
>
> Cheers,
> Jeaye
>
> --
> Note that posts from new members are moderated - please be patient with
> your first post.
> ---
> You received this message because you are subscribed to the Google Groups
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojurescript+unsubscr...@googlegroups.com.
> To post to this group, send email to clojurescript@googlegroups.com.
> Visit this group at https://groups.google.com/group/clojurescript.
>

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.

Re: [ClojureScript] Re: A new take on ClojureScript and npm

[Thomas Heller]

> Yes.  Currently optimization is something we are doing when compiling 
> clojurescript, but perhaps *ideally* optimization could be done after 
> bundling when all the javascript is available.   However, I realize this 
> may not actually work very well in practice since most modern js 
> applications include dozens or hundreds of npm libraries that are not 
> closure ready and would break in unexpected ways.  Perhaps this is why 
> UglyifyJS is more common for webpack users?  UglyifyJS does dead code 
> elimination as well I believe, is it as good? probably not? is it good 
> enough? not sure.
>


UglifyJS is not good enough in my opinion, not even close. The JS world has 
"accepted" that you need to make lots of many small files to make it 
acceptable. We don't since we have Closure.

 

> Do we still need analyzer data after its compiled? Can't we just use the 
> javascript as a lib? I assume that google closure isn't written in cljs but 
> cljs has no problem using or optimizing it... perhaps the packages are 
> distributed as unoptimized google closure compatible js and the webpack 
> plugin turns google closure modules into commonjs modules? not sure. just 
> ideas. 
>


You need to analyzer data if you want to compile any .cljs. It is not 
needed at runtime (which is where the closure library comes in).

 

> Best optimized perhaps, but possibly not the best js dev ux.  Many js 
> developers don't want to run java as part of their build process and might 
> prefer to use uglifyjs even if the results are not as good.  
>

But many js devs do optimize and the best results would probably be to put 
> the unoptimized closure together with the unoptimized javascript and then 
> optimize everything together. But my guess is that wont work in practice. 
>  UglifyJS I think is safer than closure, as good? probably not, good 
> enough? not sure.  Your solution probably produces best optimization, but 
> its worth asking if thats what devs care about the most?  Slower build 
> process with more complexity vs a faster website.  There will be devs on 
> both sides I think. 
>


This is one place where it is far more important to optimize for production 
users not the developer UX. I care very little about the fact that my 
production build may take a while longer if the resulting .js my users have 
to download is substantially smaller with much better runtime performance. 
The fear of Java is unreasonable and mostly FUD. If I run builds with 
create-react-app or create-react-native-app they are frequently much slower 
than a :advanced compiled CLJS build.

There are still lots of places where we can optimize the dev UX but 
production concerns will always come first.

JS integration is still a work in progress and will get a whole lot better 
soon. Stay tuned. ;)

/thomas
 

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojurescript+unsubscr...@googlegroups.com.
To post to this group, send email to clojurescript@googlegroups.com.
Visit this group at https://groups.google.com/group/clojurescript.