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.
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.
> I am however feeling so overexposed to new libraries and frameworks that I can hardly muster the energy to even look at it.
That's the nature of the job. In the front-end new frameworks are born all the time, new apis are created, new paradigms are "invented". Coming up with the "perfect" framework is clearly a work in progress.
Here is a list of the techs I had to learn and work with during my career :
- flex
- jquery
- extjs
- backbonejs
- angularjs 1.x
- Reactjs
- angularjs 2.X
And i'm only talking about "view frameworks" here. Not even about the crazy js pipelines involving build tools, running on nodejs , 3 different CSS pre- processors , ...
And in 1 year i'm pretty sure i'll have to work with yet another new framework because managers think framework Z isn't cool enough anymore.
Again that's the nature of the job,because front-end techs are evolving. Everybody was praising backbone 3/4 years ago. Then everybody was praising Angular then everybody is praising React as the new hot stuff.
In the front end, either you keep on learning new stuff, or you're out of job.
Those who believe they have "job security"(as I read in this thread) because they chose angular are lying to them self.
Being a front-end developer means having to learn a shit tons of libraries , techs and apis everyday. You can't just tell yourself , "I'll learn X and i'll be all set" like with server-side techs.
Yet today the biggest challenge isn't even choosing a framework, but more like choosing how to transition from ES5 to ES6. Because the tools aren't ready.
> 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.
Every two weeks? Try every day. I hate to be that guy, but this sounds like whining. You're a developer, it's an incredible privilege (we're part of one of the fastest-growing, most-successful businesses ever, and we basically get paid to solve puzzles by writing machines directly from our minds and in most dev shops I've worked in nobody cares if you roll in at 10am, not to mention that we get compensated quite well while arguably becoming ultimately smarter than doctors yet without any required certification or schooling... I mean, in the history of human jobs, I can't imagine it getting much better!!), and staying on top of new developments is part of our job description. If you're getting fatigued, perhaps it's time to take that vacation you've been putting off, or to (wo)man-up and ask your superiors for more. Or to ask yourself if this is the right career path for you (although there's so much work now that you can get by just fine even relying on decades-old technology/libraries/languages). OR... to specialize. The full-stack developer's days are unfortunately numbered, there's no way a full-stack developer can keep up with every new development while keeping his job anymore. I myself gave up on keeping up with frontend around the time Angular came out...
I understand you very well. My todo list called 'stuff to check out' grows so fast that sometimes I'm thinking about clearing it out and just start another one.
Geography. The replies I've read, as they so often do, ignore geography. SV might move rapidly from one to the next, but the city I'm in is more conservative and moves slower, so all I've ever seen much of from recruiters are jquery, knockout, angular. SV is the gladiatorial arena, and only the survivors make it through the filters to elsewhere, so elsewhere has fewer to deal with. If you engage with SV news while living elsewhere you'll still be trying to keep up, but if you hang back, things are a bit more laid back. Or, make the decision to ignore every other tech. If the next one is along shortly, you'll not likely miss much.
Which is the reason, it is an appropriate time to back and stay with React for the long term.
React has so many technical benefits that is all covered through so many posts - That declarative is better, Fast DOM manipulation with Virtual DOM is nice and a great development API and syntax sugar with JSX is wonderful.
Having said all of that, I think what seals the deal in favour of React is that it is being used by Facebook on their homepage for half a decade and in all likely hood going to be continued to, which means you're assured of incremental upgrades and regularly maintained and yet no radical shifts, which would warrant a large change for your product.
I think Facebook has hit the abstraction level perfectly with "Product Engineering" and "Library Development" or "Infrastructure Development". This abstraction may not work well for all use cases. But for a large audience this is what is needed and where it is needed, it fits in perfectly.
Take a look at Mithril. People are frequently surprised by its small learning curve (and for many, the majority of the learning is for knowledge that you can go and apply outside of Mithril)
If you already found good tools and happy with these - stick to it. If you are still looking - I find description on the site is pretty clear about idea behind approach, which made me quickly do proper decision to learn it/skip it this time.
I feel what you're saying. With regards to this and similar projects, I think the important thing is to be familiar with reactive programming. To me, it was an eye-opening new paradigm to develop in.
Man, a few hours ago I was debating with some team mates about js frameworks. In the middle of this ocean of frameworks I keep going with ExtJS. And I'm very criticized about this. And today the discussion is as always - that it's a monster and I need try ember ou angular etc etc... But I keep using ExtJs happily focusing in my business and almost never worrying about why something not work and wondering how to use new new coolest javascript/css/html thing - I almost never touch html and css since I begin to use ExtJS. I'm happy and it's working.
Instead of learning a new framework, try learning a new paradigm. You can then apply that knowledge in whatever new shiny tool your boss want you to use to build the next big thing.
This is seriously one reason I've been looking at career-switching to being a machinist. A new technology can come along, but it has to establish itself, and then you can take time and get really proficient at it.
That, plus the more grey hairs a machinist has, the more they're respected (usually).
That's exactly how I feel about every new js framework popping out from nowhere.
But I accidentally clicked on the title. The site looks cool and guess what, a framework which is faster that React and doesn't make you put xml in js.
And it grabbed my attention. I don't know whether I'll ever use it but it will be on my radar for sure. Especially if they don't lie about how fast it is.
I'm sure some scientist said the same thing about some early stage germ of a discovery once upon a time. But it's true, we still get very far along with Newtonian physics, we don't need a full working knowledge of quantum mechanics to get our jobs done day-to-day. Not that what we're doing is anything comparable, but maybe the analogy fits somewhat.
-) is a sign of an area or areas of still not recognized core problems leading to tackling it from different angles
-) it could be connected to the average age of developers in the field responsible for the choice of their tools. They will settle for something with time ... eventually ;)
-) bears resemblance with an earlier me, eager to find the latest, newest and most importantly most different way to ... well, what actually? Most probably traverse the unknown landscapes of new, landscapes of "my way"
-) is worst than it used to be, as the _really_ old ppl say ;) ... or I changed the sides, moved on on this spectrum of professional attention deficit hyperactivity disorder.
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.
100% agreed. Working now on angular app at work (not my choice) I see state flying everywhere which will inevitably lead to something awful. The argument to push it back into a main controller and let it flow downward only seems completely unrealistic if not impossible and the api certainly doesn't encourage it at all.
Meanwhile in Clojurescript I have undo functionality without thinking about it - mind blowing because it's something I never expected to see in a web app without much pain.
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
I'm surprised that no one's pointed this out yet, but isn't this basically the same as Knockout (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.
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.
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.
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), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
[+] [-] yummybear|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] aikah|10 years ago|reply
That's the nature of the job. In the front-end new frameworks are born all the time, new apis are created, new paradigms are "invented". Coming up with the "perfect" framework is clearly a work in progress.
Here is a list of the techs I had to learn and work with during my career :
- flex
- jquery
- extjs
- backbonejs
- angularjs 1.x
- Reactjs
- angularjs 2.X
And i'm only talking about "view frameworks" here. Not even about the crazy js pipelines involving build tools, running on nodejs , 3 different CSS pre- processors , ...
And in 1 year i'm pretty sure i'll have to work with yet another new framework because managers think framework Z isn't cool enough anymore.
Again that's the nature of the job,because front-end techs are evolving. Everybody was praising backbone 3/4 years ago. Then everybody was praising Angular then everybody is praising React as the new hot stuff.
In the front end, either you keep on learning new stuff, or you're out of job.
Those who believe they have "job security"(as I read in this thread) because they chose angular are lying to them self.
Being a front-end developer means having to learn a shit tons of libraries , techs and apis everyday. You can't just tell yourself , "I'll learn X and i'll be all set" like with server-side techs.
Yet today the biggest challenge isn't even choosing a framework, but more like choosing how to transition from ES5 to ES6. Because the tools aren't ready.
[+] [-] lectrick|10 years ago|reply
Every two weeks? Try every day. I hate to be that guy, but this sounds like whining. You're a developer, it's an incredible privilege (we're part of one of the fastest-growing, most-successful businesses ever, and we basically get paid to solve puzzles by writing machines directly from our minds and in most dev shops I've worked in nobody cares if you roll in at 10am, not to mention that we get compensated quite well while arguably becoming ultimately smarter than doctors yet without any required certification or schooling... I mean, in the history of human jobs, I can't imagine it getting much better!!), and staying on top of new developments is part of our job description. If you're getting fatigued, perhaps it's time to take that vacation you've been putting off, or to (wo)man-up and ask your superiors for more. Or to ask yourself if this is the right career path for you (although there's so much work now that you can get by just fine even relying on decades-old technology/libraries/languages). OR... to specialize. The full-stack developer's days are unfortunately numbered, there's no way a full-stack developer can keep up with every new development while keeping his job anymore. I myself gave up on keeping up with frontend around the time Angular came out...
[+] [-] gothy|10 years ago|reply
[+] [-] hnrem|10 years ago|reply
[+] [-] scorpion032|10 years ago|reply
React has so many technical benefits that is all covered through so many posts - That declarative is better, Fast DOM manipulation with Virtual DOM is nice and a great development API and syntax sugar with JSX is wonderful.
Having said all of that, I think what seals the deal in favour of React is that it is being used by Facebook on their homepage for half a decade and in all likely hood going to be continued to, which means you're assured of incremental upgrades and regularly maintained and yet no radical shifts, which would warrant a large change for your product.
I think Facebook has hit the abstraction level perfectly with "Product Engineering" and "Library Development" or "Infrastructure Development". This abstraction may not work well for all use cases. But for a large audience this is what is needed and where it is needed, it fits in perfectly.
[+] [-] lhorie|10 years ago|reply
[+] [-] hippich|10 years ago|reply
[+] [-] daenz|10 years ago|reply
[+] [-] rhapsodyv|10 years ago|reply
[+] [-] z3t4|10 years ago|reply
[+] [-] hoprocker|10 years ago|reply
That, plus the more grey hairs a machinist has, the more they're respected (usually).
[+] [-] smanuel|10 years ago|reply
That's exactly how I feel about every new js framework popping out from nowhere.
But I accidentally clicked on the title. The site looks cool and guess what, a framework which is faster that React and doesn't make you put xml in js.
And it grabbed my attention. I don't know whether I'll ever use it but it will be on my radar for sure. Especially if they don't lie about how fast it is.
[+] [-] ryan-allen|10 years ago|reply
[+] [-] pointernil|10 years ago|reply
To me this
-) is a sign of an area or areas of still not recognized core problems leading to tackling it from different angles
-) it could be connected to the average age of developers in the field responsible for the choice of their tools. They will settle for something with time ... eventually ;)
-) bears resemblance with an earlier me, eager to find the latest, newest and most importantly most different way to ... well, what actually? Most probably traverse the unknown landscapes of new, landscapes of "my way"
-) is worst than it used to be, as the _really_ old ppl say ;) ... or I changed the sides, moved on on this spectrum of professional attention deficit hyperactivity disorder.
[+] [-] mambodog|10 years ago|reply
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.
[+] [-] smrtinsert|10 years ago|reply
Meanwhile in Clojurescript I have undo functionality without thinking about it - mind blowing because it's something I never expected to see in a web app without much pain.
[+] [-] idibidiart|10 years ago|reply
[+] [-] gcb0|10 years ago|reply
it's completely opaque on how it decides to re render the dom. unless you only have react code there, it's completely dark magic for other code
[+] [-] snarfy|10 years ago|reply
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.
[+] [-] dkersten|10 years ago|reply
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
[2] https://github.com/cgrand/enliven
[+] [-] talles|10 years ago|reply
[+] [-] nahiluhmot|10 years ago|reply
[+] [-] nashashmi|10 years ago|reply
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|10 years ago|reply
[+] [-] aikah|10 years ago|reply
> 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.
[+] [-] bananaoomarang|10 years ago|reply
[+] [-] bshimmin|10 years ago|reply
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|10 years ago|reply
Compare to the launch of Mithril: 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).
[+] [-] anshin|10 years ago|reply
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.
[+] [-] austinhyde|10 years ago|reply
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.
[+] [-] ttty|10 years ago|reply
[+] [-] beefsack|10 years ago|reply
[1] https://lhorie.github.io/mithril/
[+] [-] k__|10 years ago|reply
Mess yourself with Mithril, Mercury or Elm.
[+] [-] ndreckshage|10 years ago|reply
If you really want a framework that is faster, check out Tungsten (https://github.com/wayfair/tungstenjs), which is as fast as this client side, and can render in vanilla Mustache using Go/C++.
[+] [-] alexmuro|10 years ago|reply
[+] [-] emehrkay|10 years ago|reply
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.
[+] [-] pothibo|10 years ago|reply
[+] [-] rattray|10 years ago|reply
[+] [-] andrewstuart|10 years ago|reply
[+] [-] anonymoushn|10 years ago|reply
[+] [-] Finbarr|10 years ago|reply
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.
[+] [-] mozumder|10 years ago|reply
A project i'm working on went from 10000ms -> 500ms -> 60ms -> 15ms. Each phase opened up a new usability model.
[+] [-] astoilkov|10 years ago|reply
[+] [-] vidarh|10 years ago|reply
[+] [-] rythie|10 years ago|reply
[+] [-] ojr|10 years ago|reply
http://cdixon.org/2014/04/07/the-decline-of-the-mobile-web/
[+] [-] keslag|10 years ago|reply
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.
[+] [-] tracker1|10 years ago|reply
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.