13 ms·

Marko – An isomorphic UI framework similar to Vue

276 points by jsnathan 9y ago

alansammarone 9y ago
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 9y ago
  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 9y ago
    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).
    - mrout 9y ago
      Vuex is no more tied to Vue than Redux is to React.
    - shangxiao 9y ago
      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.
      - mamp 9y ago
        > The community is though, if you don't do things with redux, react-router, etc then you're considered odd A bit disingenuous there. In general people find Redux quite complicated and it everyone acknowledges it requires quite a bit of boilerplate when used in the default way. Quite a few like MobX, or using their own state management. I've found the community to be very open to alternatives and helpful.
      - debaserab2 9y ago
        I've used neither of those libraries in any of the production React apps I've made.
        boubiyeah 9y ago
        Me neither, thank god.
    - oulu2006 9y ago
      You've mentioned one of the exact reasons why I found Vue.js so much simpler. It's highly opinionated, which for 95% of the time, in my experience, is exactly what I want. I found myself much much more open to JS library fatigue with React; the ecosystem is so vast that it's hard to figure out which particular store I need, or which routing library I want or what form library I need and so on. I've seen a number of people complain about this, especially new comers. I find the opinionated nature of Vue.js so refreshing, especially for newcomers, which the OP is, hence why Vue.js is a much better option to begin with. And continue with, but that's a decision I guess the OP can make further down the road.
      - debaserab2 9y ago
        You don't need a route library. You don't need a form library. What do you need a routing library for? Have a single controller component (usually the most outer shell app component) and sprinkle in further functionality (e.g. history pushState) as necessary. Don't build it out until you actually need it. I've never needed a "form library" because forms are almost always interactive in some specific way. Using a form library is almost always guaranteed to just get in the way. You don't need to have a global state management library either if you have a good grasp of your apps data structures and how they need to be passed into components. I find with React I get the opposite of javascript fatigue: it's so easy to build anything you need once you understand react that you won't need to search for all those libraries and code snippets.
        oulu2006 9y ago
        I guess we have completely different approaches to software development. I really hate reinventing the wheel, especially when good quality production tested solutions are out there. React libraries, quality wise, I've found hit or miss. I find Vuex a very nice global store and the tooling (chrome plugin etc..) is top-notch.
        debaserab2 9y ago
        You won't be reinventing the wheel for things like global state management and javascript routers. I promise. These libraries are huge solutions to problems that may or may not be huge - and in most of the cases I've seen, YAGNI. The concept of maintaining application state is nothing specific to SPA's. What is new is the idea that every application must have a global data store where all state is saved. This is a trend and not always necessarily a best practice. This isn't a matter of reinventing the wheel, it's a matter of using an oversized solution for an undersized problem.
  - raphinou 9y ago
    Did I miss something or there's no explanation of what nuxtjs is on their website?
    - ycmbntrthrwaway 9y ago
      https://nuxtjs.org/guide https://nuxtjs.org/guide
  - christilut 9y ago
    Don't start with nuxt. Start with the Vuejs tutorial on their website. Vuejs docs are amazing and one the big reasons why people enjoy starting Vue. Nuxt docs are so-so and can be quite confusing.
    - noir_lord 9y ago
      Agree with this. I tend not to use "quick starts" especially when using something new since you a) don't learn the internal gubbins b) are more fucked when something breaks. When I started with WebPack and TypeScript I deliberately started from an empty webpack.config.js and an empty tsconfig.js and added in stuff as I went at the end I had a decent understanding of what everything in both files actually did and they only did what I wanted. I've never found a quick start that helped me (in terms of total time) since the time spent fixing it when it breaks always exceeds the time taken from just doing it manually the first time, after I understand what I'm doing then I'll consider the quick starts.
      - musashizak 9y ago
        Poi is a good webpack wrapper for vue. Is a webpack with zero config
    - oulu2006 9y ago
      I guess I should have been more specific here, my bad. Reading the Vue.js docs online is of course the first port of call; the documentation is very good, so much better than Reacts. One of the few occasions I've been able to learn a good majority of the project without resorting to googling for tutorials and other community contributed resources. I recommended Nuxt as a good "this is how you put a enterprise ready Vue.js project together" so the OP would learn some good habits in project layout early on.
      - computerex 9y ago
        I tried to like VueJs but just couldn't. Seems just like another Angular 1.x like framework. I am done with HTML template API's. So many failed attempts using this concept. Anyone remember Polymer? That's what I thought.
  - scottmf 9y ago
    Nuxt is the Vue version of Next, which I highly recommend for quickly bootstrapping a production-ready React app with server-side rendering and so on.
  - wolco 9y ago
    For me I picked up React pretty quickly but I was using old school includes in the browser with the babel compiler. I tried moving to a newer version and start using with npm and webpack and I got a little lost. Started using the php framework laravel it has a mix package build in that makes everything very simple. My advice for backend developers is to use either the laravel framework or standalone npm laravel's mix package. With a simple command preseyts for vue, react, bootstrap come out of the box to allow you to focus on writing code vs setting up webpack or gulp or grunt and managing that yourself
    - jbergens 9y ago
      There is nwb and create-react-app that takes care of initial configuration now. Unless you're gonna write everything from scratch you're gonna need to learn npm though.
  - zebra9978 9y ago
    hi, im helping build a fairly vanilla ecommerce site in either reactjs/vue. I want it to be entirely server-side rendered with high SEO visibility. However.. (and this is the big point), have the same APIs exposed for mobile apps as well. How do I do this ? Any templates to explore this pattern ? It is fairly straightforward to do this in rails, but in the world of react/vue, it seems that the whole community is geared towards rich client-side applications with low SEO.
    - jbergens 9y ago
      There are many examles, like next.js. Or search for isomorphic or universal js.
- davedx 9y ago
  Yeah, there is a lot of (developer driven) hype around new tools. I see it as both negative (hard to keep up, confuses those new to JS) and positive (lots of innovation and people trying many ways to solve things). If you want to learn a front end framework, pick one that's got a lot of community support (Angular, React, maybe Ember or Vue) and focus on it. Don't get distracted. Even when things change, it'll be good for a long while.
- pkstn 9y ago
  Try RE:DOM: https://redom.js.org https://redom.js.org ;)
- onion2k 9y ago
  I feel the same way about backend development. I stick to express.js because I know it, but I'm aware of at least a dozen other Node frameworks, and hundreds for other languages. Frontend is far from unique in growing in complexity as the web has changed.
- wruza 9y ago
  As a desktop developer, I rarely ever touched backends. Though they are not "modern js", it was close enough to that madness to stay away from it. Otoh, I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours. A month ago we started a project with a custom backend (on me) and had to choose a frontend option for our frontend-employee to use. It feels like hell, really. We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend. I don't know where it all goes about the web. Before, when I heard about new cool js framework, I thought "well, guys do The Technology". Now that I'm forced to dive into it, I see that they just reinvent square wheels in a wrong ways that were polished a decades ago in regular desktop apps. Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience. My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter.
  - deleted 9y ago
    [deleted]
  - sbergot 9y ago
    I hate to be that guy but you are confusing simplicity and familiarity. > I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours When I tried those things, I had a hard time making an hello world app in two hours because of dependency/build/tooling issues. However I was able to grasp angular 2 in two hours probably because I am more familiar with the frontend ecosystem. It would be like saying that because you knew english & german and was able to quickly learn swedish, you should be able to learn russian easily. > Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience. 15 years ago the js applications were nowhere as complex as they are today. So obviously things are a bit more difficult IF you want a rich application. If you just want to make a simple document you don't need all those librairies. > We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend This is your first project with a very unfamiliar tech. This was an expected outcome. > My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter. And that's a perfectly reasonable option, especially if you don't have someone with more experience in frontend tech to keep things sane.
- snarfy 9y ago
  The only thing that really sticks are the fundamentals like algorithms and design patterns. The tools always change. If you want to be a stronger developer down the road focus on the fundamentals. JS may seem hype driven because it is very active. I think you're right that it is hype driven as well simply due to human nature. We all fall for it on the rest of the internet. We fall for it when working with frameworks too. I mean, how many of us didn't really read the React license before building an app with it?
- hasenj 9y ago
  I've been doing frontend for several years and largely agree with what you're saying. It's not just frontend though; the entirety of all ecosystems springing around dynamic languages seem to suffer the same phenomenon.
- siddhant 9y ago
  I actually blogged about exactly this topic last year. As a backend developer (and a new entrant to the JS world), the one thing I was looking for from a JS framework was that it should scale with my application. And somehow none of the frameworks do well on that metric, except VueJS. Here's the post if you're interested -https://sgoel.org/posts/non-technical-reasons-why-i-like-vue/ https://sgoel.org/posts/non-technical-reasons-why-i-like-vue...
  - fiatjaf 9y ago
    React can do it, and any other virtual-dom framework. Your problem is that you're looking for a framework, but these are just libraries.
    - siddhant 9y ago
      Actually I'm just looking to get things done. I'm pretty sure React can do all those things and much more. But speaking as a backend dev, getting to a state where I can write useful code was faster with Vue than with React.
- spankalee 9y ago
  This is why Web Components are so important. It's great to have so much innovation, but when each innovation is incompatible with the next it makes it very difficult to actually use the better things. You can't incrementally adopt them, you have to port an entire application. This in turn makes it harder for new entrants to get adoption, even if they're better in some ways, because they need to reach a critical mass before many people are willing to put in the effort to, and accept the risk of, porting a whole app. If we establish the base component layer and interop with the platform and other components - which Web Components does - then people can innovate on the internals of components, things like how and when DOM is updated. This is mostly what's being focused on anyway, the component models themselves are usually pretty comparable. Not to mention that Shadow DOM is incredible and just fixes CSS. If Firefox finishes up their Web Components implementation soon, we'll be at 3/4 major browsers with native Web Components support. I think more people will take them as a given for basing their UI libraries on.
  - ausjke 9y ago
    I did look into web components and google polymer, great idea, still somehow not gaining much traction as they should.
    - spankalee 9y ago
      I work on Polymer, and I think we're well on the way to fixing that. Our uptake with large enterprises is quite good already, we're just not very popular with the HN crowd... yet. Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule https://summit.polymer-project.org/schedule
      - ausjke 9y ago
        Thanks. Looking forward to the live stream.
      - mbrumlow 9y ago
        I tried to push polymer at my work (I use it for personal projects). The problem I came into is I am a backend guy trying to convince that polymer and web components are the only sane way that I have ever seen to do web dev. To many people were set it their own ways had just flat out did not want to learn something new. They could not put down react and redux for two seconds. Admittedly I am not a front end developer, but when I did get some to have conversations many of them went like this -- How do you do xyz in polymer / web components -- Umm seems to be a concept your framework had to create at a work around, that is not something you will need to worry about any more. So what did we end up with? Some use react, some use ZK!?!, some just stick with straight up html/css/js -- oh and we have some angular too, but that fell apart because the guy doing it tried to do some weird shit with making some sort of tight integration with zk... Side rant, if I have somebody send me that video about how react just had to be created to fix unread notification count at facebook one more time... Webdev is a mess in my opinion and coming from the backend / systems side of things polymer / web components is the only thing that looks sane to me. Beyond what the component looks like I think a push in this direction will hopefully remove the requirement for a "web developer" vs just another developer who can work on any part of the project.
- chuckdries 9y ago
  They are super hype driven, now let me hype you for my personal fav. Vue is the most similar to vanilla JS that I've used so far. It stays out of your way and works like you expect it to. I like that it only handles the render layer. It says to you "Give me a template and give me data. The data is up to you, I'll handle keeping the template up to date." I'd love to use webcomponents but they're not going to totally replace these toolkits and right now the polyfill you need is atrociously slow.
  - spankalee 9y ago
    > polyfill you need is atrociously slow The polyfills haven't been slow since Polymer 0.8/1.0 when we switched away from the "full" Shadow DOM polyfill and to the much lighter-weight ShadyDOM shim (which trades a little spec compliance that Polymer hides, for speed). Polymer demos, like for HNPWA, are consistently among the fastest, even beating the speed-focused React clones.
    - pbowyer 9y ago
      > Polymer demos, like for HNPWA HNPWA?
      - zebra9978 9y ago
        https://github.com/nuxt/hackernews https://github.com/nuxt/hackernews
      - ergo14 9y ago
        https://hnpwa.com/ https://hnpwa.com/ - check out how fast polymer version is.
- deleted 9y ago
  [deleted]
- lopatin 9y ago
  I keep reiterating this point, but people keep calling React complex, it's not. React is raw simplicity. As far as I'm aware it's the most minimal API for creating sufficiently complex UIs. It's so minimal that it's hard to build full apps in because it says "not my problem" to questions such as routing, global state management, you name it. And that's fair. I still maintain that it's a tool for pros. But the responsibility that it does take on, I believe it does so in the most simple way possible. And you don't need to be aware of React internals to use it effectively. The details of the component lifecycle are not internals, but part of the public API.
  - look_lookatme 9y ago
    It's easy to say React is simple if you are looking at, say, a barebones create-react-app. But most production React apps I have worked on (I work at an consultancy) seem to accrete complexity faster than functionality. I used to chalk this up to me not "getting it". Now I think it has more to do with the desire to incorporate newness into React apps. Stuff like ripping out routers to replace with another router but then the old router was rewritten so lets replace it with that one again. That kind of stuff happens, and even it is preferable to someone deciding to incorporate something like [shudder] styled-components half way through a project. This kind of stuff almost always incorporates new abstractions that will increase surface complexity. In the interest of avoiding a rant, I won't start with people monkeying with context or not understanding the effects of setState. React should be judged by the quality of it's ecosystem and extant production code, and I would argue that if you survey these things often you will find plenty of unnecessary complexity.
    - cloverich 9y ago
      I have to agree w/ lopatin overall: React is a tool for professionals. And I think it addresses your arguments very well. Being open source and powerful, its reached for by people left and right who do not (yet) understand how to architect well constructed applications. And the results are predictable: Needless complexity, bloated apps, bad ui. Personally, I don't read any more into it than that.
    - 9y ago
- jaredklewis 9y ago
  > 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? I hear this sentiment a lot, but it always irks me. There seems to a general feeling amongst programmers new to front-end development that the current popular libraries have been over engineered and that the constant changes are driven by more by hype than actual need. From my view, the complexity in these libraries is mostly a reflection of the complexity of the underlying platform. Browsers and their JS engines are now monstrously complex and implement a horrifying number of web standards. When compared with browsers, something like the C++ compiler or the JVM suddenly looks childishly simple (and I'm not saying those things are simple). For example, it may not be apparent at first why something like React is a good idea, because it takes some knowledge of the performance characteristics of browser rendering to understand that. As for the churn, the libraries have been changing because the world has been changing. Back in the day, HTML was rendered server side and people used jQuery with little snippets of JS to modify small sections of the DOM. It only made sense to do that. But JS engines started to get really fast. Browsers finally started to use the DOM standards. People started working on solutions for all of JS's many warts, like not having any sort of module system and there being no good solution for package management. All these things came together in just a handful of years and suddenly it was possible to do actually cool stuff in browsers. Writing a browser based photoshop or itunes was no longer just the domain of tech giants like Google. When the world is literally turned upside down, that does shake things around a bit. So, if you are coming to web development from the backend, I don't think there is an easy path. The platform is complex. And just the idea of writing single page applications is only about 7 years old. That the first handful of years were somewhat chaotic is not surprising. But that aside, I would recommend to start with React and Redux.
- vmware513 9y ago
  If you are looking for a matured and easy to use solution, which follows convention over configuration pattern, so it helps to be the job done, I would highly recommend Ember.js Especially useful for us who come from backend world, so many concept will be familiar. You can learn the whole framework in a few days from www.yoember.com or from www.emberjs.com Especially the toolset and addon ecosystem will suprise you, so easy and fast. You will love it.
  - vmware513 9y ago
    http://ember.js.com http://ember.js.com http://yoember.com http://yoember.com
- keymone 9y ago
  i feel like i would've had similar feelings had i not learned (and pretty much fell in love with) clojure some years ago. now whether it's backend or frontend or even seamless code sharing between both - i am totally covered. react wrappers in clojure get unreal synergies with language design choices (immutable by default, convenient nested data structure manipulation, etc), things like this one - http://maksm.net/crypto-calculator/ http://maksm.net/crypto-calculator/ is 100 lines of code including html templates. obviously this all means having to learn another language but i dont need to touch js ever again and i'll take that trade any day.
  - fnordsensei 9y ago
    Where can I find the source code for the above?
    - keymone 9y ago
      didn't have it published anywhere yet but there you go: https://github.com/keymone/cryptick/blob/master/src/cryptick/core.cljs https://github.com/keymone/cryptick/blob/master/src/cryptick... it's a hacky little thing i threw together in couple hours so don't expect any best practices or idiomatic clojure[script]
- psteeleidem 9y ago
  Web components do not have a great story about passing complex data. If you want to pass typed data (not just strings) then declarative HTML suffers since HTML parses all attribute values as strings. You can use JavaScript properties to provide typed data to Web component custom elements, but properties cannot be provided declaratively in HTML and now you have two ways of providing data. With that said, I think there is value in building UI components in Marko and offering web component custom elements as one option for embedding your Marko-based UI component into a page (using a small UI bridge layer... something that we plan on open sourcing). --Marko author
- vborovikov 9y ago
  Take a look at IntercoolerJS. It's just a simple library, not a framework. I found it as the easiest way to deal with modern frontend programming. http://intercoolerjs.org/ http://intercoolerjs.org/
spacetexas 9y ago
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 9y ago
  Same reason someone picked up vue in first place?
11235813213455 9y ago
I really prefer to template html from js, so the react-way or even like this https://github.com/caub/dom-tagged-template https://github.com/caub/dom-tagged-template
tangue 9y ago
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 9y ago
  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 9y ago
    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.
jcelerier 9y ago
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.
- hobofan 9y ago
  How is that related to the topic? (apart from the last sentence)
  - jcelerier 9y ago
    isn't the topic reactive JS-based UI frameworks ? Marko compare itselfs to Vue; it should be compared to other UI frameworks in the same problem domain too.
    - hobofan 9y ago
      Saying 'this is what a "real" (whatever that is supposed to mean) reactive framework looks like' without saying anything else, is not really a constructive comment, and to me looks more like bashing or an attempt to start a flamewar. Apart from that Qt is a non-web framework, rarely used in combination with Javascript last time I checked, so even inside the problem domain it is barely related.
      - jcelerier 9y ago
        > Apart from that Qt is a non-web framework, rarely used in combination with Javascript last time I checked, so even inside the problem domain it is barely related. http://qmlweb.github.io/ http://qmlweb.github.io/ QML (the language in my snippet) is based on javascript; "rarely used in combination with Javascript last time I checked" has been false since roughly 2008 (wrong, actually 2010) when it was introduced.
dmitriid 9y ago
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 9y ago
  Given how little boilerplate there is for the actual code, I'll take the templating language.
deleted 9y ago
[deleted]
bryanph_ 9y ago
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.
- davedx 9y ago
  I feel the same way. It's a huge investment picking up an entirely new tech stack, and I'm not throwing that investment away every bloody year.
- Vinnl 9y ago
  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.)
- debaserab2 9y ago
  I feel like React has hit that tipping point that Rails did several years ago: it's no longer cool but it's still incredibly productive, and literally every new hip library that is currently flavor of the month is modeled after it in some way.
- psteeleidem 9y ago
  In another comment I mention that the biggest conceptual improvement that Marko offers is async and streaming rendering. Async changes how you think about passing data to your view (you start rendering immediately and you can retrieve backend data asynchronously to start rendering parts of the page asynchronously). Also, Marko is not tightly coupled to a VDOM (while React is) and because Marko is not tightly coupled to VDOM rendering we can achieve significantly better performance (sometimes over an oder magnitude faster than React on the server) and this absolutely can make a difference. The slowness of React (and the sync rendering) were huge blockers from the very beginning when we considered using React at eBay. --Marko author
brianon99 9y ago
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.
jarym 9y ago
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.
pier25 9y ago
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 9y ago
  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 9y ago
    > 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 9y ago
      > 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.
akras14 9y ago
Yay, another front end framework! /s
stuaxo 9y ago
This looks pretty decent.
dolphone 9y ago
You had me at isomorphic.
SeriousM 9y ago
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 9y ago
  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 :)
forkLding 9y ago
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 9y ago
  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
znpy 9y ago
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 9y ago
  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%.
sAbakumoff 9y ago
https://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com
jcranberry 9y ago
Isomorphic UI? WTF?? What's next, homotopic web frameworks and commutative app diagrams???
seangates 9y ago
For those interested in spreading this on PH: https://www.producthunt.com/posts/marko-js https://www.producthunt.com/posts/marko-js

276 points by jsnathan 9y ago

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 9y ago
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 9y ago
  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).
  - mrout 9y ago
    Vuex is no more tied to Vue than Redux is to React.
  - shangxiao 9y ago
    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.
    - mamp 9y ago
      > The community is though, if you don't do things with redux, react-router, etc then you're considered odd A bit disingenuous there. In general people find Redux quite complicated and it everyone acknowledges it requires quite a bit of boilerplate when used in the default way. Quite a few like MobX, or using their own state management. I've found the community to be very open to alternatives and helpful.
    - debaserab2 9y ago
      I've used neither of those libraries in any of the production React apps I've made.
      - boubiyeah 9y ago
        Me neither, thank god.
  - oulu2006 9y ago
    You've mentioned one of the exact reasons why I found Vue.js so much simpler. It's highly opinionated, which for 95% of the time, in my experience, is exactly what I want. I found myself much much more open to JS library fatigue with React; the ecosystem is so vast that it's hard to figure out which particular store I need, or which routing library I want or what form library I need and so on. I've seen a number of people complain about this, especially new comers. I find the opinionated nature of Vue.js so refreshing, especially for newcomers, which the OP is, hence why Vue.js is a much better option to begin with. And continue with, but that's a decision I guess the OP can make further down the road.
    - debaserab2 9y ago
      You don't need a route library. You don't need a form library. What do you need a routing library for? Have a single controller component (usually the most outer shell app component) and sprinkle in further functionality (e.g. history pushState) as necessary. Don't build it out until you actually need it. I've never needed a "form library" because forms are almost always interactive in some specific way. Using a form library is almost always guaranteed to just get in the way. You don't need to have a global state management library either if you have a good grasp of your apps data structures and how they need to be passed into components. I find with React I get the opposite of javascript fatigue: it's so easy to build anything you need once you understand react that you won't need to search for all those libraries and code snippets.
      - oulu2006 9y ago
        I guess we have completely different approaches to software development. I really hate reinventing the wheel, especially when good quality production tested solutions are out there. React libraries, quality wise, I've found hit or miss. I find Vuex a very nice global store and the tooling (chrome plugin etc..) is top-notch.
        debaserab2 9y ago
        You won't be reinventing the wheel for things like global state management and javascript routers. I promise. These libraries are huge solutions to problems that may or may not be huge - and in most of the cases I've seen, YAGNI. The concept of maintaining application state is nothing specific to SPA's. What is new is the idea that every application must have a global data store where all state is saved. This is a trend and not always necessarily a best practice. This isn't a matter of reinventing the wheel, it's a matter of using an oversized solution for an undersized problem.
- raphinou 9y ago
  Did I miss something or there's no explanation of what nuxtjs is on their website?
  - ycmbntrthrwaway 9y ago
    https://nuxtjs.org/guide https://nuxtjs.org/guide
- christilut 9y ago
  Don't start with nuxt. Start with the Vuejs tutorial on their website. Vuejs docs are amazing and one the big reasons why people enjoy starting Vue. Nuxt docs are so-so and can be quite confusing.
  - noir_lord 9y ago
    Agree with this. I tend not to use "quick starts" especially when using something new since you a) don't learn the internal gubbins b) are more fucked when something breaks. When I started with WebPack and TypeScript I deliberately started from an empty webpack.config.js and an empty tsconfig.js and added in stuff as I went at the end I had a decent understanding of what everything in both files actually did and they only did what I wanted. I've never found a quick start that helped me (in terms of total time) since the time spent fixing it when it breaks always exceeds the time taken from just doing it manually the first time, after I understand what I'm doing then I'll consider the quick starts.
    - musashizak 9y ago
      Poi is a good webpack wrapper for vue. Is a webpack with zero config
  - oulu2006 9y ago
    I guess I should have been more specific here, my bad. Reading the Vue.js docs online is of course the first port of call; the documentation is very good, so much better than Reacts. One of the few occasions I've been able to learn a good majority of the project without resorting to googling for tutorials and other community contributed resources. I recommended Nuxt as a good "this is how you put a enterprise ready Vue.js project together" so the OP would learn some good habits in project layout early on.
    - computerex 9y ago
      I tried to like VueJs but just couldn't. Seems just like another Angular 1.x like framework. I am done with HTML template API's. So many failed attempts using this concept. Anyone remember Polymer? That's what I thought.
- scottmf 9y ago
  Nuxt is the Vue version of Next, which I highly recommend for quickly bootstrapping a production-ready React app with server-side rendering and so on.
- wolco 9y ago
  For me I picked up React pretty quickly but I was using old school includes in the browser with the babel compiler. I tried moving to a newer version and start using with npm and webpack and I got a little lost. Started using the php framework laravel it has a mix package build in that makes everything very simple. My advice for backend developers is to use either the laravel framework or standalone npm laravel's mix package. With a simple command preseyts for vue, react, bootstrap come out of the box to allow you to focus on writing code vs setting up webpack or gulp or grunt and managing that yourself
  - jbergens 9y ago
    There is nwb and create-react-app that takes care of initial configuration now. Unless you're gonna write everything from scratch you're gonna need to learn npm though.
- zebra9978 9y ago
  hi, im helping build a fairly vanilla ecommerce site in either reactjs/vue. I want it to be entirely server-side rendered with high SEO visibility. However.. (and this is the big point), have the same APIs exposed for mobile apps as well. How do I do this ? Any templates to explore this pattern ? It is fairly straightforward to do this in rails, but in the world of react/vue, it seems that the whole community is geared towards rich client-side applications with low SEO.
  - jbergens 9y ago
    There are many examles, like next.js. Or search for isomorphic or universal js.
davedx 9y ago
Yeah, there is a lot of (developer driven) hype around new tools. I see it as both negative (hard to keep up, confuses those new to JS) and positive (lots of innovation and people trying many ways to solve things). If you want to learn a front end framework, pick one that's got a lot of community support (Angular, React, maybe Ember or Vue) and focus on it. Don't get distracted. Even when things change, it'll be good for a long while.
pkstn 9y ago
Try RE:DOM: https://redom.js.org https://redom.js.org ;)
onion2k 9y ago
I feel the same way about backend development. I stick to express.js because I know it, but I'm aware of at least a dozen other Node frameworks, and hundreds for other languages. Frontend is far from unique in growing in complexity as the web has changed.
wruza 9y ago
As a desktop developer, I rarely ever touched backends. Though they are not "modern js", it was close enough to that madness to stay away from it. Otoh, I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours. A month ago we started a project with a custom backend (on me) and had to choose a frontend option for our frontend-employee to use. It feels like hell, really. We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend. I don't know where it all goes about the web. Before, when I heard about new cool js framework, I thought "well, guys do The Technology". Now that I'm forced to dive into it, I see that they just reinvent square wheels in a wrong ways that were polished a decades ago in regular desktop apps. Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience. My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter.
- deleted 9y ago
  [deleted]
- sbergot 9y ago
  I hate to be that guy but you are confusing simplicity and familiarity. > I can't remember a time when I couldn't easily grasp any of Qt, Gtk, whateverTk toolkits in few hours When I tried those things, I had a hard time making an hello world app in two hours because of dependency/build/tooling issues. However I was able to grasp angular 2 in two hours probably because I am more familiar with the frontend ecosystem. It would be like saying that because you knew english & german and was able to quickly learn swedish, you should be able to learn russian easily. > Not to blame or insult good frontend people here and everywhere, but it feels like en masse they don't understand the programming essence at all. Sorry, but UI development was never HARDER than today. My colleague feels the same, having more than 15 years of html/css/js experience. 15 years ago the js applications were nowhere as complex as they are today. So obviously things are a bit more difficult IF you want a rich application. If you just want to make a simple document you don't need all those librairies. > We picked Angular2 randomly after few probes and it seems that out project has more quirks, hacks and LoC than if we just coded it in pure js with heavy templating help from e.g. perl backend This is your first project with a very unfamiliar tech. This was an expected outcome. > My thoughts are we're throwing it out next week and generate all ui with decent server-side scripts, leaving /js/util.js of 1kloc as a broker and generic table sorter. And that's a perfectly reasonable option, especially if you don't have someone with more experience in frontend tech to keep things sane.
snarfy 9y ago
The only thing that really sticks are the fundamentals like algorithms and design patterns. The tools always change. If you want to be a stronger developer down the road focus on the fundamentals. JS may seem hype driven because it is very active. I think you're right that it is hype driven as well simply due to human nature. We all fall for it on the rest of the internet. We fall for it when working with frameworks too. I mean, how many of us didn't really read the React license before building an app with it?
hasenj 9y ago
I've been doing frontend for several years and largely agree with what you're saying. It's not just frontend though; the entirety of all ecosystems springing around dynamic languages seem to suffer the same phenomenon.
siddhant 9y ago
I actually blogged about exactly this topic last year. As a backend developer (and a new entrant to the JS world), the one thing I was looking for from a JS framework was that it should scale with my application. And somehow none of the frameworks do well on that metric, except VueJS. Here's the post if you're interested -https://sgoel.org/posts/non-technical-reasons-why-i-like-vue/ https://sgoel.org/posts/non-technical-reasons-why-i-like-vue...
- fiatjaf 9y ago
  React can do it, and any other virtual-dom framework. Your problem is that you're looking for a framework, but these are just libraries.
  - siddhant 9y ago
    Actually I'm just looking to get things done. I'm pretty sure React can do all those things and much more. But speaking as a backend dev, getting to a state where I can write useful code was faster with Vue than with React.
spankalee 9y ago
This is why Web Components are so important. It's great to have so much innovation, but when each innovation is incompatible with the next it makes it very difficult to actually use the better things. You can't incrementally adopt them, you have to port an entire application. This in turn makes it harder for new entrants to get adoption, even if they're better in some ways, because they need to reach a critical mass before many people are willing to put in the effort to, and accept the risk of, porting a whole app. If we establish the base component layer and interop with the platform and other components - which Web Components does - then people can innovate on the internals of components, things like how and when DOM is updated. This is mostly what's being focused on anyway, the component models themselves are usually pretty comparable. Not to mention that Shadow DOM is incredible and just fixes CSS. If Firefox finishes up their Web Components implementation soon, we'll be at 3/4 major browsers with native Web Components support. I think more people will take them as a given for basing their UI libraries on.
- ausjke 9y ago
  I did look into web components and google polymer, great idea, still somehow not gaining much traction as they should.
  - spankalee 9y ago
    I work on Polymer, and I think we're well on the way to fixing that. Our uptake with large enterprises is quite good already, we're just not very popular with the HN crowd... yet. Our annual summit starts Tuesday, and the talks are live-streamed, check them out for some updates: https://summit.polymer-project.org/schedule https://summit.polymer-project.org/schedule
    - ausjke 9y ago
      Thanks. Looking forward to the live stream.
    - mbrumlow 9y ago
      I tried to push polymer at my work (I use it for personal projects). The problem I came into is I am a backend guy trying to convince that polymer and web components are the only sane way that I have ever seen to do web dev. To many people were set it their own ways had just flat out did not want to learn something new. They could not put down react and redux for two seconds. Admittedly I am not a front end developer, but when I did get some to have conversations many of them went like this -- How do you do xyz in polymer / web components -- Umm seems to be a concept your framework had to create at a work around, that is not something you will need to worry about any more. So what did we end up with? Some use react, some use ZK!?!, some just stick with straight up html/css/js -- oh and we have some angular too, but that fell apart because the guy doing it tried to do some weird shit with making some sort of tight integration with zk... Side rant, if I have somebody send me that video about how react just had to be created to fix unread notification count at facebook one more time... Webdev is a mess in my opinion and coming from the backend / systems side of things polymer / web components is the only thing that looks sane to me. Beyond what the component looks like I think a push in this direction will hopefully remove the requirement for a "web developer" vs just another developer who can work on any part of the project.
chuckdries 9y ago
They are super hype driven, now let me hype you for my personal fav. Vue is the most similar to vanilla JS that I've used so far. It stays out of your way and works like you expect it to. I like that it only handles the render layer. It says to you "Give me a template and give me data. The data is up to you, I'll handle keeping the template up to date." I'd love to use webcomponents but they're not going to totally replace these toolkits and right now the polyfill you need is atrociously slow.
- spankalee 9y ago
  > polyfill you need is atrociously slow The polyfills haven't been slow since Polymer 0.8/1.0 when we switched away from the "full" Shadow DOM polyfill and to the much lighter-weight ShadyDOM shim (which trades a little spec compliance that Polymer hides, for speed). Polymer demos, like for HNPWA, are consistently among the fastest, even beating the speed-focused React clones.
  - pbowyer 9y ago
    > Polymer demos, like for HNPWA HNPWA?
    - zebra9978 9y ago
      https://github.com/nuxt/hackernews https://github.com/nuxt/hackernews
    - ergo14 9y ago
      https://hnpwa.com/ https://hnpwa.com/ - check out how fast polymer version is.
deleted 9y ago
[deleted]
lopatin 9y ago
I keep reiterating this point, but people keep calling React complex, it's not. React is raw simplicity. As far as I'm aware it's the most minimal API for creating sufficiently complex UIs. It's so minimal that it's hard to build full apps in because it says "not my problem" to questions such as routing, global state management, you name it. And that's fair. I still maintain that it's a tool for pros. But the responsibility that it does take on, I believe it does so in the most simple way possible. And you don't need to be aware of React internals to use it effectively. The details of the component lifecycle are not internals, but part of the public API.
- look_lookatme 9y ago
  It's easy to say React is simple if you are looking at, say, a barebones create-react-app. But most production React apps I have worked on (I work at an consultancy) seem to accrete complexity faster than functionality. I used to chalk this up to me not "getting it". Now I think it has more to do with the desire to incorporate newness into React apps. Stuff like ripping out routers to replace with another router but then the old router was rewritten so lets replace it with that one again. That kind of stuff happens, and even it is preferable to someone deciding to incorporate something like [shudder] styled-components half way through a project. This kind of stuff almost always incorporates new abstractions that will increase surface complexity. In the interest of avoiding a rant, I won't start with people monkeying with context or not understanding the effects of setState. React should be judged by the quality of it's ecosystem and extant production code, and I would argue that if you survey these things often you will find plenty of unnecessary complexity.
  - cloverich 9y ago
    I have to agree w/ lopatin overall: React is a tool for professionals. And I think it addresses your arguments very well. Being open source and powerful, its reached for by people left and right who do not (yet) understand how to architect well constructed applications. And the results are predictable: Needless complexity, bloated apps, bad ui. Personally, I don't read any more into it than that.
  - 9y ago
jaredklewis 9y ago
> 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? I hear this sentiment a lot, but it always irks me. There seems to a general feeling amongst programmers new to front-end development that the current popular libraries have been over engineered and that the constant changes are driven by more by hype than actual need. From my view, the complexity in these libraries is mostly a reflection of the complexity of the underlying platform. Browsers and their JS engines are now monstrously complex and implement a horrifying number of web standards. When compared with browsers, something like the C++ compiler or the JVM suddenly looks childishly simple (and I'm not saying those things are simple). For example, it may not be apparent at first why something like React is a good idea, because it takes some knowledge of the performance characteristics of browser rendering to understand that. As for the churn, the libraries have been changing because the world has been changing. Back in the day, HTML was rendered server side and people used jQuery with little snippets of JS to modify small sections of the DOM. It only made sense to do that. But JS engines started to get really fast. Browsers finally started to use the DOM standards. People started working on solutions for all of JS's many warts, like not having any sort of module system and there being no good solution for package management. All these things came together in just a handful of years and suddenly it was possible to do actually cool stuff in browsers. Writing a browser based photoshop or itunes was no longer just the domain of tech giants like Google. When the world is literally turned upside down, that does shake things around a bit. So, if you are coming to web development from the backend, I don't think there is an easy path. The platform is complex. And just the idea of writing single page applications is only about 7 years old. That the first handful of years were somewhat chaotic is not surprising. But that aside, I would recommend to start with React and Redux.
vmware513 9y ago
If you are looking for a matured and easy to use solution, which follows convention over configuration pattern, so it helps to be the job done, I would highly recommend Ember.js Especially useful for us who come from backend world, so many concept will be familiar. You can learn the whole framework in a few days from www.yoember.com or from www.emberjs.com Especially the toolset and addon ecosystem will suprise you, so easy and fast. You will love it.
- vmware513 9y ago
  http://ember.js.com http://ember.js.com http://yoember.com http://yoember.com
keymone 9y ago
i feel like i would've had similar feelings had i not learned (and pretty much fell in love with) clojure some years ago. now whether it's backend or frontend or even seamless code sharing between both - i am totally covered. react wrappers in clojure get unreal synergies with language design choices (immutable by default, convenient nested data structure manipulation, etc), things like this one - http://maksm.net/crypto-calculator/ http://maksm.net/crypto-calculator/ is 100 lines of code including html templates. obviously this all means having to learn another language but i dont need to touch js ever again and i'll take that trade any day.
- fnordsensei 9y ago
  Where can I find the source code for the above?
  - keymone 9y ago
    didn't have it published anywhere yet but there you go: https://github.com/keymone/cryptick/blob/master/src/cryptick/core.cljs https://github.com/keymone/cryptick/blob/master/src/cryptick... it's a hacky little thing i threw together in couple hours so don't expect any best practices or idiomatic clojure[script]
psteeleidem 9y ago
Web components do not have a great story about passing complex data. If you want to pass typed data (not just strings) then declarative HTML suffers since HTML parses all attribute values as strings. You can use JavaScript properties to provide typed data to Web component custom elements, but properties cannot be provided declaratively in HTML and now you have two ways of providing data. With that said, I think there is value in building UI components in Marko and offering web component custom elements as one option for embedding your Marko-based UI component into a page (using a small UI bridge layer... something that we plan on open sourcing). --Marko author
vborovikov 9y ago
Take a look at IntercoolerJS. It's just a simple library, not a framework. I found it as the easiest way to deal with modern frontend programming. http://intercoolerjs.org/ http://intercoolerjs.org/

spacetexas 9y ago

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 9y ago
Same reason someone picked up vue in first place?

11235813213455 9y ago

I really prefer to template html from js, so the react-way or even like this https://github.com/caub/dom-tagged-template https://github.com/caub/dom-tagged-template

tangue 9y ago

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 9y ago
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 9y ago
  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.

jcelerier 9y ago

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.

hobofan 9y ago
How is that related to the topic? (apart from the last sentence)
- jcelerier 9y ago
  isn't the topic reactive JS-based UI frameworks ? Marko compare itselfs to Vue; it should be compared to other UI frameworks in the same problem domain too.
  - hobofan 9y ago
    Saying 'this is what a "real" (whatever that is supposed to mean) reactive framework looks like' without saying anything else, is not really a constructive comment, and to me looks more like bashing or an attempt to start a flamewar. Apart from that Qt is a non-web framework, rarely used in combination with Javascript last time I checked, so even inside the problem domain it is barely related.
    - jcelerier 9y ago
      > Apart from that Qt is a non-web framework, rarely used in combination with Javascript last time I checked, so even inside the problem domain it is barely related. http://qmlweb.github.io/ http://qmlweb.github.io/ QML (the language in my snippet) is based on javascript; "rarely used in combination with Javascript last time I checked" has been false since roughly 2008 (wrong, actually 2010) when it was introduced.

dmitriid 9y ago

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 9y ago
Given how little boilerplate there is for the actual code, I'll take the templating language.

deleted 9y ago

[deleted]

bryanph_ 9y ago

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.

davedx 9y ago
I feel the same way. It's a huge investment picking up an entirely new tech stack, and I'm not throwing that investment away every bloody year.
Vinnl 9y ago
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.)
debaserab2 9y ago
I feel like React has hit that tipping point that Rails did several years ago: it's no longer cool but it's still incredibly productive, and literally every new hip library that is currently flavor of the month is modeled after it in some way.
psteeleidem 9y ago
In another comment I mention that the biggest conceptual improvement that Marko offers is async and streaming rendering. Async changes how you think about passing data to your view (you start rendering immediately and you can retrieve backend data asynchronously to start rendering parts of the page asynchronously). Also, Marko is not tightly coupled to a VDOM (while React is) and because Marko is not tightly coupled to VDOM rendering we can achieve significantly better performance (sometimes over an oder magnitude faster than React on the server) and this absolutely can make a difference. The slowness of React (and the sync rendering) were huge blockers from the very beginning when we considered using React at eBay. --Marko author

brianon99 9y ago

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.

jarym 9y ago

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.

pier25 9y ago

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 9y ago
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 9y ago
  > 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 9y ago
    > 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.

akras14 9y ago

Yay, another front end framework! /s

stuaxo 9y ago

This looks pretty decent.

dolphone 9y ago

You had me at isomorphic.

SeriousM 9y ago

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 9y ago
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 :)

forkLding 9y ago

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 9y ago
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

znpy 9y ago

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 9y ago
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%.

sAbakumoff 9y ago

https://dayssincelastjavascriptframework.com https://dayssincelastjavascriptframework.com

jcranberry 9y ago

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

seangates 9y ago

For those interested in spreading this on PH: https://www.producthunt.com/posts/marko-js https://www.producthunt.com/posts/marko-js