Define "big blob of js" React, the framework alone, is around 54kb gzipped, my elm SPA is currently half that gzipped. Also, you would load the same blob once, as it's cached in your browser. Currently, if you split your app up into multiple entry points, those would still require the Elm runtime, core library, virtual dom and html library.
torsdag 24. november 2016 13.40.12 UTC+1 skrev Rafał Cieślak følgende: > > Robin: > > I would just keep everything in one Elm app, then use a router to display >> the correct page. > > > The problem I see with this is that our app is not SPA, so each page that > needs an Elm app would need to load a big blob of JS with dependencies of > all the Elm modules in our source code. > > When it comes to google closure, Elm only works with SimpleOptimizations. > > > Thanks for the info, I was under the impression that it worked okay with > advanced optimizations. > > In any case, the difference between Google Closure and Uglify is very >> small when it comes to Elm. > > > Yeah, that's why I eventually gave up – the few KBs of reduced size were > not worth the time I spent figuring out how to make this all work with > Closure Compiler. ;) > > > > Noah: > > So you use a similar setup to what I described, right? I assume that by "a > unique Elm app" you mean "a main module" and that all the main modules > share a single elm-package.json. > > This is ideal in terms of build time and reliabitly, as everything can be >> built and once and share a single lot of packages. > > > Yeah, definitely. Another advantage for me is what I mentioned earlier: it > can be easily plugged in to our existing workflow with webpack. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
