At the risk of beating a dead horse, we are only fueling the flames of javascript fatigue by churning out these "It's like X, but with more/less cowbell" libraries. We need to stop fragmenting and start doubling down on existing libraries.
> we are only fueling the flames of javascript fatigue
The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery. If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do. If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.
It took me all of 30 seconds to skim the home page and to conclude "hmm, I don't need this now", but I've filed it at the back of my mind should I require it some day (I might not remember the name then, but I'll be able to figure out the search keywords).
> We need to stop fragmenting and start doubling down on existing libraries.
I reject this sentiment. You can't force people to contribute to projects they have no passion for. You also can't prevent people from scratching their own itch and registering a domain for their slightly different flavor-of-the-week JS project. Best you can do is ignore them or support them. The undeserving will wither eventually, you do not owe any project your attention.
>The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery.
You'd be surprised.
In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling.
>If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do.
You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough.
Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.). In Python or Ruby I could still use the Rails and Django I learned in 2006 -- not so much with JS.
>If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.
Only people have (cereal fatigue). Too much choice leads to fatigue and stress in itself -- and this is backed by science...
> You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough
Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype. Best practices for who? Facebook's "best practices" might not work for you. You can't blame external circumstances for your technology churn, especially if the "dead-end" technologies are still actively maintained. "Best practices" are just design by committee writ large. I still use Grunt rather than Gulp, for me the 'improvemements' are marginal. I still support a Dojo SPA even though it's considered ancient. These technology decisions are not considered best practices, but they work for me. The buck stops with you (or whoever makes tech decisions at your org) - you can't pass the blame to the larger JavaScript community.
My point is you can safely ignore the latest and greatest (or 'best practice' as you call it). Apply common sense and only use what you need.
Speaking of hype: aren't containerized Flask-based microservices the current 'best practice' rather than monstrous Django apps? Looks like your 2006-era technology won't cut it on the back end either - it's all about scalability now ;)
Edit: added text below this line
> Too much choice leads to fatigue and stress in itself -- and this is backed by science
This is not inherently bad in any way: it's a trade-off. The paradox of Choice states that choice decreases (present) happiness. If this is what you are optimizing for, then less choice is good. Unfortunately, large and complex systems are...complex and multifaceted. I'm willing to sacrifice a little happiness in the present for ease of maintainability (when choosing a library that better fits my needs). Nature itself seems to celebrate choice when it comes to genetics in sexually reproducing organisms. Diversity has it's benefits -- and this is also backed by science.
> Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.).
And yet you can use any/all of those as desired, still - Backbone's still chugging along, being a mature framework at this point - Angular still has a huge community - Ember definitely still exists, and I'm starting a project using it.
What you're possibly missing out on is hacky "components" and "integrations" with whatever CSS framework, protocol or SaaS service is popular this week - but all of them have pure javascript versions which you can use just fine in any framework you want.
The only reason you should be forced to use the bleeding edge is if your customer/VC demands it.
Rails and Django are back-end; a good analogy there would have been Node.js which, as a framework, has done little but expand its API, implement ES6 features, and improve performance.
Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?
>Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?*
There's nothing "silly" about it. If anything, this arbitrary distinction is silly.
It's still all frameworks.
Whether they are front-end or back-end doesn't matter one iota to whether they could (or should) be stable.
There's nothing about "diffing DOM elements" (or any other thing front-end frameworks do) that necessitates tons of new and redesigned frameworks each going about it in its own way. In fact it could be retrofitted to an existing framework with care for backwards compatibility -- if only more JS frameworks were like Ember.
It's not a matter of some inherently technical concerns making the backend more stable. It's just the JS community churning out new frameworks and redesigned stuff all the time (because it's easy, and because they're many more millions that Python or Ruby programmers).
It's not even JS getting more features with ES6/7 (Python got tons of new features and syntax since early Django but you still don't get the same framework churn. Heck, Django even works with 3 -- and all only with tiny incremental changes to the same framework over many releases).
Yes, and even within a framework... investing in using for example React for a project and some plugs, come back to project a couple of months later to add some library for let's say graphs, and face need to upgrade every lib/plug and lots of version mismatches. Not all libraries you opted to use might be compatible with new version of React.
Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult.
Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks.
Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.
I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure.
I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar.
I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push).
I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.
It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Concat & minify is still there like it always was (what tools you use to get this done is really irrelevant). You don't need to use Node, NPM, webpack, rollup, babel/buble or classes because today that means you're obligated to use all the tooling and compilation. Not to say that these things dont add value, but the value is greatly overhyped for projects that are not Facebook or Google sized. Virtual dom, Promises, rAF, Canvas, CSS3, new web APIs are definitely worth learning because they provide huge value and will be around for a long time. There has certainly been a shift towards declarative/functional/immutable paradigms in JS but that doesnt mean it works better for all cases.
Might as well do a shameless plug here. If you don't want to learn the current hotness-of-the-month. I've written domvm [1] to be small, fast, fully free from dependencies and build/tooling requirements. It uses virtual dom concepts under the hood, so you get the benefits of both declarative templates and imperative views in pure JS and a very small learning curve.
Believe me when I tell you that you can still write complex-yet-maintainable, performant web-apps with just your browser and vim/notepad w/syntax coloring.
If you're looking to be employable, though, you'll probably need to learn Angular/React/Vue and everything that comes with them ;)
>It really depends on what your goal is. You don't need to buy into any of it and still write high quality software.
Unless you also make the decisions at the company you work for, no you really can't.
What you said only applies to people making those decisions for their teams or working alone. Others are at the mercy of whatever BS du jour they'll be asked to code in.
Good point. But if you come to a team where the environment is already set up for you, then at least you avoid the headache of choosing/debugging every nut and bolt of the system just to begin writing code.
If you're in a position to define the stack, you have to weigh the benefits vs churn very carefully.
This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).
I am not "a JavaScript developer" (Python and Django mainly), but that doesn't mean that I don't need to do some stuff in JavaScript. Where do I start? The choices are overwhelming and there is no clear answer.
In addition the JavaScript world seems to be full of people loudly shouting hype about the latest and greatest new framework, then 6 months later it has changed to something else. Its really frustrating from someone that only spends maybe 10% of my time in JavaScript.
Creating new things is sometimes the only or most efficient way of experimenting with new ideas, features and techniques. And if they're really good, other libraries or frameworks can consider implementing them. The beauty of open source.
I have trouble believing this is true in the long-run. There are several examples that seem contrary to this idea.
Lodash was supposed to be a drop-in replacement for underscore, and that was fine and all until contributors felt like they had to duplicate any new features into both libraries. On the bright side, this lead to their upcoming merger, but not without years of wasted effort duplicating work and ink spilled arguing over which was better. You could argue that underscore could have been more willing to merge in more-performant implementations (though I think they preferred readability over speed), but it seems like this fork-first mentality in the JS world somehow makes that almost looked down upon.
Others like Zepto or other jQuery-alikes seem to reach moderate uptake at best but don't necessarily move the community forward either.
Ultimately it seems like the best you can hope for is to get enough attention / stir up enough of a hornet's nest / make dual-contributors lives hard enough to then get merged back in to the original library, and it seems like this is much more pronounced in the JS community[0]. But looking at Node vs IO, CoffeeScript vs JS, or other like-X-but-better situations[1], it sure seems like more community input into and improvement of the already existing frameworks would go a long way.
0: I'm totally willing to admit that JS is one of the things I spend more time doing so I just might notice it more.
1: I know there are nuances to these situations, but I'm being a little reductionist, and they were still stand up to the point.
Alternatively we need to start making optional frameworks. Essentially a way to do many of the usual things you use a framework for (like model binding) but will work, without changing the code, when using just about any framework.
I hate taking the basic things that are not hugely different in concept and workflow but end up using very different code so I can't port it between frameworks. Working on the start of this in my msngr.js library (shameless plug) because I would like to use it but also because I think it's important.
A new framework every couple of weeks is daunting but okay. Not being able to reuse code between them is awful.
We were previously using RiotJs in our company. We are building huge single page application and recently moved to InfernoJS. Results have been amazing. RiotJs used to BE lagging a lot (It simply could not handle 3000 components in same way) It had really long (50ms) delays everywhere.
After moving to Inferno following things have improved:
-We are unit testing components
-Performance!!! (No delays/lagging anymore)
-es2015 syntax with JSX and inheritance
-Intellisense support in IDEs (webstorm) no custom riot syntax
- Future proof syntax without worrying low level API changes
Negative things:
-It took for a while to recode all our components in JSX
Maybe we're just slow, but we recently estimated that rewriting and launching our whole frontend in another js Framework would take a dedicated 3 Person Team atleast a year, how do you explain this cost to someone with financial responsibility, I mean the benefits are probably great, but THAT great?
The alternative, depending on your market segment, is your competitor do it and you don't, they fall behind for a little bit, your sales grow.
Then their version comes out, faster and better, and their dev team iterates faster, eventually catching up and leaves you in the dust. I've seen it happen...very recently, in a situation that ended up in large layoffs.
It doesn't have to be all or nothing though. These libs are easy to keep around side by side, so you can slowly rewrite stuff as you add new features until the transition is complete.
I'm not OP, but they said "We are building huge single page application"
For SPAs, it is not uncommon to use CSS to hide multiple controls (or what would otherwise be entire pages) from the user but leave it in the DOM so you can reveal them as needed. Deciding to hide a DOM subtree vs destroying & rebuilding is a performance balancing act.
Benefit I saw to Riot was that my app's minimized size was one third what it was with React. And not to mention RiotJS was so much simpler than React...
Shameless plug, I know, but I bet Inferno doesn't come close to my latest framework when it comes to the notorious task of writing a TODO app: https://github.com/ErikWittern/TODOit
"Non-performant features have been removed or replaced where an alternative solution is easy to adopt without too many changes." Sound for me like preact (https://github.com/developit/preact)
Same code can run on the server too (node.js) not just in the browser, so it's possible to make search engine friendly page that can work even without client-side JavaScript.
Events + callbacks are great for keeping with the conventions of the existing (ancient) DOM APIs, but I was hoping that a new, 'modern' framework would be a little more ambitious by making everything promise-based.
I'm trying hard to figure out why someone want to use something like this or React, when vanilla HTML, CSS and JavaScript seems much easier and more performant. The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
Why? In a large part, it's because writing reusable components in React makes a world of difference AND is a lot more readable. The jQuery code was a mess of accessing DOM elements and was liable to break without warning when updating the HTML.
The other thing is that it's much easier to write a functional, complex UI. React will attach and detach listeners for you, will create and delete elements, etc. You are not going to be writing lots of hard-to-read boilerplate in onClick handlers. Finally, combined with something like Redux, you get a single-source-of-truth backing the UX, which avoids a lot of the issues I've seen in other jQuery codebases, where there are race conditions between various components during initialization.
It's a completely different way of writing a UI, but I don't see myself going back to the traditional paradigm.
> The only thing I can think of is that appendChild is a bit tedious, but createClass seems even more boilerplate.
You can't compare the two. A component is made of any number of HTML elements and other components, it's not like you are going to use createClass every time you need to want to display a span.
> I'm trying hard to figure out why someone want to use something like this or React
There are many reason why one would want to use framework X,Y,Z instead of writing his own (because at the end of the day, any large application will need some form of framework/toolkit to be maintainable).
The first reason I guess is that in practice the code you depend on is the code you don't have to maintain and test.
The second reason is politics. You work with 50 engineers. You decide to write your own toolkit. I'm pretty sure you'll end up having endless debates about what is the right architecture. Now if you tell the rest of your team or the management "Facebook/Google is using that, they can't be wrong", It can save a lot of time.
The third reason is "laziness". Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap. Yet the same engineers are writing 1 million dollars SPA for Fortune 500 companies ...
Frameworks are a trade-off. By learning one, you expect the investment to save you time, maintenance cost and not to be leaky(i.e. not having to understand the internals of a framework in order to use it). In an era where engineers are asked to be backend engineers, front end engineers, DBA, UX/UI specialist,data analysts, statisticians, server administrators, to know the OSI model from top to bottom,to know 10 languages with 5 years of professional experience in each of them and what not, some engineers don't consider learning the fundamentals of the DOM a worthy investment.
I think you are on to something. When you have hundreds of (front end) developers working on the same UI, refactoring becomes more of a people management problem then a programming problem. And something like React would help in such circumstances. So I can imagine how it would be useful for Facebook. But not the average small team or solo dev.
> Many "engineers" using React or AngularJS actually don't know how the DOM really work, like many people only know jQuery and not standard DOM API in order to perform a task, or many "engineers" don't know how to write CSS so they use Bootstrap.
Many know how all these things work but prioritise your first reason "code you don't have to maintain and test".
The vanilla way tends to result in state spread out throughout your JS and DOM. React UIs act like predictable functions: you describe the UI you want with your current state as the input and React makes the visible UI match that.
I think this is a JQuery problem, as it makes complexing state the path of least resistance. i.e. modifying the DOM directly instead of via functions. Resulting in code that is hard to test or debug. React seems to fix this, witch makes it a good argument on why to use it. My counterargument for "vanilla" JS/HTML is that you can refactor the bad parts. But you can't get rid of React, or you would have to rewrite your whole app! Like when the next JS fashion/framework comes. grin
React itself is just the view. You can replace your template language without redoing everything if you want. Khan Academy, for example, still has some Backbone views that render with React. We also have some Handlebars templates that we haven't converted over yet. That's all peacefully coexisting, though we'd love it if all of our views were React and more of our data handling was just pure functions.
But you CAN get rid of React and not have to rewrite your whole app. Redux, for example, isn't coupled with React at all. React-Redux gives you the tools you need to tie the two together, but you could easily take your Redux code (reducers, actions creators, selectors) with you to a new framework like Angular 2.
"Current state as the input" sounds like a big caveat. I'm having trouble distinguishing this from "you describe the UI you want with your current document as the input and jQuery/JS/whatevs makes the visible UI match that."
One major difference being that Vue.js doesn't really quite support TypeScript even with d.ts files provided. It will work only to a point until things fail to typecheck due to generative aspects of Vue's API.[1]
I think a useful comparison is taking a look at t7[2], trueadm's template library. Last I knew, it wasn't ready for use with Inferno yet, but that is a peek at the direction it is heading. It's rather similar to Vue's templates minus the v-directives magic in favor of leveraging JS for things like control flow.
I'm not 100% sure I'm sold on it, myself, as I rather like beating out Vue templates in Jade rather than doing everything in JavaScript with template strings. That being said, I haven't directly tried to implement anything with Inferno or t7 yet to turn in an informed opinion on working with it.
Inferno is one of the few other library than Vue I'd even bother looking at, however, at this point in time. They both aren't horribly bloated, are rather quick and have a mostly sane model to work with. Cito.js[3] is also interesting and works with t7, if you're looking for even less frills.
It is also worth noting that if you care about licenses, Vue is MIT and Cito.js and Inferno are using a much more heavily restrictive license, MPL 2.0, which will matter if you're a commercial developer doing standalone apps. For this reason alone I have to throw Inferno and Cito.js into the trash at work.
ah thank you for the summary of the licences. that moves inferno off the table for me too. sadly though, cause I was really getting interested with it being written in typescript.
I dont understand. Afaict, MPL only requires you to publish the changes you make to MPL'ed libraries, not all source that uses it. Why does that stop you from using Inferno?
It is the difference between amending documentation (MIT) and producing infrastructure (MPL/LGPL) to ensure that whatever is currently in-tree and covered by the license is exactly what is available for download in the event anyone ever patches it... else you are out of compliance. It isn't just changes, either, it's the files in their entirety.[1]
In a perfect world, no company would balk at having a GitHub account and having a public fork available, but many companies out there right now are still rather conservative about these things. Some barely use source control. MIT is simply one of the easiest licenses for these places to comply with. In my personal experience working at unglamorous places like these, they're fine returning patches as long as they never have to think about the legal implications or feel like there's a burden for using the code in the first place.
The MPL is a poor choice for this sort of code because it makes the assumption that distribution is a given and will happen automatically, but if you're doing application development rather than web development that simply is not true that the code will always be a 'View Source' away. There are certainly applications where this license would be more appropriate, but I do not think an isomorphic vDOM library would be one of them, since this is rather foundational glue.
It would be rather nice if trueadm would reconsider, if possible.
This was a problem I was trying to solve as well and theres a pretty elegent solution that this project has implemented partly already. The "render to string" is also a proof of concept that the indicates "unknown" types can be fullfilled by a "renderer". So long as he allows generic "renderers". Within a more free form environment like nativescript[
1], this library can be one of any that can be used. I was planning to implement blessed and nativescript uis but these can often be very painstaking tasks. If the developers on this project are committed, the sky is the limit!
I didn't know about nativescript before, thanks for bringing it to my attention! That said, it looks like nativescript promotes single code for multiple platform, which means the app won't look awesome in any of them (examples from history: phonegap, java awt). I would be much more comfortable with it if I could just use JS to access native controls and style them using the established (platform specific) methods. I am guessing css will never support each and every widget property... Is this approach possible with nativescript?
It's solving performance issues that React and other virtual DOM libraries currently suffer. This is massively important for low power mobile devices. It's not an ego driven project, all research is going back into the open-source community to make better libraries and implementations inclusion React.
> It's solving performance issues that React and other virtual DOM libraries currently suffer.
But isn't "performances" the point of React? As I understand things, people were moving from AngularJS to React because the virtual DOM was supposed to be the most performant technique to handle UI mutation and rendering.
So what is the reality behind the supposed speed of React ?
I can't make comparisons to Angular as I've never used that library. However, the point of React and the many virtual DOM libraries like it is to simplify UI code.
You write a function that takes the current model state and returns the DOM tree that should be displayed in that state. If you want to change something on the UI, you swap in a new state and the whole thing is re-rendered -- at least that's the abstraction.
It's a programming model that's easy to understand and hard to get wrong. That's the great thing about it! The bad thing about it is that if you implemented it naively, by actually re-rendering all the HTML for your single-page app on every state change, the performance would be awful.
Virtual DOM diffing is a solution to that performance problem, and it makes applications written this way perform adequately. You can't read about React without the DOM diffing being mentioned, and library authors love to compare benchmarks, so it's easy to see virtual DOM as the feature. It's just a means to an end though.
The point is to be able to (from a developer's point of view) re-render "everything", with every change, top down, without having to worry about the details. Doing that normally would be horribly slow, so React makes it adequately fast.
So it's not "super mega high speed lib". It's "Gives you the ability to have a function which, given argument, renders an entire app, and can be called over and over and over" at pragmatic speed, allowing for easier code to reason about.
If your primary goal is performance above all else, it's actually not that great a library.
You can ask for research and proof sure, but it should be very intuitive that a delcarative, "re-render everything from props and state with a call to setState()" system is less error prone than the two way binding digest mess that is angular, or manual dom manipulations for that matter.
Reminder: VirtualDOM is just an optimization of the rerender everything problem.
I don't know if Facebook has done any formal studies. Here's one way to think about it: if you have a webapp and have state in JS objects that you have to synchronize with the DOM, that generally takes a fair bit of code. React provided an approach for eliminating synchronization code entirely.
My own experience and that of the many others that created webapps pre-React and then adopted it is that its model simplifies our work and removes bugs. That's why we use it. It's also why there are a bunch of other vdom libraries and Ember and Angular have both moved toward similar one-way data flow models.
There's a lot that we do day-to-day that doesn't have research to back it up. At some point, we have to try things out for ourselves to see how they work for us.
Anecdotally I can certainly back this up from my own experience. My React based UIs are so much easier to build and maintain than the jQuery stuff they replaced.
As a curiosity, how do we feel about changing the names of the lifecycle methods from "lifeCycleEvent" to "onLifecycleEvent"? Looks like a lot of stuff is pretty transparently portable from React code, I think it's curious this got changed.
TypeScript not only helped improve Inferno's with quality and read-ability of code. It can potentially help produce highly optimal output (bundles) with Google's Closure Compiler. In the future it may even help created optimised WebAssembly output. It's an exciting time :)
fine, thanks. TypeScript makes it even more interesting. I am going to make some tests to see if Inferno can replace React when working with react-templates.
The fact is that React is extrodinaitilly bloated, you can only have one instance in a single environment and you are highly dependent on using libraries that are forks in order to target new environments (like native, blessed or rbg).
React isnt some God given wheel that needs no fixing. Competition is a great thing to have
Thing is, that's the equivalent to saying "Critical mass _has_ to be coming soon with graphics rendering" - what exactly do we expect from critical mass, something like Xcode for iOS?
The Browser is a multitude of runtime UI/network environments with rapidly increasing capabilities. The "frameworks" are basically different abstractions of their capabilities. They are easy to make, and match whatever abstraction the writer's prefer.
I personally dislike React, so am glad it's not "the one" and glad that their are options.
Please don't comment like this here! HN comments need to be civil and substantive—especially in response to new work, which is so easy to dismiss. And personal attacks are right out.
@original question. Did you read the github? It is clearly stated what the intentions are. Mainly performance related achieved through being able to only diff renders that have dynamic values. So if you are having trouble with performance and are pretty sure it's not your code but the framework, inferno might solve it.
The vitriol on this thread is surprising and disappointing, but I can reassure you that it's also uninformed: re-posting things that have received little or no discussion, after some decent interval, is a norm on HN and is encouraged.
It would be a bad idea to post this story again in another month, but your last post got no comments at all, so this is presumably totally legit.
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.
The reason is that there's so much randomness in what gets seen on /newest and thus gets a chance at the front page. Allowing a few rolls of the dice is a way of mitigating that randomness and increasing the best posts' chance at getting attention, which is a top priority here. So we don't penalize reposts as dupes until that happens.
Edit: please don't take the pushback personally. JavaScript fatigue and framework fatigue have become trends over the last year or so. That's probably why the discussion is a bit more cranky than the median. Criticisms like 'ego' are totally out of line; neutral questions like "What problem does this solve" are of course fine.
Erm. That... is a comment that _I_ made, a couple days ago, in a Reddit thread where someone was asking about trying to diff data instead of the VDOM. Why are you pasting it here?
Interesting. If you go to this user's comments, their other comments are from reddit as well. Possible way to farm karma by picking the top voted comment on reddit and reposting it onto HN?
I guess? What's weird is that while my comment is decently written, it's not like it particularly racked up much karma on Reddit to begin with (a whopping 3 points atm), the topic of VDOM management is not likely to be a huge hotbed of upvotes anyway, and the fact that I was replying to someone else to begin with means that just dropping it in here obviously makes it read very awkwardly.
