15 ms·

Show HN: An Isomorphic JavaScript Framework Faster Than React

• bananaoomarang 11y ago
  In my view, one of the huge benefits of react is the lack of two-way data binding, since the one-way flow of flux is far easier to think about IMO. Speed is one thing, but when the framework you have is fast enough, a little more for a sacrifice of code reason-ability seems undesirable.
• snarfy 11y ago
  > <div data-query="each(products)"> Well, one problem is declarative programming has never been as expressive as imperative programming. In React you'd use JavaScript for this iteration. This is why I like React over say Angular, with ng-each, ng-if, etc. Flow control does not belong in markup. I cringed the first time I saw an XML schema with an IF element.
  • nahiluhmot 11y ago
    I would argue that React is a declarative style as well, the difference between it and the above example being that JS is far more expressive than HTML.
  • talles 11y ago
    In the beginning we mixed style with content. Now we're mixing logic which, IMO, is an even worst mistake.
  • dkersten 11y ago
    Flow control does not belong in markup. My favourite templating system is enlive[1] (or enliven[2]). You use CSS-style selectors to select snippets of HTML to manipulate and then use code to duplicate, remove, move or replace these snippets, insert content, set attributes etc. The "template" is pure HTML without any additional markup and without any logic. The code then says "repeat this snippet for every item in this list and insert it over there" (or whatever you need). Markup does what its good at, code does what its good at. Works out really nicely. Although nowadays I use reagent and hiccup-style markup and write everything in code (but keep my components as pure and dumb as possible). [1] https://github.com/cgrand/enlive https://github.com/cgrand/enlive [2] https://github.com/cgrand/enliven https://github.com/cgrand/enliven
    • astoilkov 11y ago
      What do you think about OneScript - https://github.com/astoilkov/OneScript https://github.com/astoilkov/OneScript?
      • dkersten 11y ago
        Can't say I'm a fan honestly. Reminds me too much of PHP, I guess. The thing about reagent/hiccup is that the markup is just a clojurescript data structure and can be composed and manipulated like one. This also means that you can easily write pure functions to generate the UI (data in, markup out). The thing about enlive/enliven is that the markup and the logic are completely separated. OneScript has neither of the things that I like about enlive or reagent. EDIT: I should probably add that I'm not particularly a fan of JSX either, so I'm probably the wrong person to ask for an opinion on this.
    • Wintamute 11y ago
      How do the frontenders and CSS folk feel about you making assumptions about what CSS selectors there should be in order to render a template on the backend? Its hard enough to get dedicated frontend folk to stick to an adaptable/maintainable CSS architecture like SUITCSS, let alone backenders too. I've always thought Enlive seems to create a brittle co-dependency between frontend and backend codebases, ok for small projects with 1 or 2 devs with skills that span front and backend, but surely a nightmare for larger project with lots of people working on them?
    • arnarbi 11y ago
      Genshi [1] is (was?) wonderful in a similar respect. Although the "code" was itself an html document, it allows master templates to fully select and manipulate nodes from child templates. [1] http://genshi.edgewall.org/ http://genshi.edgewall.org/
  • aikah 11y ago
    A lot of stupid arguments in your message, the biggest being : > Well, one problem is declarative programming has never been as expressive as imperative programming Haskell is declarative, are you saying Haskell isn't expressive ? > Flow control does not belong in markup > In React you'd use JavaScript for this iteration There is no flow control in HTML , but some frameworks use DSLs in the HTML. If you are saying frameworks shouldn't be using DSLs yet you praise React which uses JSX which contains a declarative DSL in form of XML markup ... your point is a big contradiction.
    • insin 11y ago
      <div data-query="each(products)"> ... </div> The React (or Mithril, or Mercury, or other virtual DOM libraries - just change the function being called) equivalent would be: products.map(product => React.createElement('div', null, ... )) Which you can use JSX (again in any virtual DOM library, via Babel) to sugar as: products.map(product => <div> ... </div>) The flow control is outside the DSL, not part of it.
    • reverius42 11y ago
      A DSL for logic inside of a declarative markup language is very different from a DSL for declarative markup inside a programming language.
  • nashashmi 11y ago
    You are right. Flow control does not belong in markup. But what if I redefined the logic and called them instead relationships. Could relationships be declared in markup? Could behaviors be declared in markup? Then we would expect the browser and the script to play with the relationships according to the behaviors.
  • Touche 11y ago
    The other-side of the argument is that JavaScript is much harder to tool than HTML.
    • talles 11y ago
      If I heard such statement in a debate I would stress that word harder.
• _pmf_ 11y ago
  > Isomorphic JavaScript Framework No. Just no.
  • ycitm 11y ago
    Is this just criticism of the "isomorphic" term? I'm not a fan of it either ("isomorphic" already has a different well-defined meaning in CS), but it does seem to have some traction now. Perhaps you have an alternative term you'd prefer these frameworks used?
    • barkmadley 11y ago
      I've seen "progressive javascript"[1] and "heterogeneous javascript". Both of which are much better IMHO. [1]: https://medium.com/the-thinkmill/making-the-case-for-progressive-javascript-a98dfa82b9d7 https://medium.com/the-thinkmill/making-the-case-for-progres...
      • ycitm 11y ago
        Agreed, both of those are better. Hopefully one will gain traction. Thanks for the link, good to know people are thinking about the naming issues.
    • tunesmith 11y ago
      I've seen "split rendering" a few times.
• astoilkov 11y ago
  I agree. I am not saying jsblocks is better. It is choice of what you prefer. jsblocks offers Backbone like MVC structure and easy to manage observables. It also have a unique debugging experience - http://jsblocks.com/learn/introduction-why-jsblocks#debugging-experience http://jsblocks.com/learn/introduction-why-jsblocks#debuggin.... It also packs things like routing and animation integration which React lacks out of the box.
• mambodog 11y ago
  It's not hard to be faster than React, React's performance benefit comes from the fact it makes performance easy to understand and optimise rather than just being magically (but opaquely) fast. However, the real reason React is a good choice is not performance, but rather how it encourages developers to think about, isolate and better manage mutable state in their applications.
  • idibidiart 11y ago
    Correct. But React is also a step behind ClojureScript based React wrappers :) like Om and Reagent.
    • zaynetro 11y ago
      Could you explain why are they step ahead? I am not familiar with ClojureScript, but my interest in it is really high.
      • alejandrodob 11y ago
        Because Clojurescript uses immutable data structures, and keeps the state in a centralized atom, so comparing different states is as easy (and fast) as comparing the different versions of the data structure, which in turn (and thanks to being immutable data structures) reduces to compare their memory references, which is fast.
        • mbrock 11y ago
          Centralized state as an immutable data structure is exactly how the app I work with is built. It's plain JavaScript and React. So I don't see how React is "behind" on this front.
        • xtrumanx 11y ago
          Immutable.js is a project also from FaceBook that brings immutable data structures to your JS applications including those using React. Since Clojurescript compiles down to JS, wouldn't it be possible to use Immutable.js and a slightly different app design (a single Flux Store for the entire app) to get the same benefit of using React with Clojurescript?
• sairion 11y ago
  "Faster than React" does mean anything?
  • astoilkov 11y ago
    You could take a look at the performance chart at the home page and inspect the project containing the tests - http://jsblocks.com/downloads/jsblocks-performance.zip http://jsblocks.com/downloads/jsblocks-performance.zip. In general rendering and syncing changes are faster.
  • JDDunn9 11y ago
    React.js is a new popular toolkit by Facebook (http://facebook.github.io/react/ http://facebook.github.io/react/)
    • seliopou 11y ago
      I think he meant to imply that React is slow.
• juliangregorian 11y ago
  lodash slower than underscore? Isn't lodash's primary purpose to be a more performant drop-in for underscore? Would love to see these benchmarks in a jsPerf.
  • striking 11y ago
    Guess not. http://jsperf.com/ldash-vs-underscore http://jsperf.com/ldash-vs-underscore
    • zilean 11y ago
      Why link version with year old code? https://jsperf.com/ldash-vs-underscore/3 https://jsperf.com/ldash-vs-underscore/3
      • bpicolo 11y ago
        Lodash was still slightly slower here for me. Chrome 43.0.2357.65 on OS X 10.10.0
  • astoilkov 11y ago
    I have discussions with lodash creator. jsblocks is only faster in some cases and almost the same speed in other cases. Underscore is slower in general than lodash just the test cases shows some isolated scenario.
• anshin 11y ago
  This is interesting, but it doesn't excite me. My initial reaction is to be curious as to why it's able to thrash underscore and lodash (and React too, but separately) on speed. There could be many reasons for this. Maybe I'm personally not interested in adopting a new framework, maybe your target audience (which includes me) has some sort of fatigue or lack of interest, maybe speed isn't enough of a reason to sell me (or us) on its own, or maybe your landing page needs work. I'm not sure, but maybe my comment will help identify an/the issue – or maybe there is no issue, and it's just me. Thanks for making a JS framework and posting it here. That takes a lot of guts and is notorious for inviting hostility. I appreciate it.
  • striking 11y ago
    I think it's because people are tired of the thrashing between/around the "next big thing." Angular was supposed to fix everything, React is still trying to fix everything... But even Atom stopped using React because it was so slow. As for this framework, I'd be happier if it came in discrete chunks that you could wire together, because if you're not happy with one part of it, you don't have to accept it. You can instead build your own.
    • astoilkov 11y ago
      Nice hearing that. I am currently working on making the framework more modular. This is create powerful individual modules that could be used for other purposes not only in MV* Framework.
    • anilgulecha 11y ago
      > But even Atom stopped using React because it was so slow That's a mischaracterization -- it was only slow for a very specific usecase -- rendering a source code text-view. (It's like using an optimized C plugin in your python project for that core part that needs the benefit of performance.) React makes a LOT of sense for a JS framework, and it's not a surprise that it's among the most popular ones now. To simply call it unusable because ONE particular usecase did not suit it is doing it an injustice.
  • curveship 11y ago
• yummybear 11y ago
  I think it's great that there is such an amount of active development in the JS sphere, and I'm sure your framework is fantastic - so don't take this as directed at your framework specifically. That being said... I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. I constantly feel that I'm behind on my homework having to evaluate new libraries and frameworks showing up. Every two weeks, another one shows up with another paradigm shifting approach. I am getting increasingly apprehensive about committing myself to learning anything new, because in two weeks there's another shiny framework that everyone is proclaiming as the next wunderkind. Sorry about the 6 months spent learning it, but now we're doing something new. The amount of time where I feel that I am confident and productive with a library or framework is getting shorter and shorter, and more and more of my time learning, I feel is wasted. Sorry to barf all over your post - like I said, it's nothing specifically with your framework, and it looks very shiny on the surface, but I think I'll just get back to work instead of studying it in greater detail.
  • kuyfiuyg 11y ago
    So don't study it then? It's perfectly fine to continue using what you are using. Most recruiters talking to me still ask for Angular, even if I consider it a little hairy and prefer not using it. After being in the JS sphere for a while and living with these changes, I have learned a lot. Because there is nothing new under the sun, these all do pretty much the same thing - but in different ways. There are tradeoffs, and by working with and making big and small products in different frameworks, I've learned how to learn. Picking up new things are not always needed, but the more you expose yourself to different libs, frameworks and platforms, the better you get at it.
    • kyllo 11y ago
      The problem is, it's our fault that recruiters are now asking for Angular, because we sold our employers on Angular and built their apps in Angular. Now that Angular is mainstream and has fallen out of fashion, they need to hire more developers to maintain all those Angular apps we built for them.
• pothibo 11y ago
  People here dismissing this framework due to 'fatigue' or 'overexposure'. It's weird as I don't recall hearing this when React started to see adoption 8 months ago.
  • rattray 11y ago
    React was released by Facebook as a mature project. There wasn't much doubt as to whether it would be at least worth considering. There also may have been fewer JavaScript frameworks released that month (Dekku came out something like last week).
• nailer 11y ago
  Is isomorphic JavaScript a thing? Isn't it just 'using jsdom'?
  • astoilkov 11y ago
    No. jsdom is not the perfect solution. jsblocks is using Virtual DOM and have specific implementation to support server-side rendering which makes the framework more powerful and flexible.
    • tinganho 11y ago
      How is it Isomorphic? I can't see how the example illustrates server-side rendering? Just an HTML file?
  • zilean 11y ago
    It is, but i dunno why every other new framework pushes that, when you can do this in react with some conventions and 30 lines of node code. AFAIK ember fastboot gonna use jsdom and they are planning to release something for a long time, may be it is focus thing, or just too painful to do that using naive jsdom rendering.
• andrewstuart 11y ago
  I care less about react's performance than that it at last brings code organisation that makes sense.
• ndreckshage 11y ago
  Still relies on JavaScript server side rendering - which will be the biggest performance bottleneck, by far, for both this and React. If you really want a framework that is faster, check out Tungsten (https://github.com/wayfair/tungstenjs https://github.com/wayfair/tungstenjs), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.
  • nahiluhmot 11y ago
    I can't speak to this framework, but you do not need to use server-side rendering for React applications. Instead, you can essentially serve a blank page on every request, then have the React application bootstrap itself when the page loads. Alternatively, one could precompile the HTML, and serve it as static content with nginx, apache, etc.
    • ndreckshage 11y ago
      Correct, not rendering on the server removes the bottleneck.
    • towelguy 11y ago
      It's funny Meteor actually has this problem upside down and are trying to add a way to have server side rendering.
• k__ 11y ago
  Performance comparisons with Angular and React aren't that interesting anymore. They are good because they got Facebook/Google behind them and not because they are blazing the rest of the Frameworks away. Mess yourself with Mithril, Mercury or Elm.
  • xyzzy123 11y ago
    Right; a large part of the "is this framework worth using" question really relies on "can we get other developers to work on this", "can we make a business case for it", "how is hiring going to work", and critically: "will stack overflow work for us". 50ms on the client is very negotiable and trivial versus cultural concerns.
• amelius 11y ago
  If you have N virtual dom nodes, and you are going to compare them every time a single thing changes, your performance may be good, as long as N is small. Unfortunately, React and similar frameworks don't deal with the case that N is large.
  • lhorie 11y ago
    Actually, they do. React has shouldComponentUpdate, Mithril has subtree directives, Mercury has thunks, etc. One big difference between vdom frameworks and KVO/dirty checking frameworks is that since the virtual dom tree is in plain view (pun intended), it's possible to use advanced features to micro-optimize the hell out of it, whereas other types of engines tend to be more "black boxy" and make these kinds of optimization nearly impossible.
    • acdha 11y ago
      That only helps if you had poor state management and churning updates to things which hadn't changed. If you actually have a large number of DOM elements which need to be updated, you'll find that React is an order of magnitude worse than just using the DOM directly because it has to do that extra book-keeping multiplied by the number of elements.
      • lhorie 11y ago
        Touching the DOM is by far the biggest bottleneck in performance. Of course for some arbitrary discrete task, hand coded DOM manipulation code is always going to be faster than a layer of abstraction on top of it. But the strength of virtual dom is that a single piece of code can handle insertions, deletions, sorts, splices and pretty much any data contortion you can throw at it without increasing code debt. Managing all of those w/ only the DOM API (or jQuery) as an application grows is difficult, and it's one of the main reasons why frameworks exist in the first place.
        • acdha 11y ago
          > Touching the DOM is by far the biggest bottleneck in performance My point was simply that this devolves back to Amdahl's law: the only way that React overhead + the DOM can be faster than the DOM alone is when the pure-DOM code is doing too much work. It's possible that React makes the code so much easier to maintain that you write better algorithms but that has very little to do with the virtualdom rather than the strong push towards better structure.
• icemelt8 11y ago
  I seriously think this is some sort of parody of JS. Really? A new framework every week?
  • avinassh 11y ago
    As someone who mostly codes in Python, I don't understand, why JS gets new framework so often. What is the reason behind? Is Javascript makes thing easy to develop a new framework? Why doesn't Python get new framework so often?
    • winterbe 11y ago
      Server code is spread across different languages. But every webdev is forced to use JS on the client. It's the sheer amount of people using this language.
    • kbody 11y ago
      I've been coding JS for a while now, and it personally feels having imposter syndrome most of the time. It's easy to get into making/sharing something, but has no (strict) guidelines on how things are structured or work. So you have countless ways to do one thing.
    • moron4hire 11y ago
      It because package management in JS is complete garbage. I can't believe people actually like using Bower or Browserify or JSPM or any of it. While NPM for Node has some scaling problems, at least it just works for the simple cases. I've never not had problems with the client-side JS package systems and managers. So package adoption is hard because of this. If you make it a pain for implementing developers to use your code, they're more likely to just write their own code. That's why I think the old style ala jQuery or Google Maps API of packaging everything manually as just namespacing-objects still makes the most sense, with the fewest tradeoffs. You give the user a single, minified JS file to either copy or reference on your CDN. It's a least-common-denominator solution and it lets the implementing developer figure out how to fit it into their workflow.
      • 11y ago
• bshimmin 11y ago
  Top article on the front page of Hacker News as I write this, and not a single positive comment below. Great job, guys... To the author: I think the homepage looks great, the examples are clear and informative, and I would definitely give this a try if I weren't wed to a couple of other frameworks right now.
  • rattray 11y ago
    I think a lot of the negativity has to do with the marketing. This isn't being sold as "a cool thing I made", but "Better MV-ish Framework" and "Faster than React". If you try to position it as better than existing alternatives, HN commenters will tear it down if they don't think it makes the cut. If you put it out as "exploring interesting new approaches", I think you're likely to see a lot less negativity here. Compare to the launch of Mithril: https://news.ycombinator.com/item?id=7421652 https://news.ycombinator.com/item?id=7421652 EDIT: Actually, revisiting this, the problem may be more with the fact that it hit the front page than the fact it has a lot of negative comments. If nobody here seems to like it, how did it get 182 upvotes? That seems like a problem with our community, eg; upvoting before actually looking at the article. (Note: I don't mean to comment on whether this is a good framework, just that the HN community doesn't seem to like it much).
    • astoilkov 11y ago
      You are totally correct. I believe it could have taken another direction if I have done this. It is hard to be compared to React built by Facebook but I started first. :)
    • bshimmin 11y ago
      Absolutely fair points. Another one: the general weariness with which new JS frameworks are greeted has increased massively in the 433 days since Mithril was posted here.
    • alexc05 11y ago
      on record: I loved working in Mithril and am a huge fan of Leo one of the nicest guys around.
• emehrkay 11y ago
  I've been playing around with RiotJs (actually committed some fixes/features to the repo). I think what is attractive about both Riot and React is that everything is "defined" in JavaScript, there isn't really a separation of markup and behavior. Each little module can act an individual component. React has gone a step further and has shown that the DOM doesn't really matter...your React code could create native apps. Does jsblocks allow users to develop little objects that encapsulate whats's needed for that component to work? The examples seem to have separate html/js/css.
  • astoilkov 11y ago
    Cool question. Please take a look at OneScript - https://github.com/astoilkov/OneScript https://github.com/astoilkov/OneScript and share your opinion. I believe this is the next step in developing applications. Bringing HTML, CSS and JavaScript in one place where components are modular and small.
    • emehrkay 11y ago
      I like this syntax. How do you pass values to a component and how do you nest components with values and lets say, loop over an array and create a (sub)component? Also, when you embed a component, is there a way to interact with it? This looks cool, keep it up
      • astoilkov 11y ago
        Great questions. I currently filling the documentation so you could watch the repo or star it and keep an eye on it. The idea is that components will be like objects and elements so you could easily access them. Take a look at this example: <div> { this.each(profiles); <!-- Render all profiles --> <Profile> } <div> { this.find('Profile').setIsMyProfile(true); <!-- render personal profile --> My profile. <Profile> }
    • j1e 11y ago
      " I believe this is the next step in developing applications." Agreed - encapsulation is key to managing complexity.
• ttty 11y ago
  Thanks for highlighting 2 things: "Level UP your HTML" and "Two-way data binding".. Already made my decision, stick with react! (:
  • nicklovescode 11y ago
    You perhaps have a reasonable criticism but there is no need to wrap it in a sarcastic insult
• ojr 11y ago
  This is interesting but the performance comparison is a moot point for me. React also has React Native, the pros of a faster isomorphic javascript framework working in the browser is not a very strong selling point in a world where native apps are dominating the mobile web. React will help me reach more platforms. http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/ http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/
  • astoilkov 11y ago
    Yeah definitely. It is hard to be compared to React which is built within Facebook. I am happy to even get here. :)
• beefsack 11y ago
  I'd be more interested to see a performance comparison with Mithril[1] rather than React, their core functionality is similar but Mitril strives to be lean and fast. [1] https://lhorie.github.io/mithril/ https://lhorie.github.io/mithril/
  • rattray 11y ago
    Agreed. Mithril's performance is incredible, and it's also closer to React in philosophy. That's the alternative I'd be looking at (perhaps along with Vue, which also goes unmentioned). EDIT: though, one difference is this supports server-side rendering out of the box, while Mithril requires a (tiny) third-party module: https://www.npmjs.com/package/mithril-node-render https://www.npmjs.com/package/mithril-node-render
    • lhorie 11y ago
      There's also another more ambitious Mithril isomorphism project called misojs https://github.com/jsguy/misojs https://github.com/jsguy/misojs Definitely worth looking into if you're looking for a full stack solution.
    • jatins 11y ago
      I wish Vue were more popular. It has one of the nicest APIs of all the JS frameworks and offers good performance.
  • keslag 11y ago
    Mithril's use of helper assisted javascript for it's view templating is a giant drawback for me. I'd be using it exclusively, but as an old crusty dev, I've gone down that path more than once, and it's always been a train wreck.
    • Meai 11y ago
      What do you mean by "helper assisted javascript"? Can you give an example where this has caused problems for you? I'm trying to decide between mithril and this library.
• lilkwarrior 11y ago
  It's unclear if the views are also leveraging Observables to asynchronous load views. Is so, are Observerables not unlike the ones of RxJS being used?
  • astoilkov 11y ago
    You could load views asynchronously. Observables could be compared to RxJS but they do not use it. They are inspired by Knockout observables.
• anonymoushn 11y ago
  What is it isomorphic to? How do I compute the isomorphism between this framework and some other thing?
  • axiak 11y ago
    In javascript frameworks, isomorphic usually refers to running the same code in the server (node.js) as well as the client.
  • aikah 11y ago
    > What is it isomorphic to? Don't bother, most people using this word in the context of javascript apps do not understand what it really means. It just has became a buzz word meaning :" you can render your views on client and on the server using JavaScript". IE you can render an HTML page representing the initial state of your app, then upgrade to an interactive application using JavaScript on the front-end seamlessly . You can't do that with angularjs 1.x for instance without some kind of heavy machinery relying on a headless browser. That's why angular 2.x basically ditches 1.x and is a completely different framework.
    • gclaramunt 11y ago
      To be fair, it comes from the same people who call node.js "close to the metal"
• Finbarr 11y ago
  Have you ever encountered a situation in the browser where 32k ops per second from underscorejs wasn't enough? How many rows/columns were in the table being repopulated? 10 times in 2400ms doesn't seem that bad - it's 240ms per refresh. Is this too slow for your use case? The 250ms gain on rendering 1500 rows - is this something you think needs to be optimized? I can't imagine a scenario where all of those rows would fit on the screen at once. I ask as the main area of focus for the framework seems to be speed, and I'm curious to know what inspired you to make it.
  • astoilkov 11y ago
    I agree. Performance is important because the lack of it creates problems. Additionally, with performance I want to showcase that you can rely on a framework that is built with care because it is hard to be compared with frameworks like React and Angular built from the two largest companies in the world. It needs skill for a single person to create such a framework.
  • mozumder 11y ago
    For me 240ms is very slow. I target 60fps for all operations, so that's 17ms. There's a very noticeable difference when you get to this level in performance. A project i'm working on went from 10000ms -> 500ms -> 60ms -> 15ms. Each phase opened up a new usability model.
  • vidarh 11y ago
    Consider that this is rarely going to be the only thing you want to do.
  • rythie 11y ago
    Even if 240ms was fast, is it still that fast on old iPad, budget Android phone or old computer?
• endymi0n 11y ago
  Impressive, but Vapor.JS is still orders of magnitude faster than both of them. https://github.com/madrobby/vapor.js/tree/master https://github.com/madrobby/vapor.js/tree/master
• galfarragem 11y ago
  Resuming: I know that we are still in the wild west but Javascript Land should start learning politics. Javascript Land tribes need to merge and get a larger population support, a small tribe even with fast weapons will never be more than a guerrilla. External support is also crutial (Angular, React and Typescript without Google, Facebook and Microsoft, respectively, wouldn't be nearly as strong. Even Meteor has external support: Horowitz). It completely saddens me watching little tribes as Elm, Purescript or Clojurescript struggling even with such a great weaponry. These little tribes should at least merge. Sometimes is too difficult but other times is just pride: their leaders want to remain as such. Stepping down a bit in the hierarchy doesn't seem acceptable for them, they prefer to be the leaders of the guerrilla till the end - because normally there is an end. Politics are boring and ugly but they work: just look at Meteor.
• onaclov2000 11y ago
  MY personal reason I like Angular (haven't had time to look into the others, sorry, but most I assume fit this bill) is that I don't need a server, I can put my application up on a static hosting site, and worry about what is happening in my controller/html/css/etc I like that approach. Putting a server that you now have to maintain is just one reason I wouldn't want to use it. I Love Firebase/Sendgrid/etc because I can write a client side only app exclusively, and let people who are good at databases,email,etc manage the back end. Is it a poor approach? Maybe, but when you only have an hour here and an hour there to build things, spending 6 months just setting up a few simple things seems crazy. Getting to a working application quickly for me is the goal. (I am not amazing with databases, so something like firebase gives me database with ease, and I don't have to figure out how to setup a server, figure out the database, figure out where to host... Same goes for email providers, etc)
• oabm 11y ago
  I'm just generally not a big fan of "X is some percent slower than Y" stats, because I find them counterintuitive. However, in this case I think something is wrong. Rendering: jsblocks: 700ms React: 950ms (35% slower) Angular: 2200ms (310% slower) Doing some maths: 700ms + (700ms * 0.35) = 945ms 700ms + (700ms * 3.10) = 2870ms Looks like they got a little carried away when calculating Angular's rendering speed. Same thing with the "Syncing Changes" stats. Edit: formatting
  • astoilkov 11y ago
    You are absolutely correct. It actually is an error. Thanks I will fix it.
    • deleted 11y ago
      [deleted]
    • Murkin 11y ago
      Also, please add 'track by $index' to the Angular example.. might be a suprise for you. (Makes Angular outperform both frameworks)
      • astoilkov 11y ago
        Are you sure you are getting correct results. Theoretically Angular can't be faster than both libraries because it does not implement diffing algorithm.
        • Murkin 11y ago
          You can try yourself, the samples are there. And it does, just not Virtual DOM
• keslag 11y ago
  Looks good, I look forward to playing with this. One note on site design of the API section, you have some dead zone sizes issues. The window can be larger than trigger to turn the api list into a hoverable sidebar, but too small to display the content. This causes the API definition to fall to the bottom of the page. I was clicking for a while, thinking it not working, before realizing that the content was at the bottom.
• smrtinsert 11y ago
  I wish js authors would stop baking functional apis into their libs and let the available contenders (ramda lodash underscore) do it for them. this reminds of the days when everyone published their own psuedo oo js lib. yuck.
  • astoilkov 11y ago
    I am actually considering removing the functional API. I agree lodash is better. It just doesn't make sense to use something that is not proven.
• norman784 11y ago
  Will be hard to compete with those big libraries like angular and react, b/c they have yet a large community, IMO I like angular on top of react (didn't like the way you create DOM with javascript, tried it 2 years ago, maybe it evolve but I doubt it). Also I'll wait till the project get more mature and get a significant community, b/c I'm not with the energy to learn every library that come out there, maybe will test with some small project but not with big projects, yet. Keep working on it, but try to make it more intuitive and easy to use (didn't read well the docs, but just seen it quickly). ;)
  • astoilkov 11y ago
    You are absolutely correct. It is hard to compete with Google and Facebook. Possibly impossible. I love what I do and it is great experience developing jsblocks. And one last thing you could check OneScript - https://github.com/astoilkov/OneScript https://github.com/astoilkov/OneScript. Do you think it is simple?
    • galfarragem 11y ago
      Why not joining Elm instead?
      • astoilkov 11y ago
        I believe that HTML, CSS, JavaScript should be combined the way they exist in the moment. Elm is too revolutionary for me. :)
      • norman784 11y ago
        do you think that Elm is in the good track? if you are involved with Elm, why I must using it? give me good reasons ;)
    • norman784 11y ago
      Its simple but got an issue, you need to hack your html. IMO the best approach will be the angular one, just add params to elements, so your designer that is brain less and only knows html can see your template after you put all the logic. An advice maybe will be try to get as much html friendly as you can, so ppl don't need to relearn / hack html. I only can give the point of view of someone that uses libraries, not developing libraries, so maybe there is some unknown reason to me for those approaches.
• alexmuro 11y ago
  Being a current react user the thing that I like the most about react is having my markup and my logic in one self contained file. React is fast, but that isn't what has me use it on all of my projects. React has toString() which makes isomorphic apps very easy to create but that isn't why I use it either. I use it because it constantly encourages maintainable solutions for user interfaces.
  • rickr 11y ago
    If you don't mind me asking - how do you manage that? Do you use inline CSS a la https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js?
    • alexmuro 11y ago
      My js and my markup live together but I still use seperate css. So maybe I was over stating my case but generally, I have a predefined set of styles that I am working from, which means I don't think about the styles too much, other than setting them using classes. I am definitely interested and excited for someone to make an excellent inline styles framework though, but I haven't found one yet. Currently for most of my projects I still use bootstrap (with a theme or something) and just include one compiled css file and bootstrap.js in my main index (everything else gets put together into one javascript file by browserify). I choose my markup with classes (className) and use bootstraps interactive pieces (accordians, modals, messages) with the markup data api. If you are really curious, here is a template app I often use to start from. (https://github.com/availabs/dashboardTemplate https://github.com/availabs/dashboardTemplate)
• tinganho 11y ago
  I'm not sure if an example beginning with an HTML file gives me good perception about it being isomorphic.
• warfangle 11y ago
  Why build in list traversal functions? Some people prefer lodash, some prefer underscore, others prefer VanillaJS. It seems like just a little sugar, but adding a sugar a little at a time gets addictive.
  • astoilkov 11y ago
    You are correct. I am thinking of removing the functional methods. It would be better to leave this battle to lodash and underscore.
• austinhyde 11y ago
  I'm surprised that no one's pointed this out yet, but isn't this basically the same as Knockout (http://knockoutjs.com/ http://knockoutjs.com/)? The difference being that Knockout's been around forever (first release was in 2010), does two things and does them well (data binding and observables), and is very mature and feature-complete at this point. I don't have any comparison performance-wise, but I don't see anything new and exciting feature-wise in JSBlocks that Knockout doesn't already do.
  • astoilkov 11y ago
    It is similar to Knockout. However, Knockout is hard to manage because you have to invent architecture on your own while jsblocks offers MVC out of the box. Additionally, Knockout don't have routing, server-side rendering, animations, filtering, sorting, paging, lazy loading of views, validation, working with remote data out of the box. Also the debugging experience is a cool feature - http://jsblocks.com/learn/introduction-why-jsblocks#debugging-experience http://jsblocks.com/learn/introduction-why-jsblocks#debuggin....
• Murkin 11y ago
  The speed comparison is sadly incorrect: Adding 'track by $index' to the Angular example makes it run 10x faster (outperforming both React and Blocks).
  • astoilkov 11y ago
    Are you sure you are getting correct results. Theoretically Angular can't be faster than both libraries because it does not implement something like diffing.
    • Murkin 11y ago
      Yes, you can easily test it - the code they used is in a link on the site.
• blairanderson 11y ago
  DBmonster or it didn't happen
• tbolt 11y ago
  Might want to tighten up the spelling and grammar http://jsblocks.com/learn/introduction-why-jsblocks http://jsblocks.com/learn/introduction-why-jsblocks
• swah 11y ago
  To demonstrate speed, don't use a very slow CSS transition property...
  • astoilkov 11y ago
    You mean the animations demo? This is to showcase how to work with animations to speed. CSS3 Transitions/Animations have the same performance regardless of the framework.
    • jonahx 11y ago
      I think he's just saying you should have used a lower transition time, like 100 or 200ms. It has to do with nothing more than the impression it makes on the user. It's "illogical" but if one of your examples uses a slow CSS transition then the framework "feels" slower, even though the two things have nothing to do with each other.
• jellofiend84 11y ago
  Maybe I'm in the minority but after drinking the React 1-way data flow kool-aid I love it. I can think more logically about what a components state is and I can test for that state very easily. IMHO 2-way data bindings are not a feature anymore they are firmly on the cons list for me.
• franzwong 11y ago
  It'd be better to explain more on why it is faster. It's more convincing. I was a Knockout user, but 2 way binding and mixing up logic with html made me choose React. I think the target audience of this framework should be AngularJs user.
• joesb 11y ago
  data-query="val(...)" data-query="css(...)" data-query="click(...)" data-query="each(...)" ... Really? Are you aiming for single god function? "It makes so much sense to query a click!!" said no one ever.
• up_and_up 11y ago
  > I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it. My rule is to ignore pretty much anything and everything until either: 1. A year goes by and it seems like it is gaining traction. 2. certain key people that I know personally and respect also start talking about it etc.
• dwg 11y ago
  The title of this post "faster than React" is misguided. React is fast. Most libraries and frameworks have to be fast to be widely adopted. But speed is not, in my opinion, one of the main reasons to use React. I use React professionally. I choose React because of maintainable the resulting code is. There are other libraries/frameworks that I could use which are faster than React. I choose not to because, having used several of them, I found the code produced comparatively more difficult to understand and maintain in the long run. I'm sure jsblocks is awesome and some people will love it. I haven't tried it yet but perhaps I will someday. Nonetheless I think calling it faster than react, while perhaps true, will be misleading to some.
• tracker1 11y ago
  While I think this is relatively cool, I'd be somewhat more interested to see how it compares to knockout. Beyond that, none of the demos give any indication as to how one would create discrete components or modules, it seems like you'd wind up with some fairly difficult to manage code on a larger project. React and related tools just feel more right to me... that or going more towards Polymer... There are several alternatives, and in practice, how many times are you going to change all 10k rows in a table 10 times? I'll lean towards more manageable code in this case. We aren't talking the performance drop to say Angular 1.x, or other frameworks that work directly against the DOM. Of course most people don't need absolute performance in a web based application. To me React with something similar to Flux just makes the most sense... I think Flummox brings it to a nice circle, that's easy enough to reason about.