trial and stderr

Look, it's been fun, but my org has given me the opportunity to bail on MarkoJS (by insituting a massive pivot, obviating most of the code I wrote). I'm going to double down on NextJS.

MarkoJS is a very good idea, put together by very kind and helpful people. It's simply just not well executed enough, and the people can't be sufficiently kind and helpful to compensate for how not ready for general use it is.

I will miss Marko's unbelievable speed. It's the "great physical connection" part of the relationship that almost makes me forget about all the problems that developed between us.

You should use MarkoJS if you want to develop MarkoJS into something useable.

The biggest problems are

1. the error messages are terrible
2. errors have to be looked up in the compiled JS code, from which you have to infer what went wrong in the Marko code
3. the documentation was obviously mostly written for old versions of Marko, and needs to be fully restructured to make sense for what Marko is now
4. there's a lot of weird behavior that's just not documented at all outside PRs
5. complex component relationships are completely undocumented, even in examples -- you'll note that every MarkoJS snippet everywhere has trivially simple data models
6. any given Google search about MarkoJS will turn up a wealth of information about a deprecated MarkoJS-related project (Marko Widgets, Marko Router...) and almost nothing about MarkoJS as it presently exists
7. no one uses it except a handful of highly enthusiastic eBay engineers, so you better hope one of them is online to answer your questions, and will continue to be, forever
8. most of the documentation for MarkoJS refers to Lasso and wants you to use Lasso, but no one has actually used it for anything other than MarkoJS, so finding information about it is pretty much impossible

I hope MarkoJS takes off, because I think it's largely composed of good ideas. And is mind-blowingly fast.

In my project's shared npm package are included both my database models and some code that I'd like a client, bundled with Lasso, to be able to access. So I figured I could make the model only conditionally required, right?

const browser =
  typeof window !== 'undefined' ||
  process.browser ||
  process.env.IN_BROWSER === '1'

module.exports = {
  config: require('./config'),
  models: browser ? null : require('./models'),
}

Running marko-starter build, I see that browser == true, but the Lasso bundling still fails on code in models, indicating that the module is getting required regardless. Bummer.

The right way to solve this, of course, would be to use the browser field spec which Lasso ostensibly respects, but that doesn't seem to be working, and my requests for help have fallen on deaf ears. The Marko community is mostly very helpful people, but unfortunately it's a community of like four people that work for eBay.

So I suppose I'll now maintain two common packages, one browser-compatible, one not.

I was looking for a nice way to do a "dynamic import" in Marko.js, like the following Next.js code:

import dynamic from 'next/dynamic'
const L = dynamic(import('leaflet'), { ssr: false})

This seems pretty good:

var L
class {
  onMount() {
    L = require('leaflet')
    ...

Here's the example you're looking for. Hopefully this'll make it a little easier to find for the next person.