
Marko – An isomorphic UI framework similar to Vue - jsnathan
http://markojs.com
======
alansammarone
I've focused on backend for the last 7 years or so, so I've been kind of out
of contact with the frontend world. Recently I started working on a personal
project, and I thought it would be a good time to learn some of the modern
tools people have been using for frontend dev.

I was completely baffled by the myriad of options out there, how complex they
look (note I've been working on very high performance, distributed backend
applications, so complexity on itself is not an issue), and how it's very
unclear when to use any one of them or what each one is good for. I tried
Angular and React, and both feel like almost a different language. You have to
learn their internals to work effectively with them, and it often looks like
they create more complexity then the original complexity they were trying to
reduce. I have no problem learning new things, in fact, I love it! It just
feels like there are other things to learn that will stick around for longer -
JS frameworks/libraries seem to be very hype-driven these days. What are your
thoughts on this?

~~~
oulu2006
Just learn vue.js, and use the associated vue libraries, vue-router, vuex,
etc.

Start with: [https://nuxtjs.org/](https://nuxtjs.org/)

And go from there, I wouldn't waste my time with Angular, and React is much
more complicated than Vue.

~~~
clarus
This is very subjective. I feel React is conceptually simpler (no custom
templating language) and less opinionated (no official state management system
like Vuex for example).

~~~
shangxiao
Your response is a bit disingenuous.

> no custom templating language

JSX may not be a templating language but you still need to consider it when
comparing with other framework's languages

> less opinionated

The community is though, if you don't do things with redux, react-router, etc
then you're considered odd. Any job you pick up with react is sure to use
those.

~~~
debaserab2
I've used neither of those libraries in any of the production React apps I've
made.

~~~
boubiyeah
Me neither, thank god.

------
bryanph_
Nowadays I only consider switching front-end frameworks if there is a
substantial conceptual improvement. React did this for me due to its uni-
directional dataflow and component-based architecture. There is nothing new
here conceptually.

~~~
Vinnl
I find that this is the most sane tactic as well. If you just limit yourself
to frameworks with conceptual improvements (that _also_ show at least signs of
substantial adoption, and preferably already are widely adopted), then the
churn really is not that high. It used to be jQuery, then Angular around 2012,
and now React. That's perfectly doable in terms of keeping up, at least as
long as you're an actual front-end developer rather than someone who also has
to do the front-end. (And perhaps it's less so when you're older and I'm one
of those darned millenials now, but I wouldn't know.)

------
tangue
I've discovered Marko in one of the various react-alternative topic that
emerged yesterday and it looks like something sane, which is rare in the js
ecosystem. I'm wondering if anyone on hn used in in a real world project and
how it was.

~~~
nherment
Yes we've started using it a couple of months ago. What attracted us is how
easy it is to build an isomorphic app with Marko.

I would not recommend it to anyone though. There is a world of difference
between what they advertise on their website and the reality of using it as
your framework.

Some key take-away for us so far:

Pros: \- the idea and principles behind marko are brilliant. \- it does render
relatively fast

Cons: \- it is bug ridden with inexplicable error messages. Not beta version
bug ridden, not alpha version bug ridden but pre-alpha version bug ridden...
\- top level elements can't have a state, which made templates impossible to
use (still need to make sure that's completely true, we haven't tried
everything we could). \- when doing back-end rendering, the browser still
waits for the JS bundle before rendering. Almost completely defeating the
purpose of an isomorphic app... \- Marko does not come with a state manager.
We had to build our own. \- We haven't started using their router yet but
having a quick look at it it seems to have an utterly bad API. They could have
gone all the way and embed the path definition into the marko files but no, we
get some awful JSON to work with...

My guess is that some very talented engineers at eBay rightly decided that the
current state of UI frameworks is terrible and started remedying it. Then,
deadline and other commitments made it hard for them to support the framework
enough for it to be usable by third parties. It is still a great achievement
and I find marko interesting but cannot possibly recommend it against React
(haven't used enough of Vue.js to have a valuable opinion on it).

~~~
modalist
Hi nherment,

I appreciate your feeedback. To follow up on some of your concerns:

Top-level UI components can have state now:

    
    
        class {
          onCreate () {
            this.state = {
              count: 0
            }
          }
          increment () {
            this.state.count++;
          }
        }
    
        <html>
          <body>
            <div onClick('increment')>Count: ${state.count}</div>
          </body>
        </html>
    

If Marko's built-in component state management is not sufficient, you can of
course use Redux with Marko. Here's a sample app: [https://github.com/marko-
js-samples/marko-redux](https://github.com/marko-js-samples/marko-redux).

Marko does not have an "officially" supported router yet, but this is the one
we've been pointing people to: [https://github.com/charlieduong94/marko-path-
router](https://github.com/charlieduong94/marko-path-router). If I understand
your statement correctly, you mean that you would prefer to export the path
directly from the component? I agree that this should be supported. Currently,
Marko does not support exports, but it's actually on our issues board
[https://github.com/marko-js/marko/issues/538](https://github.com/marko-
js/marko/issues/538). We'd like to support the following:

    
    
        export var route = '/about';
    
        class {
          ...
        }
    
        <div>About!</div>
    

This actually would be fairly easy to implement, but we've been focusing on
other things. I think that we should reprioritize this issue though.

It's definitely true that we have a lot of features that we'd love to focus on
and a very small team of engineers working on Marko/Lasso. I welcome you and
anyone else to jump in and help if you'd like! Any contributions are extremely
appreciated. Additionally, feel free to drop into the Marko Gitter chat with
any concerns and we'll try to help [https://gitter.im/marko-
js/marko](https://gitter.im/marko-js/marko).

~~~
nherment
I have just been using the state for a top level component.

While it is true that this is now working, updating the state in the component
that contains the <lasso-head/> and <lasso-body/> tags will cause the
dependencies (defined in browser.json) to be lost. Unfortunately, the
stylesheets are included in the dependencies... This means that playing with
state at the top level removes any styling on the page.

This is EXACTLY the type of insanity that makes me recommend _AGAINST_ using
marko...

Example code here: [https://github.com/nherment/marko-css-
error](https://github.com/nherment/marko-css-error)

------
jcelerier
Meanwhile in real reactive environments:

    
    
        import QtQuick 2.7
        import QtQuick.Controls 1.1
        
        Rectangle {
          property real count: 0
          
          Column {
            Text {
              text: count
              color: "#09c"
              font.pointSize: 24
            }
            Button {
              text: "Click me!"
              onClicked: count++
            }
          }
        }
    
    

Also the so-called "60fps smooth" animation has noticeable stutters on Firefox
on linux.

~~~
daenney
It works entirely fine on Firefox on macOS and Windows though. It seems more
likely that has something to do with how Firefox interacts with the graphics
stack on Linux than Marko.

Have you tried it in a different browser, like Chrome or Midori?

~~~
Vinnl
Works fine for me on Firefox on Linux. Not a weak laptop though.

~~~
jcelerier
Me neither. Intel 6900k and GTX 1080. Works fine in Chrome though.

------
jarym
So many new UI frameworks, yet no one really mentioned SmartClient.com (LGPL
licensed).

I've been using it for almost 10 years and some of the concepts they pioneered
have only recently been discovered by the new kids.

I still use it, though some of the 'fixes' they had to put in place to support
old browsers are often polluting the DOM unnecessarily in modern browsers
(this is something I hope they fixed).

My favourite aspects of it are that I can declare components declaratively, it
has a technique called autoChildren that allows managing a tree of components
as a flat set (useful for complex components like tabsets), and the data
binding layer. The documentation is top notch (which it needs to be given the
depth of stuff in there).

Again, all of this was around in 2009 since when I started using it - and not
sure how many years before I found it they'd been going.

------
znpy
I just skimmed the page and seen that sort coloured of sine wave... Then read
«The above animation is 128 <div> tags. No SVG, no CSS transitions/animations.
It's all powered by Marko which does a full re-render every frame.».

Well, as soon as my browser renders that thing, the browser process reaches
122% cpu usage (according to htop). And i'm using a 4th gen core i7 processor.
I can literally (literally in the literal sense of the word) hear my fan spin
up. That __hurts __battery so much.

~~~
ReadHearing
Ouch. I had a look and according to the Chrome task manager that page is
sitting at 12-18% cpu usage while looking at the animation.

For reference, a 5000Kb (720p) twitch stream I had open was sitting at 3-4%.

------
brianon99
Don’t abuse the term “isomorphics”. To prove 2 groups are isomorphic
mathematically you have to show there exists a product preserving map between
the groups.

Just kidding.

------
sAbakumoff
[https://dayssincelastjavascriptframework.com](https://dayssincelastjavascriptframework.com)

------
forkLding
Quick question, is there anything conceptually interesting about Marko thats
different in ideology and structure from Angular and React or Vue?

For background to why I'm asking: I'm an IOS mobile dev and was a web dev
before and I often use web dev structures and ideas as there is less
structure, frameworks (unless you count RxSwift) and general philosophies I
find in IOS mobile dev aside from best practices and tips like avoid Massive
View controllers, etc.

~~~
psteeleidem
Async and streaming rendering is probably the biggest conceptual difference
since it changes how you think about providing data to your view (in a good
way). The paradigms of how you build UI components is very similar across all
of the major UI libraries, but Marko aims to reduce boilerplate and offers
what I think to be a superior syntax. --Marko author

------
spacetexas
Ecosystem is so important these days, there might be technical reasons for
choosing this but considering the support (knowing stack overflow answers will
be available) and pre-existing component ecosystems for Vue & React, I can't
see a reason anyone would pick this.

~~~
murukesh_s
Same reason someone picked up vue in first place?

------
pier25
Here's a great introduction to Marko by its main dev:

[https://www.youtube.com/watch?v=i6eZA8Y_GgA](https://www.youtube.com/watch?v=i6eZA8Y_GgA)

~~~
vladimir-y
You can see on the 21-24 minutes the bad idea of implicit imports which is
being presented as a great idea:

\- Explicit import is a much better idea than the Marko's folder structure
based implicit import thing. Explicit import makes the code base more
maintainable, reduces the side effects probability and "magic" stuff.

\- "Counter" there is not a "word" as author says, but the component's file
name. So it's not the word that you can misspell, but the file/module, that
will not be imported in case of file name misspelling. Import by file name is
not repeating, it's the explicit module importing by the file name, not by a
some word - no DRY ideas violation here.

\- Author says on 21:51 that "imports is kind of terrible" due to the relative
path. There is no issue with the relative path - use Webpack's aliases. He
says imports (explicit relative imports in that case) makes code more
fragile...

\- I like Vue's idea of separation computed/methods/data blocks more than
mixing all together. It for example helps the green devs to better understand
the framework's lifecycle/internals and separation of concern ideas.

I stopped watching the video after the 24 minute.

~~~
pier25
> use Webpack's aliases

You are contradicting yourself there. There is really no difference in clarity
between an automatic path resolver and using aliases.

> I like Vue's idea of separation computed/methods/data blocks more than
> mixing all together

It's really a matter of taste.

~~~
vladimir-y
> You are contradicting yourself there. There is really no difference in
> clarity between an automatic path resolver and using aliases.

No difference? In case of explicit importing you get the "import" thing in the
sources code and it's a huge difference in comparison of not having it there.

> It's really a matter of taste.

Not really, but a matter of separation of concern and good design. Besides Vue
is a reactive thing, and such structure I guess makes it easy to apply
reactivity observers where they are needed in a more explicit way.

~~~
pier25
> No difference?

If you are using aliases you are not using explicit imports.

    
    
        import something from 'something';
    

Where does 'something' come from? No idea unless you peek at the webpack
configuration file.

You don't even know if the module is actually called 'something'.

> Not really, but a matter of separation of concern and good design.

Then I'm guessing you consider all OOP languages badly designed since none of
them have properties for 'methods', 'getters' (computed), etc. Yes?

~~~
vladimir-y
> If you are using aliases you are not using explicit imports.

You are as you have the "import" code line in the code sources. If you get rid
of that code line, you make it happen implicitly and this is the case of
undesirable "magic" happening.

> No idea unless you peek at the webpack configuration file.

Some IDEs do support automatic Webpack's aliases resolving, so you can
navigate to the module by ctrl+click.

> Then I'm guessing you consider all OOP languages badly designed since none
> of them have properties for 'methods', 'getters' (computed), etc. Yes?

Don't be silly, we are talking about JS that has a room for adding some
structure as it's being too flexible by default.

Anyway thanks for the Youtube link, it helped me to realize that I'm not going
to use this Marko thing.

------
seangates
For those interested in spreading this on PH:
[https://www.producthunt.com/posts/marko-
js](https://www.producthunt.com/posts/marko-js)

------
SeriousM
I don't believe the marketing when it says that working with something is
"fun". Working is maybe enjoyable sometimes, but it will stay hard work if
you're doing it right.

~~~
psteeleidem
Building web apps is definitely hard work, but it can be fun if you are
instantly rewarded with working components/pages that didn't require a ton of
code :)

------
jcranberry
Isomorphic UI? WTF??

What's next, homotopic web frameworks and commutative app diagrams???

------
dolphone
You had me at isomorphic.

------
stuaxo
This looks pretty decent.

------
akras14
Yay, another front end framework! /s

------
dmitriid
Oh hi there, yet another awkward not-really-html-not-really-js templating
language

    
    
        class {
            onCreate() {
                this.state = {
                    count:0
                };
            }
            increment() {
                this.state.count++;
            }
        }
         
        <div>The current count is ${state.count}</div>
        <button on-click('increment')>Click me!</button>

~~~
atom-morgan
Given how little boilerplate there is for the actual code, I'll take the
templating language.

