I'm slowly starting to think that we might want to build our own minifier for global names (class names, property names, function names). If we do that, then hopefully any local-only JS minifier could be applied to individual .js files to finish the job. It might not be as good as GCC applied to an entire .js file, but it might be able to go a long way in the right direction.
Yeah honestly, if we just shrink some of the property names, I think the bundle would be quite a bit smaller. Right now terser takes 13MB -> 5.6mb for us, incorrectly mangling properties (FWIW) goes from 5.66 -> 2.8MB then gzip is like 500kb
I have a question concerning jsDependencies.
I have a facade for plotly.js, but webpacking this library is terrible, so that I have given up using scalajs-bundler to deal with the js sources. So I now use jsDependencies plugin in my facade build. The result is a wrap of the plotly.min.js in my facade jar output as expected.
My question is: how to get this js resource (conained in the jar facade) from a project depending on this facade (so that I could copy it to the right place to render it accessible in my html) ?
I guess it is a trivial use case, but I didn't find the right methods to achieve that.
Are there any html libraries available for Scala 3 (or any of the RCs)? I know there's ScalaTags, but like many of the author's libraries, it's vaguely maintained :) Ideally the library itself won't depend on a framework or have other strings attached.
XML literals, sans XML feature support (read: weight/bugs/performance) would be ideal, but that's not happening, so a DSL of some sort is needed to write markup in Scala.
import scala.collection.mutable.ArrayBuffer
class Table:
val rows = new ArrayBuffer[Row]
def add(r: Row): Unit = rows += r
override def toString = rows.mkString("<table>", "", "</table>")
class Row:
val cells = new ArrayBuffer[Cell]
def add(c: Cell): Unit = cells += c
override def toString = cells.mkString("<tr>", "", "</tr>")
case class Cell(elem: String):
override def toString = s"<td>$elem</td>"
def table(init: Table ?=> Unit) =
given t: Table = Table()
init
t
def row(init: Row ?=> Unit)(using t: Table) =
given r: Row = Row()
init
t.add(r)
def cell(str: String)(using r: Row) =
r.add(new Cell(str))
table {
row {
cell("top left")
cell("top right")
}
row {
cell("bottom left")
cell("bottom right")
}
}
If you want something production ready, and you think Scalatags isn't well enough maintained, you should definitely fork it before you try coming up with your own thing. That will get you to a well-maintained, usable, production-ready implementation much faster.
Unless your goal is to invent a HTML library or play with new language features, in which case go right ahead :) Just know that it'll inevitably be even more poorly maintained than Scalatags already is!
@godenji I am working on a Scala 3 DSL using the new Context Functions. I'm really enjoying it so far.
@main def launchApp: Unit = shaka.render(ShoppingList("Odersky"))
class ShoppingList(name: String) extends Component:
override def template: ComponentBuilder =
import shaka.builders.{name as _, *}
div{className("shopping-list")
h1{t"Shopping list for $name"}
ul{
li{t"Scala 3 Books"}
li{t"Scala.js Tutorials"}
li{t"Cooking guides!"}
}
}I've made a bunch of demos here: https://github.com/getshaka-org/shaka-docsite/blob/master/src/main/scala/org/getshaka/shaka/docsite/Demos.scala
It's not done yet (not published for Scala 3 and site is down), but check it out if you're interested: https://github.com/getshaka-org/shaka
Just know that it'll inevitably be even more poorly maintained than Scalatags already is!
ha, touché :)
You're rather prolific, and with that comes too much on one's plate I suspect. Just exploring some ideas around scala 3 + scala-js, so any markup solution will do the trick in the early stages.
@AugustNagro cool, interesting approach, my first instinct with scala markup builder would be to have the tag take a Seq of arguments and have 2nd param block receive the child tag block (e.g. something like: div(cls ~ "...", click ~ "..."){ h1{...} })
I'll take a look at your library, thanks.
@godenji In my first iteration I had a varargs param group for properties/styles exactly like you say. But performance is >100 times better without varargs, which create many allocations and cannot be inline'd
You can see the change in getshaka-org/shaka@2c84679.
With inlining, the fullLinkJS output for
div{color("purple"); t"Hello $user"}Becomes
var b = document.createElement("div");
b.style.color = "purple";
b.appendChild(document.createTextNode("Hello "));
var c = this.Wo;
null !== c && void 0 === c ||
b.appendChild(document.createTextNode(c));
b.appendChild(document.createTextNode(""));
a.appendChild(b);Which is quite good. So given the perf benefit it's a no brainer. I still use the DSL like HTML, with properties on the same line as the tag, and children in the indented region:
div{`class`("myCls"); id("abc"); otherProp(23)
p{t"this is the body"}
}
I personally learned it on the JVM because I was coming from Java, if you're coming from a frontend/nodejs background I think starting with Scala.js is totally cool!
test. When I enable the scala-js plugin in the sbt file it also adds it's own tests to the test command. I would like to keep everything I have done (compile the scala lib to javascript) but keep the test command as it was (testing only scala code).
crossProject to build, in fact, 2 projects: one for the JVM and one for JS.
@renghen
I am doing some experiments around javascript and cps
Does https://github.com/scala/scala-async address your use case?
scalajs-stubs in the jvm dependencies :/