Show HN: An Isomorphic JavaScript Framework Faster Than React
jsblocks.com
jsblocks.com
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.
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.
What's in fashion isn't what the recruiters are talking about, but what the developers are talking about. Recruiters will always lag a bit behind whats actually in fashion.
Employers seem to be influenced by what the developers push (maybe not short term, but longer term it seems to me to be that way). Recruiters go where the employers are. Therefore, IMHO, ultimately its the (vocal) developers who pick the fashion.
It's just like when your parents start listening to your (former) favorite musician.
* a tribe
* a close-knit group
* an industry union
You do not assign blame to hundreds of thousands of professionals, who live in different parts of the world, speak different languages and work on different projects.
The web evolves without intelligent design or regard of your personal interests. Deal with it or withdraw in denial to the perfect land of perfect web technologies.
I do, primarily because it's yet another attempt in a long history of misguided attempts to bestow Turing completeness on XML.
If Angular has produced a local optima of efficiency in the range of "misguided attempts" then it's effect on the development ecosystem was a net positive.
That said, I am extremely concerned that most popular frameworks/libraries are products of megacorps.
I think a more important reason would be that Facebook/Microsoft/Google media influence and corporate support creates massive brand awareness and generates instant interest. Educational projects anticipate the interest from developers and create courses, tutorials and reviews. The cycle continues and bam! we have an information cascade[0].
Rich get richer and poorer get poorer (in developer mindshare). Megacorps reap the benefits while indie developers are not able to achieve critical mass.
I shudder when I think about the possible Typescript/Microsoft, Angular/Google, React/Facebook domination in web technologies.
- Polling for changes vs. event driven - two way data bindings causing infinite redraw loops. - "feels like O(n^2)" performance on ng-repeats / large pages
but things like the templating, directives, data-binding... they are all really good things.
And dependency injection! They have really moved the needle forward on client side testing.
No angular in itself is not a mistake at all. There are mistakes without question. I suspect the angular 2.0 release will address many of the major criticisms. Though, I haven't read much about it yet.
Why do you even need dependency injection and singleton services and factories in a dynamic language with closures and first-class functions? You don't. Client-side testing works fine without DI. Angular is just a way to do Java in JavaScript. It's a pile of unnecessary complexity designed to sell to enterprises that love over-designed Java projects and want to make client-side development feel more similar to what they know. In that regard I suppose Angular is a little better than Google Web Toolkit, but that isn't saying much.
It's nice to have a largely declarative way to specify markup but still allow simple loops and conditionals.
Hasn't every template language in the world has come to a similar conclusion?
No, not even every mainstream template language. For example, I still use ERB and EJS extensively, and so do many other engineers. ERB and EJS use the control flow constructs of the underlying languages (Ruby and JS, respectively).
There is of course debate about whether templates should expose the full power of a programming language. I have tried templating languages that do and ones that don't. For now, I'm sticking with templates that let me mix in arbitrary code as I see fit. Could I abuse that power and make a mess? Absolutely. But I try not to, and my code stays pretty maintainable.
Now all those companies are bogged down by Angular, but feel like ejecting it would be too costly. Elsewhere, lots of new developers are introduced to Angular and invest time and effort into learning it because they don't know any better.
Herd mentality is a big problem. It's basically the polar opposite of thinking for yourself, and as such, extremely detrimental in other aspects too.
The most ironic thing in all this is that your comment is still full of Herd mentality, except that it goes the other way.
Angular is a framework, period. Using it is neither a good or a bad idea, it all depends on the people who actually use it.
Honestly, if/when browsers have better support, I think something closer to Polymer may be the best of all worlds with web development... for now, I find that React code tends to be the most sensible (with a decent framework around it)... not to mention shared client-server code with node/io.js
I don't care about the turing completeness of angular.
> * a tribe
> * a close-knit group
> * an industry union
unfourtunately
https://snowdrift.coop <-- this is a great example, btw
Modularity and code re-use are like apple pie and motherhood. The real question is, do you need dependency injection and the factory pattern to get those things? In JavaScript, the answer is no you don't, because you have closures and first-class functions. Patterns like DI and Factory were invented to compensate for the deficiencies of Java, they are superfluous in JavaScript.
Even in those platforms (.Net and Java) unit testing is such a miserable experience, and adds so much complexity it's easier to just skip unit testing in favor of simpler classes/methods and better integration tests.
Love, Past Me.
I managed to write a multi-page response explaining how the modern frameworks were moving away from jquery in favour of data bindings, virtual dom, etc... while I acknowledge that there is still a place for jQuery, it has a very much diminished role in modern web development.
In the end, I never sent the email in response. While it was cathartic to write, I really didn't want to come across as "sour grapes". (and truth be told, I respected their decision... I'd feel a better fit in a more technology forward environment, their reliance on "old faithful" technologies can still make money)
I feel like even angular has come-and-gone as a framework the 1.x just isn't performant on busy pages. Anything with a log of ng-repeats gets out of hand. Though I suppose that could also mean that I'm writing bad pages too.
My most recent favorite is Leo Horie's https://lhorie.github.io/mithril/ We've got some of that running in production and it really is beautiful to work with.
I'd like to try REACT, but haven't found the right project for it yet.
I've sortof started rambling here... my point was I share your experience with employers looking for "old" tech.
I think the reason I want to try react is to compare and contrast the various approaches.
I've written both angular & mithril for production. So far I haven't enjoyed anything as much as mithril. It is so clean & pure. It stays almost completely out of your way.
In fact there are places where I'm actually running angular INSIDE mithril pages (long story, part of migrating a project from angular to mithril, without losing legacy pages)
I would like to start a react project from scratch to see what it's like. To compare what one really, really smart guy (Leo) came up with against the mighty multibillion dollar facebook.
Leo has a day job and mithril is spare-time, facebook has a staff dedicated to react. Facebook is committed to working on react long term as a corporate strategy. Leo could get bored and walk away.
Additionally there's the aspect of looking at react-native. It makes me suspect that there may be a long term value in being aware of the patterns used in the react.
I struggle to believe it could be better than mithril, but who knows? I haven't tried it yet!
Finally there's the "learning things is fun" side of things.
But what if you're in a Starbucks, and the person behind you is the head of BMA Model's hands and feet division? (http://www.bmamodels.com/hands_legs_feet). As you reach for your frappachino you're "discovered" as the next-big-thing. About to explode into the glamorous, yet high stakes world of hand-modelling. It's a multi million dollar deal... but with the stipulation... no more coding effective immediately.
What happens to mithril then Leo? What then?
If it happened at facebook they'd give the job to Jimmy "Stubby Fingers" Malone and move on.
Obviously I'm teasing (hopefully at least).
I think there are actually a lot of advantages to your running mithril lean & (mostly) solo.
I've been impressed by seeing the contributors in github https://github.com/lhorie/mithril.js/issues and the quality of the discussions in the google group https://groups.google.com/forum/#!forum/mithriljs ... to say nothing of how great your blog posts are.
You contribute and participate in all those places and even turn up on HN.
It does make it a consideration when selecting a direction for a project though. It's a bit of a risk awareness/tolerance thing. I still think C# is way better than node.js for some things too :)
=)
For learning, what you really want is a small set of new concepts to learn that easily map to things you are already familiar with, good documentation to refer to, and a active community that can answer your questions within a couple of minutes. That's why I mentioned Mithril.
I'd be quite keen to look at either refactoring to use mithril or react, so will check you blog post - thanks!
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...
Family and kids are, by any measure, a huge time and energy sink. But that too is also important work that must be done, even if it has professional costs.
The guys writing these new things, more often than not, don't have a family and kids and do have all that extra time. If you have committed to a family and kids, then join a shop where family people work and be content to use yesterday's stuff to get work done, it will still work fine for the most part. You don't have to keep up with everything, perhaps just general trends. Just watch out for that gentle slide into irrelevancy. ;)
I would argue that wasting time learning the JS "framework of the day" is not the best approach to stay relevant. Learn the logic and math behind programming and you can watch the industry slowly catch up...
I was recently at a jobs fair and spoke to a lot of companies and everyone (apart from one) were saying they wanted developers who had the core fundamentals and could learn any framework or language (the latter obviously takes longer but not much longer). So they weren't putting an emphasis on having to know the latest frameworks even if they were using them, but instead looking for people with knowledge of core concepts.
Or woman-up, right?
For the record, I changed it to (wo)man-up.
None of the productive developers I know care about all the daily/weekly noise, if something is truly new and good it'll become known on a monthly or quarterly scale.
And about job description - developers are hired to build functionality, not learn new things. It might help further your personal goals and eventually help provide functionality faster/better using new tools but at the end of the day, the business doesn't care and would rather have something that works. Don't get caught up in the hype. It's great that you seem so passionate about it but keep in mind what the work is really about.
True, but unless you own the business, the business' goals are not your goals. The business wants a working product; you need to stay relevant in a career. Sometimes these may align, but not always.
When I hire devs, I base their relevancy on what functionality and results they produced for their employer/project, not how new their tech stack was.
Go ahead and learn new stuff but if you know the fundamentals, the frameworks are just different syntaxes for the same thing. But don't assume that someone who doesnt keep up with things every day or week is somehow irrelevant. These frameworks won't change your productivity that much and your output is what matters.
I imagine most here have day jobs with projects that last more than a few months so I doubt the need to learn things faster than your cycles of your job.
Yeah. No wonder people figure out that it is not the right career path for them when people will jump on them for admitting any kind of "programmer weakness"[1], or for not being perfectly passionate about programming all the time, or for not thanking their boss for having the privilege of getting their generous pay-check and almost salivating at getting more overtime to work on the companies' interesting problems.
Sometime the work itself might not be as bad as the people you have to do it with.
[1] In their minds.
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 think it's good that there is so much fervour around it. Time and use will flush out the things that don't work and we'll be left with the bits that do (well mostly)
You can be a Java developer on hibernate the same way you can be a frontend dev doing jquery for almost a decade but being on the cutting edge is the same deal on frontend as it is backend.
Things are always changing but that's the beauty of it, isn't it?
A year ago they weren't even asking for angular.
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.
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.
That, plus the more grey hairs a machinist has, the more they're respected (usually).
That said, I think that ExtJS's UI is starting to look a little long in the tooth, but it's still usable. I really never liked it... class based hierarchies in JS always seemed like a waste to me.
That said, if that's your path, there are still some newer tools (namely node+babeljs) that can greatly improve your development experience... I think the module and class syntax from es6 would be a boon for you, along with being able to use es7 async/await combined with a fetch shim...
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.
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.
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?
(disclosure: I am the author)
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.
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
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).
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.
> 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.
<div data-query="each(products)"> ... </div>
products.map(product => React.createElement('div', null, ... ))
products.map(product => <div> ... </div>)
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.
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.
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).
Another one: the general weariness with which new JS frameworks are greeted has increased massively in the 433 days since Mithril was posted here.
make the "upvote" buttons invisible on stories that the user hasn't visited before. This could be done like so:
// css
a.upvote-botton:visited { visibility: hidden };
<!-- in html -->
<a href="{article_link}" onclick="perform_upvote()" class="upvote-button">upvote triangle</a>
http://dbaron.org/mozilla/visited-privacy is one of the better resources explaining the issue more fully.
I guess you could create the triangle solely with CSS borders, and then style the border-color to be the same color as the background when not :visited
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.
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.
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.
Apparently, what makes jsblocks different is that it appears to be doing dynamic code generation. That's an interesting idea, though I'd have concerns about how it respects lexical scoping. There are a couple bumps apparent as well:
- the benchmark is only faster because it ends in a .reduce(). I suspect that code generation allows them to remove all collection generation here and just update the reduced value in a loop. If you remove the reduction at the end, then lodash is fastest, as expected.
- the jsblocks code in their own benchmark reports the wrong result. It appears there's either an off-by-one error or the generated code runs the filter step before the map. I'm not counting this against the method, as presumably it's fixable, but it might speak to the difficulty of code generation as a strategy.
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.
Also the debugging experience is a cool feature - http://jsblocks.com/learn/introduction-why-jsblocks#debuggin....
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
Definitely worth looking into if you're looking for a full stack solution.
todo.view = function() {
return m("html", [
m("body", [
m("input"),
m("button", "Add"),
m("table", [
m("tr", [
m("td", [
m("input[type=checkbox]")
]),
m("td", "task description"),
])
])
])
]);
};It works as advertised :-)
{
"jsxPragma": "m"
}Mess yourself with Mithril, Mercury or Elm.
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++.
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)
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.
This looks cool, keep it up
<div> { this.each(profiles);
<!-- Render all profiles -->
<Profile> <!-- render personal profile -->
My profile.
<Profile>
}Agreed - encapsulation is key to managing complexity.
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.
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.
A project i'm working on went from 10000ms -> 500ms -> 60ms -> 15ms. Each phase opened up a new usability model.
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.
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.
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.
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.
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). ;)
And one last thing you could check OneScript - https://github.com/astoilkov/OneScript. Do you think it is simple?
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.
It also packs things like routing and animation integration which React lacks out of the box.
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.
No. Just no.
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?
[1]: https://medium.com/the-thinkmill/making-the-case-for-progres...
Thanks for the link, good to know people are thinking about the naming issues.
Rendering:
jsblocks: 700ms
React: 950ms (35% slower)
Angular: 2200ms (310% slower)
700ms + (700ms * 0.35) = 945ms
700ms + (700ms * 3.10) = 2870ms
Edit: formatting
(Makes Angular outperform both frameworks)
And it does, just not Virtual DOM
Adding 'track by $index' to the Angular example makes it run 10x faster (outperforming both React and Blocks).
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.
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.
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.
However, depending on your needs, a stream of changes may behave differently in different use cases... to me React simply represents in my mind a better way to manage components and rendering logic, combined with something like flux for data and event flows.
this reminds of the days when everyone published their own psuedo oo js lib. yuck.
... Really? Are you aiming for single god function?
"It makes so much sense to query a click!!" said no one ever.
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.
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.
Seriously though, it's a non-problem now. There is no way I'd go back to anything else. Webpack and browserify are the only way to go. </religion>
Yes, there is a certain purism to doing your own modules and IIFEs and JS, but it's like claiming that code is only fast when it's asm. </realcoders>
Besides it can all be optimised out if you add the closure compiler plus relevant comments </nobodyactuallydoesthat>
A base set of packages, for your external functionality, your core (shared functionality) and the rest makes a lot of sense, and isn't that hard to do. In the end it's pretty easy to reason about, and with sourcemaps and better build tools it's easy to use. Though having to have a watcher or build process when JS changes takes some getting used to... if you're used to compiling server code, it really isn't bad...
I consider them somewhat fluffy and learn just to say nice job and move on.
* JS is possibly the largest programming language community in the world
* There are a lot of shortcomings in "the web platform" for app-style development
* Most JS developers are primarily developers in another language with a stronger culture and set of ideas/idioms
It's basically the cambrian explosion.
Do a search of https://npmjs.com/ for a framework you want a synonym to, and you will probably find it.
For me, some tools simple ring better in the JS way than others... if it's too cobbled, and relies on strange markup behaviors I like it less. If it's really class centric I tend to like it less, though ES7 classes and React isn't too bad. It just depends on your likes.
I really don't like seeing certain patterns in JS (factories and di/ioc) as they simply aren't needed and only add complexity.
BTW, If you want to see what that combination looks like in a more suited language then look towards ClojureScript or Elm.
It definitely did with django, pylons, flask, turbogears, web2py, . . . I didn't know which way to turn.
PHP had the same thing with cakePHP, symphony, drupal, and so forth. I remember rolling my own using smarty long ago, because I couldn't decide.
Chrome 43.0.2357.65 on OS X 10.10.0