You probably don't need a JavaScript framework - <AUTHOR> https://slack-files.com/T03JT4FC2-F151AAF7A-13fe6f98da <comment><USER2> I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two libs for crypto bolted on. Simple, easy, but not very maintenance friendly written. Took around 2000 lines all in all. One of four clients (Android, iOS and a bot framework in Scala/Java).

Then the web-boys came in to rewrite my... well, contraption. In came Grunt, NPM, Angular, some CSS framework, unit testing. Much more, but I forgot the names of all of it, you know the drill. I have to admit, looking at each of these components independently, one could hardly argue with their usefulness, but together they buried a relatively simple and elegant messaging system in tons and tons of incoherent, unmaintained, inextensible and incompatible (with websockets at the time) stuff.

The line-count went up, of course, easily to 15000 lines. I couldn't understand my own designs anymore, since they got spread out over dozens different files. Refactoring became almost impossible. The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well and we lost each other, making a babylonian tower, far away from our original goals.

The quality of your solution is not in your libraries, or your frameworks, instead it's in being fluent bottom-up before grabbing a library or two. You'll see you often don't even need them.

(edit: small typos, edit2: please explain down-votes, I'd like to know and be happy to answer any questions)

<comment><USER3> I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down- votes) on the other hand are. If one asks them why they do things the way they do them, they usually have a coherent answer and are happy to explain it.

As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. People who do this stuff every day can easily follow the standard, understand the flow and be very productive. They did invest lots of time to learn about all those tools and libraries and probably had an overall productivity gain compared to writing native JS.

If you don't really enjoy front-end development, and your comment reads like you don't, get on your high horse and join me for a ride while the "web-boys" make our hacked UIs usable for end-users and maintainable for the next "web- boys" who have to hack on it. When we get back we'll probably be very grateful for a great UI(X). ;)

<comment><USER4> > _" They did invest lots of time to learn about all those tools and > libraries"_

Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it".

One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.

<comment><USER3> > introduce frameworks without so much as "apparently it's quite good, so > let's use it"

And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough.

Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

<comment><USER5> >> The productivity gained by agreeing on a framework

This is a false dichotomy. This only applies once the developers have _real experience_ with the framework. Throwing a brand new framework at the devs without at least a month to _play_ with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake.

There is a _lot_ to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that _technically_ uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen.

Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

<comment><USER3> You are quoting me but I am not sure you are responding to my comment.

>> if they all want to use it - let them use it

>> they use the framework they are most comfortable with.

> Then please don't expect devs to pick up a new framework on the spot with no > time to self-train on it.

I never said I did.

<comment><USER5> Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> To begin, React isn't a framework. It's a tool. Would you compare a table saw to a workshop? That doesn't make sense and neither does comparing React to a framework—especially if you're saying you don't need one.

Furthermore, using a virtual DOM is not the purpose of React. Virtual DOM is merely a part of how React works. People don't buy cars to get an engine. They buy cars to get around places. People don't use React to get a virtual DOM engine. People use React to make building and maintaining apps easier.

Let's say you decide you're smarter than everyone who worked on React or some other library, and you can build your app without them. Great, if you're building a small app this is probably just fine. Scale your app up, however, and you're going to end up with a framework anyway. The only difference is that it will be your own framework, and chances are it will be difficult to understand, hard to maintain, and full of bugs, and you may even be stuck with it because of how much it would cost to change.

Using libraries, or even frameworks, is how you leverage the collective intelligence of dozen, hundreds, or even thousands of very smart minds (a few of whom might even be smarter than you). Especially proven ones with many successful projects using them.

You're welcome to give this up to be a cowboy, but me: I've been there, thought I was that smart, and realized how much better off I am by not trying to reinvent the wheel every time.

The rest of the article mentions other points which don't seem particularly related to framework decisions to me at all, so I'll let them be.

<comment><USER7> > To begin, React isn't a framework.

The way I look at it:

\- If you use a library that augments your style of work but doesn't change it then it's a library. Maybe a tool.

\- If you use a library that replaces or changes your style of work then it is a framework.

React is a framework in my opinion. It can be used as a library but it's almost never used that way; most people incorporate JSX and much of the virtual dom into their workflow.

But this is pedantic. I feel comfortable I could make an argument for almost any JavaScript library being a framework as well as not being a framework.

> Scale your app up, however, and you're going to end up with a framework > anyway. The only difference is that it will be your own framework, and > chances are it will be difficult to understand, hard to maintain, and full > of bugs, and you may even be stuck with it because of how much it would cost > to change.

While correct I cannot disagree with you enough. If you write clean, as- simple-as-possible code with clear separations of concerns it's dead easy to maintain and not necessarily "full of bugs". It really just boils down to how well a developer can architect an application to determine if their own framework is going to be a huge bottle neck / issue or a breeze. I've been through both :)

> You're welcome to give this up to be a cowboy, but me: I've been there, > thought I was that smart, and realized how much better off I am by not > trying to reinvent the wheel every time.

I'm not a fan of this sentiment. If it makes the most sense (and it doesn't always) I try to avoid using frameworks but I would _hardly_ call myself a cowboy (though perhaps I will going forward, ha).

The DOM API, as this article shows, provides _quite a bit_ of functionality that many popular frameworks / libraries provide and as long as you don't need to target old browsers you're fine here.

Yes, angular and react do a lot for you but you can still write effective web applications without them with minimal "reinventing of the wheel". Just because someone provides a way to do X in a framework doesn't mean it's not easy to still do X without a framework. Many times the bulk of the framework's capabilities are supporting its own, specialized workflow that isn't always necessary.

<comment><USER8> Good post, very well said and says most of what I wanted to say on the subject.

I was much more in the camp of 'use/learn frameworks as much as possible for productivity', started a new job and have really become much more moderate on the subject. There really is a balance and the type of application you're building matters. The best thing about writing your own framework is that you're able to structure to fit the exact needs of a business. The productivity gains can be extremely massive as well. If you can build a custom system that scales to your needs, it can certainly be worth doing. The flip side of course is that you may ( Probably? ) have a fairly simple/basic product. If you don't have heavy business logic to model, the heavy automation and tooling that is available can be a damn good way to go.

</comment></comment></comment><comment><USER9> The point of React isn't its performance (though that is nice). The point of React is the simplicity and composability of functional components.

You can create this on your own of course (and I have), but the solution of "just use the DOM" ignores an enormous amount of progress that React made with component _design_ , not performance.

<comment><USER10> The main contention of the article is that this "simplicity" is illusory. You end up writing just as much code, but now you've added a complex dependency you don't really understand but have to make your customers download, and ultimately have to test against

<comment><USER11> That seems incredibly anecdotal. Perhaps if you don't understand the framework you are using.

Ember (for example), takes care of huge swathes of complexity for you. I can't imagine trying to build a:

* client side router * data transportation/cache layer * view layer * model layer * build pipeline

... and more, in less code that just

`npm install -g ember-cli` `ember new my-app`

And then having a common app structure with thousands of other people that can provide help and insight.

You people really are kidding yourselves. I feel bad for whoever is paying your salaries.

<comment><USER7> > I can't imagine trying to build a: * client side router * data > transportation/cache layer * view layer * model layer * build pipeline

Why can't you? Routers are _easy_ ; you likely don't need more than a few lines of code to accomplish most of what you need. Caching and data transportation is also easy and simple (there are a million cache libraries if you don't want to write a small one). Views and models have been done since the 90s and are relatively easy as well (in fact I wrote one in just a few minutes the other day to drop some dependencies from a personal project). Though models are not always the best way but I'm digressing.

Build pipelines usually add more complexity than needed in my experience. I almost always, eventually, nix whatever complicated build pipeline I start out with and go with something dead simple.

Most of this stuff has been done for over 15 years on the web. It's at the point where it should be mostly boilerplate / routine if you're not using a framework.

<comment><USER12> > Routers are _easy_ ; you likely don't need more than a few lines of code to > accomplish most of what you need.

Router as in delegating a URL to a handler for that URL? I wrote one once … and it is deceptive and _not_ easy; most of the server side ones that I've encountered (e.g., Django, Flask, nginx) do a poor job.¹

The naive implementation of a mapping of regexes to handlers is dead simple to implement, but not very ergonomic to really use. Something that understands that paths are hierarchies works a lot better. Then it's also nice to have something that can stub out a component to a variable (and preferably type check that), e.g., "/customers/:customer_id", and pass you "customer_id" after validating it to be an integer, a UUID, or whatever. Then you need the capability to delegate an entire subtrees to a subrouter, and maybe if we could just get some handling of delegation based on the method in here, but HEAD needs to be automatic…, and canonicalization of URLs would be nice too.

¹I feel like this is one of those things that until you've seen something better, you're still wanting the faster horse.

</comment></comment></comment></comment></comment><comment><USER13> A) There are people that love frameworks. B) There are the ones that don't.

The type A ones just gave up to the complexity and bury it with foreign frameworks.

The latter ones invent their own ecosystem. And are very productive with it. It's fast and beautiful. And you know every screw and bolt. There is a feature request? No problem, you know immediately how to solve it. I know many of them. And nearly all of them are the best I have ever known.

But here is the big "but". Would programmer type B want to work with a 2 year old project from another type B programmer? And there you have your answer why there is such a hugh appretiation for frameworks. Its easier to throw 10 programmers of type A onto the same project.

<comment><USER14> > The latter ones invent their own ecosystem. And are very productive with it. > It's fast and beautiful. And you know every screw and bolt. There is a > feature request? No problem, you know immediately how to solve it. I know > many of them. And nearly all of them are the best I have ever known.

You're forgetting type C that don't know anything about existing frameworks so decide to reinvent the wheel by writing an unmaintainable mess of spaghetti code... I'm guessing type Bs are very rare. Once you've seen enough untestable jQuery soup you'll learn to appreciate frameworks.

<comment><USER15> I would go so far as to say that to a new programmer on the team, Type B and Type C programmers' code looks much the same.

I'm a type B. I've written entire systems from scratch that fit me like a glove. I could fix any problem in no time flat, and it was very stable.

But when it came time to have other people work on it, it didn't fit them like a glove. It barely made any sense to them at all. They eventually got up to speed, but they were never as productive in it as they would have been in a decent framework-based system.

I was actually quite happy when they decided to rewrite the whole thing... And then it turned out I left about a year later, so it was a good thing they did.

</comment></comment></comment><comment><USER16> You don't need one, but if you don't eventually adopt one, you'll end up writing one.

<comment><USER10> Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller

<comment><USER17> In reality JavaScript size means very little when a single image might be 500k.

<comment><AUTHOR> Unfortunately I have to disagree. The JavaScript Engine still have to parse and interpret the code. This can take a bit of time, especially on mobile devices.

<comment><USER18> Parse time shouldn't be very long at all, especially compared to network latency. How long does it take for large (~100-150kb minified) to be parsed and interpreted? I'd be surprised if it's more than 100ms

<comment><USER19> 100ms is noticeable. It's already slow if you reach that.

<comment><USER16> It's barely above the threshold for detectable live feedback latency, from a musical instrument or sight/sound correlation. As a user veiwing a page with plenty of other latency, it's inconsequential, particularly since you can execute your js while image assets are still incoming.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I don't use React for speed. I use it because manipulating the DOM to make it reflect the application state is _hard_. It's something a program should do for me. React is that program.

<comment><USER21> I don't get a lot of opportunities to play around with JS frameworks, which is odd because I hobby-code a lot in JS. I imagine the top reasons to use frameworks are cross-browser compatibility and support for scalability in the domain of your work. Unfortunately sometimes people use them because the only tool they have is a hammer, so everything is a nail. Vanilla DOM manipulation has become much easier in the past few years. I have played around with some new DOM features in my own time, but for anything public-facing I'm going to use a library that allows for cross-browser compatibility, and typically that's a combination of jQuery, polyfills, etc.

<comment><USER22> It's not that it is hard to `document.createElement` compared to `React.createElement`, it's just that React has a nice paradigm of syncing your app state to what's displayed to the user which many people like. Sure it might be better somewhere else, but React is what is popular and more easily accessible.

</comment></comment></comment><comment><USER23> One thing many people underestimate is how easy it is to run into XSS, XSRF, XSSI when not using a framework, in particular XSS when using native DOM APIs ("location.href = ..." \- pwned. "e.innerHTML = ..." \- pwned. "a.href = ..." \- pwned. "*.src = ..." \- pwned.).

You might not need a framework, but you'll need a structured approach to avoid those problems, and frameworks can help a lot with security.

<comment><USER24> None of those are "pwned" if you know what you're doing. Idiot proofing is a real feature I grant you but it's not something you can blame the native DOM APIs for.

<comment><USER25> Anyone who knows what they're doing is one dumb moment away from not knowing what they're doing. I suspect I know no programmers that don't average at least a dumb moment per day. Your code reviewer is one dumb moment away from not catching it in your code review - which may be as simple as skimming a little too fast because the diff was a little too big. tl;dr: This:

> None of those are "pwned" if you know what you're doing.

... can be rephrased as "All of these are still 'pwned' on a daily basis."

</comment></comment></comment><comment><USER26> "Another example is the Fetch API"... That API has very limited cross-browser support. One of the largest reasons web frameworks exist is to bridge the gaps between browser incompatibilities/offering legacy support.

I don't know if this person has even really scaled and deployed a web application that must work across several browsers - especially older browser versions. I always wonder that whenever I see people bashing frameworks. Like the author said, start with asking why the framework was created. Just make sure you come up with the right answer to that question next time.

<comment><USER27> Yeah I find it hard to believe that the people who go on about how convoluted web development is actually get paid to do web development.

1) Where are all the people hiring web devs who don't know a single library or framework?

2) Why do huge tech companies like facebook and google develop web frameworks if they're unnecessary?

<comment><USER10> Do Google even really use angular? I know none of their core products use it. As to Facebook, their website is painfully slow, seems like it's not a model of the right way to do stuff

<comment><USER28> I don't think their main website uses React fully yet. Instagram does and that's pretty fast—same as most other well-done React apps.

<comment><USER29> Facebook.com contains more than 20,000 react components. They use React at pretty much every dynamic aspect on their website. They also use React Native in a lot of aspects of their mobile apps, both for iOS and android.

</comment></comment></comment></comment></comment><comment><USER30> The article's author does not seem to understand what React is for and why people use it.

The article is full of sentences like: it's true React is fast, but basic Javascript is even faster. Duh? It's true React is quite small, but if you don't use it, your site will be even smaller. No sh*t Sherlock?

React was invented to simplify the program structure of medium-to-large applications by replicating the successful data flow of the Web itself: namely, the state of the application is in one place only (the URL in the Web, the state object in React); HTML is generated from that state using one set of reusable and composable templates; and crucially, user events only affect the state, not the HTML itself.

Personally, I'm going back to basic HTML + progressive enhancement, for a variety of reasons. But React is the sanest of all the client-side architectures I've seen so far, including bare-bones web api.

<comment><USER31> "for a variety of reasons"\---care to share in brief?

</comment></comment><comment><USER32> The cycle continues...

No framework -> Backbone -> Angular -> React -> No framework

We should be back towards using a simple MVC skeleton by the end of 2016.

<comment><USER33> I always kind of liked the simplicity of Dojo-stores, and its observable QueryResults. Simple CRUD, to-the-point, tiny footprint, ... Put a view on it, BOOM, app.

(fan of modern frameworks btw, just saying vanilla MVC is kewl too)

</comment></comment><comment><USER34> The main point of frameworks/libraries is to set coding guidelines for the team. It's fine to go off and invent your own framework but this causes maintenance issues for the people coming in next. Most likely, there are no docs or examples for the code you just wrote (especially the framework bits). When a framework which has a community is chosen, these boring things like docs/examples/references/blog posts get fixed over time. So it's best to pick one so that the code is easier to maintain in the long run. Besides, the focus should be on the app and not the framework/library and writing your own is just distraction.

<comment><USER35> > _When a framework which has a community is chosen, these boring things like > docs /examples/references/blog posts get fixed over time._

Not in my experience. I've seen frameworks come and go like that over the span of 15 years and teams rewriting for the new "hotness".

So, one year they do Angular, then Angular 2 comes out, invalidating a lot of their code/experience, then they get to React, then they're told that they should structure it like Flux, then Redux comes along, and who knows what in 2 years.

Just imaging that merely 5 years ago Backbone was the preferred edge JS framework. In fact wasn't even that at that point -- it was only just released 5 years ago...

<comment><USER36> Release of a new framework doesn't render all existing code based on an older framework useless. Nobody mandates moving all existing Angular 1 codebases to Angular 2.

<comment><USER35> Mandate moving them, no.

But eventually they'll bit rot, and all the new features, and community support will move to 2 -- and you're stuck with the worst of both worlds: a framework with stuff you don't need AND with few left to maintain it.

</comment></comment></comment></comment><comment><AUTHOR> I apologize for not adressing your concerns with the post earlier, I've just added an update to the bottom of the post with some replies to some comments I've read.

Please keep in mind that my intent is not to mock you or your framework of choice. My goal with this post is to try to inspire you to try building something with the native DOM and Web API and see for yourself. Some may enjoy it, others may not. And if you feel comfortable with your current way of building your web applications with a framework, that's completely fine.

Also, please keep in mind that I cannot address every use-case in a single post. As much as I'd like to, that's going to take way too much time.

<comment><USER37> Although I agree with the idea that Frameworks can easily make your life worse instead of better. Especially at the time the Framework moves forward to a version that is not at all compatible with what you are doing.

However, in your update you are suggesting to use Object.observe as a simple alternative to React. I looked it up and [https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/observe) says it is deprecated and even removed in some browsers.

Using API's that are not widely supported and then not relying on a well supported framework to abstract them, seems to me an even worse maintenance nightmare than sticking with a Framework.

</comment></comment><comment><USER38> \- shows an example using mutation observer API and fails to mention it only works on IE 11+

\- follows the _widely_ accepted format of "rant about some popular framework/library/language by mimicking a tiny portion of it"

\- uses _shock factor_ to get the reader's attention

> React, Virtual DOM, Webpack, TypeScript, JSX… HOLD ON! Let's pause for a > second here and think.

YES, you don't always need a framework/library BUT if you want to build something maintainable & scalable, it's better to opt for battle tested approaches (which is especially true when it comes to the web, having browser quirks)

</comment><comment><USER39> It's interesting that by comparison, a lot of these modern JS frameworks are positively tiny. No comparison to e.g. Cocoa, QT, MFC, Rails, Spring and all the things usually called the f-word. React itself barely qualifies for "library", more like "helper functions".

So, having started outside the web world, I really don't understand the hullabaloo. It reminds me of a certain point in Windows development, when shareware etc. was a thing, but download speeds, RAM and disk space were still low. Creating smaller programs was a thing for some developers, both for distribution and an alleged "bare metal" feel (whether they were that much better than e.g. a big package including all of Tcl/Tk is another matter). Programming Win32 with assembly. The ATL. Compressed executables. People recomming a new weird command-line oriented operating system made by some crazy Finn.

Both ATL and Win32ASM bring in yet another feature: Programming in my favorite, possibly new idiom. Another reason for creating these mini- frameworks in the JS world. All glued together by slapdash micro-libs and utilities, that might be there one day, might be gone tomorrow.

I might finally be getting old and cranky, but I actually feel that some bigger frameworks wouldn't hurt. Some kind of standard library included, given that this won't come out of standards or the global community. More opinions. A set of standard components/widgets, not just three score methods of displaying them and two score of connecting them to a score of different backends.

Go all in: If you really want to just use the web browser as a delivery system for all kinds of GUIs, give me a GUI framework. I think that strangely enough ExtJS used to have more competition there...

Either that, or make more use out of the old-fashioned tenets of HTML, do more with text and links and stick to progressive enhancement. The middle ground of shiny but tiny GUIs that seems to be the rule for modern "SPAs" is neither fish nor flesh. (And I don't think that "isomorphic apps" is the answer here, either.)

</comment><comment><USER40> This might be the post that convinces me to write a companion piece on why you probably don't need a CSS framework, either. Browser renderers have come so far since Bootstrap's peak: Flexbox has all but obviated its primary value proposition, and when CSS grids make it out of RFC, using Bootstrap for layout will be like using Backbone to do rollover styling.

<comment><USER41> Sorry, I have to disagree strongly. For starters, bootstrap provides consistent and attractive default styles. Additionally, if you implement your styles as a bootstrap theme, third party components that are written with bootstrap in mind will (usually) automatically have the correct look & feel.

Flexbox is definitely a lot nicer than the Bootstrap column system though.

</comment></comment><comment><USER42> I wrote dbmon at Instructure (first with jquery, then in ember, then in react, where it has been for a couple years) to give us a birds eye view of a bunch of databases. It's been kind of surreal to watch it blow up into what it has.

</comment><comment><USER43> I'm getting so tired of this conversation. Use a framework. Don't use a framework. Just build something already. Who cares how you made it? I'm so sick of getting asked "what framework did you use?" I'm so sick of seeing people pitch their projects as "ProjectName: built with FrameworkX and LibraryY", with zero indication what the project does. If the most interesting part of the project to you is the tools with which it's built, you're not an entrepreneur, you're a fetishist.

</comment><comment><USER44> You don't need a JavaScript framework. You just need a bunch of stuff that you can't use because it isn't supported in IE9.

> HTTP/2 is widely supported by web browsers already. At the time of writing, > 70.15% of visitors has support for the updated protocol.

Oh yay, so only another 5-10 years until I can use it.

</comment><comment><USER45> I came across this thread late, but the comments here have been quite fascinating to read. I think as developers we're always seeing patterns in our code and trying to figure out the best way to solve them and that's how many frameworks emerge. Before React's emergence I would occasionally come across UIs which were incredibly complex due to events firing left and right (and events firing in response to those events, etc) and in an attempt to reduce cognitive load I would try and re-structure the code with a uni-directional flow that would re-render the entire UI when any state changes with varying degrees of success (since applying this pattern on top of another framework is pretty fragile). So React was immediately appealing to me. And Flux and later redux was the evolution of that idea taken to another level.

As for the article itself I was a bit confused by it as from the clarifications at the bottom it makes the assumption that the reader is building a trivial application with minimal UI state. There are thousands of boring companies like mine not named Youtube or Facebook building complex web applications and it wasn't until I read the clarification at the bottom that I realized the whole article wasn't aimed at me.

</comment><comment><USER46> So, I've been working with rich text editors in particular recently, and I can tell you one thing: contenteditable is a gigantic pain in the rear. It's uneven across platforms what it transforms user intent into (control-B: do you get a <b> or a <strong>?), it handles paste events sloppily, and marking inner fragments as not contenteditable (say an image embed, atmention or some other block) is weird, especially if that item is the last thing in the list.

Contenteditable is so annoying that the first thing most rich text editors seem to do is make their own selection state manager, because the native range implementation in the DOM is crap. Medium in particular pretty loudly got rid of it entirely, and that's the direction most modern web-based rich text editors are going.

So. The best thing to do here is find some kind of framework that helps you map from user intent into mutating a data model, and a separate way to translate that data model into the DOM. This sounds like a framework to me, and it especially sounds like one if you want it to work on lots of platforms.

Similarly, sure: I don't need a framework to do DOM manipulation. But I've been using angular (1.x) for a few years now, and I can say: it makes life a _lot_ easier. If I don't have to debug lines of javascript looking for where different elements get injected into the DOM, I'm happy. I can just look at the template file for the html code I'm editing and see where classes get programatically changed based on state, not because I'm deep inside some MutationObserver, but because I can read an ng-class directive. Easy pie.

I sure don't _need_ a framework. I could also program in ones and zeroes. Speaking as someone who's been doing web stuff since the 90s, where the first framework I ever wrote was a bunch of DIY C libraries to make writing cgi- scripts easier, I can say with all honesty: using a framework makes life easier.

Sure, it's annoying to learn, and sometimes the opinions of the framework are different from your opinions. That's why I use angular instead of ember (because I'm not a rails person, for the most part). Take your pick, learn it well, and it will make your life easier.

And if you're that worried about the weight of your library, stop loading so many hero images uncompressed.

(I will grant edge cases where library size is a big deal, but it's more of a premature optimization thing in most places, especially now that tree shaking is starting to make its way back into our build tooling).

</comment><comment><USER47> Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.

<comment><USER48> No, if you look in the footer you'll see it says "Public file shared from Slack", which I think just means someone posted this document using Slack

<comment><USER40> Weird, so Slack effectively has a stealth Medium competitor now?

</comment></comment></comment><comment><USER49> I have been avoiding JS for years (not out of hate, just the job) and every time I dabble in the node/js framework ecosystem I end up turning away frustrated.

I have a few small personal projects that I haven't started due to lack of desire in building the front end I want, after reading this I'm going to give them a shot and see how far I can go with out all the goodies!

<comment><USER50> I was in the same boat, tried reading tutorials for Angluar/Ember/Backbone/etc and wanted to throw up because of all the complexity and prior web experience/knowledge that they expect you to know. But then tried Meteor and everything there made a lot of sense to me.

<comment><USER51> Meteor is a great stepping stone to the more complicated JavaScript ecosystem of node/react/angular/webpack etc. I was a huge fan of it when I first started web development, but all its limitations caused me to switch over to using the above mentioned technologies. I highly recommend it to any beginner to web dev!

</comment></comment></comment><comment><USER52> This eternal argument of js framework/non-framework reminds me of them old days of static html when Dreamweaver will just munch a PSD file and spit out working HTML + Images + CSS. Some of us hated it b/c the output was bloated, super hard to read/maintain, etc. So, some of us just went ahead and coded from scratch. I guess the preference has to do with a need to 'understand' what's going on. Tools like React or frameworks like Angular are just the modern Dreamweavers: don't mind the inner-workings, just follow the rules and get the desired output.

If I can recommend a js framework so flexible it feels like a non-framework I'd say go and learn Backbone.js It's like a flat green Lego table, no assumptions, just structure.

<comment><USER53> I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess.

Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to.

This fits my personal preferences, I prefer simple, verbose code. I also tend to prefer lower-level to high level. For example, I don't like ORMs. For me, it is easier to explicitly express how I want the data to be indexed and move in and out of a database as opposed to have an ORM manage it for me... because if it doesn't do it right, its very difficult for me to learn how to get the ORM to do what I want it to do. I also prefer more keystrokes and fewer "things to have to know about" to fewer keystrokes with many things going on behind the scenes that I cannot see. I think I may be in the minority in this respect?

I understand that there may be better frameworks now, but I feel I need to commit to something and stick with it, I think the cost of re-writing things all the time is too high. I think its faster in the long run to use an old framework that's 50% slower than switch to a better framework every two years.

For reference, this is the main project I use backbone on: [https://demo.enterprisejazz.com/](https://demo.enterprisejazz.com/)

<comment><USER52> >I think the cost of re-writing things all the time is too high.

Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date.

I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js.

I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: \- Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. \- For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re- implemented with Underscore. \- Ditch the router if you need dynamic routes.

Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed).

[http://edwardspooner.com/items/index.html](http://edwardspooner.com/items/index.html)

<comment><USER53> I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff.

When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with.

I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data.

I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events.

Also, I use Marionette.js, not pure Backbone.js

...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake.

Oh, and I looked at your demo. That is really cool. That's really fast for so many records.

</comment></comment></comment></comment><comment><USER54> Most people probably don't need to write much app-land javascript at all to have reasonable UX:

[http://intercoolerjs.org](http://intercoolerjs.org)

Bonus: you get HATEOAS without knowing what HATEOAS means.

</comment><comment><USER55> This! This times a million times!!~!

Seriously. The javascript world is INSANE. All these frameworks and few truly need them... node.js package management is a mess... yet how many of these coders will take the time to learn real ES5? It really isn't that hard of a language.

I feel like calling oneself a "javascript" expert practically requires knowledge of a framework or too. This is saddening, because Javascript itself is a rich language with a ridiculously fast runtime, yet everyone wants to work with a framework when a head full of sound theory and experience will do :/

<comment><USER56> As a javascript-noob, not even jquery? I've heard jquery solved so many headaches.

<comment><USER57> The major criticism of jquery comes from its "overhead" which comes from wrapping a lot of functionalities onto relatively(at the time of its onset) large file[1]. While they were legitimate(internet was slow) at the time, at its cost jquery worked as a go-to-solution for browser incompatibility. This was a major issue which jquery solved magnificently.

And frankly, a significant portion of jquery usages are a very limited set of functionalities: selection, class manipulation, some visible on/off, _AJAX and promises_. A lot of those don't necessarily need jquery[2]. Some hard-core guys go so far as to separately download only modules[3] which works.

Honestly, I wouldn't mind calling a significant portion of jquery to be "pure javascript" as it lets me not worry about browser compatibilities and pleasant stuff that _should have been part of standard library_. ES6 is supposedly fix most of the complaints, but whether browsers will support them or not is a different question.

[1] [https://mathiasbynens.be/demo/jquery- size](https://mathiasbynens.be/demo/jquery-size) has a nice tabular info on how large jquery file sizes were.

[2] [http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/) is a widely cited source.

[3] [https://github.com/jquery/jquery/tree/master/src](https://github.com/jquery/jquery/tree/master/src), go nuts.

</comment></comment></comment><comment><USER14> So instead of using an established framework the post is suggesting possibly using these things?

MutationObserver for UI updates + Fetch API for networking + History API and a custom router for routing + CSS for animations + HTTP/2 instead of Webpack + npm for building + JSPM for package management + multiple polyfills for browser support for all this

Besides not having a name and a dedicated site, how is the above any different from using a framework? Once you've worked out how to get all these things to play nice together, are you really saving any time from just using an established framework that's done the work for you in the first place (i.e. they'll use some of this stuff under the hood already)?

Just because you're leaning on native features instead of library features doesn't make it any different from using a framework. At least with an existing framework you know it's battle tested, has good documentation, has an active community and is easier to maintain for new programmers on the team.

</comment><comment><USER58> React is popular because it re-frames the meat and potatoes of frontend dev as a simple input -> output problem. VDOM merely helps make this approach performant at scale - it has little to do with why people actually use React.

Abusing MutationObserver to get "easy" 2-way data binding is precisely the sort of antipattern that React & Friends would have discouraged.

</comment><comment><USER59> Whilst predictably this HN thread has turned into a bit of a flame war I would like to point out the article certainly made one indisputable point. That HTTP/2 is going to change how modern web apps are written all over again. So then we'll all need another new framework.

</comment><comment><USER60> One of the big ones is build tools.

You don't need Gulp/Grunt/etc for 90% of the stuff I've seen it used for. They could be replaced with a Makefile plus a bunch of standard unix utilities.

You shouldn't have to install 90 libraries in order to build/install/run your program.

</comment><comment><USER61> For those who read the comment about Object.observe: Don't use that. It's being removed from everywhere it exists, and pulled from the standards recommendation. Just have a set(state) function that calls your callback instead, it's like three lines of code.

</comment><comment><USER62> I really wish I didn't need a javascript framework, but I find this essay unpersuasive. He doens't seem to deal with the same kinds of problems I do. But I like that he's making the argument, and trying to pull out the parts where the web API has gotten a lot better. It's approaching maybe. I really do wish.

If we're lucky, maybe we can come up with something lighter weight (conceptually, and in terms of build tools needed, as much as in byte size) that is closer to the built-in browser API. I definitely don't feel like I can do what I need in a sane way with nothing but the browser API though.

</comment><comment><USER63> Back in the late 90s a bunch of us create an architecture we named AJAX. Now in 2016 a bunch of us are still using AJAX to build web apps that work just fine and are probably faster than these "frameworks".

</comment><comment><USER64> I don't think frameworks and tools are the problem. I have dealt with the same frustrations about these huge tool-chains but I've always seen it all boil down to one key point: the problem is not the tools- it is not choosing the right tools for the project at hand. Then you get websites and apps that really bloat up because of the overkill or poor choices.

There's the whole side issue of progressive enhancement and/or making a non-JS version of a site, but I feel like those ideals are now dead- whether it's due to it being unfeasible, unaffordable, or something else.

<comment><USER65> Its ROI. For any new company starting off, they will quickly realize that all non-js agents are either bots or very low-powered machines. With many new companies, who base their entire existence on the web and customers' ability to access it, these two groups are not their target audience so why bother making a JS free, static site when you don't need those customers' business?

On the flip side, government sites are (or at least should be) developed with a high degree of accessibility in mind due to laws that typically prevent anything less. Their reach is much higher and their audience is potentially every citizen in their jurisdiction.

</comment></comment><comment><USER66> Is it possible for someone to point me in the direction of a nice JS project template that does not use a framework?

I would still like all the core elements of a decent JS project such as package manager, bundler, templating BUT without the overkill of a new framework. A project template that allows you to simply write HTML, CSS and JS modules in an organised fashion.

A reference to a Github repo or online doc would be awesome. With so much JS news and information these days its really hard to find any info without the words react or angular or whatever. Appreciate any help from you knowledgable folks.

</comment><comment><USER67> I agree. I enjoy developing the quickest route from a-z. I can write javascript. I know the dom, that its quicker to update one large dom container than it is to update many smaller elements. I have worked with and understand ajax, that rewriting a dom node before unbinding any events creates browser memory leaks causing it to eventually crash. I would not know these things if i had coded with the prescribed framework. If the argument for using them is to have team coding standards then have team coding standards. The framework creates its own problems.

</comment><comment><USER68> Ok, we don't need frameworks, however what should we use in order to build complex UI applications? Own solutions? And know imagine that in every project you build your own skeleton and architecture...

<comment><USER69> I think the point is for complex UI applications (or a team with interchangeable members) you would use a framework. But for less complex applications you might very well not.

Enjoyed this article. I like JavaScript, I use it almost daily, I'd like to learn React or Angular but just haven't had the real need. For the amount of JavaScript in the apps I build there just doesn't seem to be the payoff. I did venture into npm. What a nightmare of goop and time wasting. Although there were some cool utilities the amount of time setting up and dealing with in most cases didn't really pay out.

Don't manipulate the DOM. Why not? Works fine for what I do. Maintainability. Maybe. But well organized code is well organized. If there were a lot more of it this probably becomes a valid point but JS doesn't do everything in my apps. It does the things JS was originally designed to do.

I figure when the dust settles I'll probably dive into a framework. But right now stored database procedures, database triggers, a light Flask/Bottle layer and judicious use of well organized jQuery/ native JS works really well and doesn't have a bunch of unneeded parts.

Then again I'm still using Slackware. I like things simple. The less abstraction and "helpfulness" between me and what I'm trying to get done the better. Simple, powerful, modifiable tools without a lot of glitz and overhead are my preference. I mistrust black boxes and complexity. Maybe React is the kind of tool that could be useful... don't know. Might look into at some point when I feel it's reached puberty.

</comment></comment><comment><USER70> Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Now let's add Javascript to the list.

<comment><USER71> The good news is that with V8 and ES2015, we now have a formalized, (fairly) fast, and tolerably buggy implementation of Half of Common Lisp. Oh yeah, and it runs natively on devices owned by literally billions of people.

</comment></comment><comment><USER72> I like this way to do, preventing complexity.

There may still be things that can not be achieved JavaScript, but aside from those cases, I would even add "you (probably) don't need JavaScript".

</comment><comment><USER73> >Virtual DOM is efficient and has good performance, but native DOM interaction is insanely fast and your users will not notice any difference.

As soon as I saw this, I knew there were limits to this author's knowledge on the subject. React was a _requirement_ for the low-latency UI we built for a major commercial app and without it (or a similar library) the user experience we shot for would have been impossible.

<comment><USER43> React Virtual DOM is faster than rebuilding the entire DOM from scratch, yes. But making edits to DOM manually will be faster with native browser functions and no VDOM diffing overhead.

</comment></comment><comment><USER74> React doesn't exist to handle the massive amounts of data that facebook has.

React exists to make complex UIs easier to build and maintain.

Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code.

That the author kind of misses this point makes me pay less attention to the rest of the post.

<comment><USER75> _" That the author kind of misses this point makes me pay less attention to the rest of the post."_

Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted.

Nowhere does the piece imply that you should render every state change server- side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding.

<comment><USER76> I think I agree with you, but your comment breaks the HN guidelines twice: the first paragraph is uncivil and the final one goes on about getting downvoted. It also pretty much breaks the injunction against "did you even read the article" comments, so that's three. Please don't do these things when commenting here, regardless of how irritatingly wrong someone else may be.

The middle paragraph is helpful and fine, and the comment would have been much better with just that.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER75> The first paragraph wasn't uncivil. He _said_ that he didn't read past the first few sentences of the article:

 _" That the author kind of misses this point makes me pay less attention to the rest of the post."_

If they had read the rest of the post, they would have seen that their argument was addressed.

You're being unfair here. The top-rated comment is from someone mischaracterizing the piece, saying he didn't read it...and you're calling me out for pointing that out.

<comment><USER76> I don't see that. Actually the only bit that seems uncivil to me is just "You just didn't read past the sentence you quoted." You can't know that, and such statements are the internet comment equivalent of elbowing.

<comment><USER75> I was responding to the last line of his comment, coupled with the fact that the comment completely mischaracterized the article based on a single line, early in the piece.

I admit that the last line is unnecessary. I'll remove it.

<comment><USER77> (I didn't downvote you, I really don't mind, but it did sound aggressive).

Here's what you wrote: >> Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted.

>> Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. The argument is that most people don't need React, not that they don't need AJAX or data binding.

Here's a political rewrite (Keep in mind I'm not a native english speaker):

It seems that the author addressed your points later in the article. For instance, rather than rendering every state change on the server-side, it explains how you can get data-binding and partial-update behavior with web- native APIS.

The main argument of the article is that most people don't need React, not necessarily that they don't need AJAX or data binding.

</comment></comment></comment></comment></comment></comment></comment><comment><USER78> This looks like a great blueprint to spend way too much time writing an app that is un-maintainable and only works in a few browsers.

</comment><comment><USER79> Brilliant. I get burned by cross browser issues when going without frameworks. Would love to work exclusively with Web API.

</comment><comment><USER80> I don't agree with the sum of it's parts, but I like some of the... components... in this article.

</comment><comment><USER81> contenteditable and MutationObserver? What about <input> and onchange?

</comment><comment><USER82> Absolutely agree. Also wanna notice that is React is the only one V from the MVC. At least it's weight now more then Angular. Backbone can even do everything and twice time more then React can do.

</comment><comment><USER83> In some special environment, such as Electron (Atom shell), that can ignore the cross-browser problem, writing application using native Web API and DOM API and ES6 is elegant and effective.

</comment><comment><USER84> openEtG doesn't even use jQuery, it's been alright. Only library it uses is pixijs, & a slimmed down version at that. Originally everything went through canvas/pixijs but over time only a few views aren't DOM

[http://etg.dek.im](http://etg.dek.im) for site

[http://github.com/serprex/openEtG](http://github.com/serprex/openEtG) for source

It does a lot of dynamic content generation, which dom.js has proved sufficient for

</comment><comment><USER85> You 'probably' don't need one but 'should' use one to save yourself countless hours re-inventing the wheel that frameworks solve.

The best thing is to try and use minimal frameworks and libraries and justify every single one - Which I'm sure most devs already do. jQuery is still rather justifiable. Yes, you can replace functions with JavaScript today but you'll end up with similar looking functions.

I recently added Transit to animate using CSS3, the alternative would be to write each animation effect I use in CSS3 down to the duration! If I need to change the ease I spend 5x the time doing so - From a devs perspective no, just no.

</comment><comment><USER86> If you're looking for work and the hiring manager fishes for names of JavaScript frameworks you've used, you need a JavaScript framework.

</comment><comment><USER87> +1 [http://www.xul.fr/ajax-frameworks.html](http://www.xul.fr/ajax- frameworks.html)

</comment><comment><USER88> I might not need a framework but that does not mean that there is no value to it.

I don't really need a smartphone, but it is quite useful.

</comment><comment><USER89> Yeah why not? Let's reinvent the wheel every fucking time.

I'm sure your clients and your family will love that.

</comment><comment><USER90> If the author thinks TypeScript is a framework there is no need to waste time reading the article.

</comment><comment><USER91> You probably don't need Redux __ __* but React is awesome

</comment><comment><USER92> npm install --save-dev vanilla-js-loader

</comment><comment><USER93> vanilla-js.com

<comment><USER69> That's pretty funny.

</comment></comment><comment><USER11> I'm really glad I don't have to work with people who think like this.

You don't NEED a framework, just like you could theoretically build a car from scratch.

If your app isn't complex enough to merit using a framework, then you aren't really building something worth talking about.

Frameworks do exactly what they say, provide a common framework for your team to work off of while they build a complex application.

I feel like most of the FUD around JS frameworks comes from simple people building simple apps and wondering why everything needs to be so complicated. Frameworks enforce structure, which becomes more and more important as your app grows in complexity.

Frankly it would be great for me if this train of though picked up steam, plenty of contract work from companies who can't maintain their "homegrown" frameworks anymore.

<comment><USER55> How funny, then, that the framework people can't seem to standardize over anything more than jquery or react?

If layers upon layers of frameworks really were the best approach for complex applications then why can't people get behind one clear winner? Why does there seem to be a new framework popping up all that damn time? How much money has been lost simply keeping up with the artificially hastened pace of change?

Now, I personally have nothing against frameworks individually, but collectively people seem to pile them on top of each other. One is enough -- the beauty of web standards is that there is a common language that one simply needs to speak to access.

You are profiting from the community's collective lack of technical rigor.

<comment><USER11> I profit from people's lack of technical expertise every day, and I'm proud of it.

People come to me because they acknowledge that they don't understand the problems they are faced with, and I provide maintainable solutions that work for years after the contract has been completed.

How?

I choose a widely adopted framework that is suited to the task and follow the best practices of the community that developed it.

That way when I leave people don't say my app is "A spaghetti be-spoke js app" but instead "Its an angular/ember/react-redux app." See the difference?

One is the opinions of a single developer (or small team), the other is the culmination of hundreds of open source developers working together to solve common problems in a maintainable and performant way.

<comment><USER55> I think you're touching on exactly the problem: a 'spaghetti be-spoke' js app. Can a JS app be anything but? Javascript is a language for the view layer. It's supposed to be the minimal shim on top of LAMP or Rails or whatever, to bridge the gap between static HTML and dynamic movement. It was never supposed to run the entire app!

<comment><USER11> You are ignoring huge problems.

How does a LAMP/RAILS app share server side rendering code with the client?

How does a LAMP/RAILS app share data models between the server and client?

How does a LAMP/RAILS app provide search engines with indexable dynamic pages?

How does a LAMP/RAILS app preserve client state between page reloads?

How does a LAMP/RAILS app synchronize client state between multiple connected clients?

Your lack of experience working in a professional front-end environment is telling, and is the source of your confusion.

<comment><USER55> _How does a LAMP /RAILS app share server side rendering code with the client?_

It doesn't, because I don't need/want it to. Any data that needs to be passed to the client is rendered as JSON. Client-side get committed to the database via AJAX (to my buzzword-o-rific REST api), or with good-ol' POST.

 _How does a LAMP /RAILS app share data models between the server and client?_

Again, not needed.

 _How does a LAMP /RAILS app provide search engines with indexable dynamic pages?_

Uh, through clever use of jquery AJAX and postgres indices?

 _How does a LAMP /RAILS app preserve client state between page reloads?_

A serverside redis cache? In the database? In the cookie? LocalStorage? C'mon man.

 _How does a LAMP /RAILS app synchronize client state between multiple connected clients?_

By pushing a hash with current state to all clients via polling? Websockets? Whatsitcalled where you don't close the original HTTP connection? Did you know postgres has some pretty awesome realtime pubsub tech? I suppose if I have some extra time I could send changesets and load them with $.merge()

...

I just want you to know that you are doing nothing to improve my image of the JS-scene-writ-large as immature, spoiled, and childish. There are isolated pockets of brilliance, for sure, but the everyday talk scares me.

<comment><USER94> We didn't collectively decide to move rendering to the client side for no reason. It is unquestionably more complex to build a SPA than to have a traditional web app.

We did it because users demand it. A SPA feels substantially faster and more reactive. Users notice.

If Gmail used your approach, it never would have succeeded.

> _How does a LAMP /RAILS app provide search engines with indexable dynamic > pages?_ Uh, through clever use of jquery AJAX and postgres indices?

I have to assume you're just throwing out terms you've heard of but never understood. Database indexes have literally nothing to do with making your site indexable for search engines.

<comment><USER95> Most SPAs feel substantially slower IME.

The users didn't demand this. They were perfectly happy when you delivered a website that performed a full-round trip in 50ms a decade ago containing more data than your average SPA can handle before choking on it.

The users want it to work. They want it to be fast. They want it to be pretty. That's about it.

I'm tired of hearing about why GMail succeeded. It's revisionist. GMail succeeded because they had the best spam filtering, in a simple design, and you were probably using Google search anyways. Plus Hotmail was always going down for hours (days?) at a time.

I've never experienced bugs in the web like I have with SPAs. I'm very thankful that even if my budgeting software is built in Ember, making it slow and buggy, my bank's site isn't. Making it predictable, and very fast to render. Time to Render is atrocious on many "modern" sites.

<comment><USER96> Gmail also offered 1GB+ at a time when generous competitors offered 100MB.

<comment><USER95> Great point. In the time before Dropbox, S3, etc Email was THE way to share your 50Mb zip file. And routinely having to clean your mailbox because you ran out of storage was a huge pain.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER97> I think the flame war that has erupted has a pretty simple explanation: some people forget the state of javascript just a few years ago. I am currently in the process of moving my team away from the monolithic dojo framework towards using more of the vanilla web standards, but I think dojo was a great choice at the time. The pains of cross-browser support, terrible vanilla APIs that were completely different in IE8 vs the rest of the web, etc. made frameworks "the way to go" in the past, and that's set us off in the direction we are going today of immediately reaching for one. Articles like this one are great in that they are helping to educate people on the power and ease of use that the modern web has to offer, but I can 100% see why people are going to skeptical for a while longer when it comes to using only vanilla javascript.

</comment><comment><USER98> If you don't use one and have a complex app, it will eventually turn into a spaghetti mess of callbacks. You will end up writing your own framework that hasn't been battle tested on thousands of sites.

For simple apps, it's probably not needed. The issue also is that you app could be really simple now, but have features added to it regularly making it complex.

</comment><comment><USER99> I wrote about that about 4 years ago, often called vanilla JS.

Back then everyone on StackOverflow was still completely bought into the JQuery mission. I often see it when people don't fully understand something, they choose a framework.

</comment><comment><USER100> While we're at it, let's just write everything in spaghetti ASP because you don't need a [insert programming language here] framework.</comment>


Chrome 83 would cause apple support website internal error - <AUTHOR> https://discussions.apple.com/thread/8338188 <comment><USER2> Same problem. Same site. For the past several days. Version 85.0.4153.0 (Official Build) canary (64-bit)

</comment><comment><AUTHOR> error stack if browse with Chrome 83:

``` Invalid user input found for this request. com.apple.sse.communities.web.filter.security.SecurityViolationException: ViolationType=INVALID_PATTERN, key=headerName:sec-ch-ua-mobile, id=HeaderValue, config=SecurityConfig(name=HeaderValue, allowedValues=[], ignoredValues=[], enabled=true, regex=[\w\s\:\%\/\\-\\+\\_\\.\@\=\;\,\\(\\)]+, length=256, sanitize=false, pattern=[\w\s\:\%\/\\-\\+\\_\\.\@\=\;\,\\(\\)]+) input=?0 at com.apple.sse.communities.web.filter.security.SecurityValidationRequestWrapper.validate(SecurityValidationRequestWrapper.java:384) at com.apple.sse.communities.web.filter.security.SecurityValidationRequestWrapper.cleanseHeaders(SecurityValidationRequestWrapper.java:272) at com.apple.sse.communities.web.filter.security.SecurityValidationRequestWrapper.<init>(SecurityValidationRequestWrapper.java:100) at com.apple.sse.communities.web.filter.security.RequestCleansingFilter.doFilterIfEnabled(RequestCleansingFilter.java:42) at com.apple.sse.communities.web.filter.AbstractWebFilter.doFilterInternal(AbstractWebFilter.java:32) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at com.apple.sse.communities.web.view.i18n.UrlLocaleFilter.doFilterInternal(UrlLocaleFilter.java:186) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at com.apple.sse.razor.http.filter.HttpServletRequestValidationFilter.doFilter(HttpServletRequestValidationFilter.java:36) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at com.apple.sse.communities.web.filter.HttpServletMetricsFilter.captureMetrics(HttpServletMetricsFilter.java:80) at com.apple.sse.communities.web.filter.HttpServletMetricsFilter.doFilter(HttpServletMetricsFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at com.apple.sse.razor.http.servlet.ServletAccessLogFilter.doFilter(ServletAccessLogFilter.java:69) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at com.apple.sse.razor.web.RazorWebRequestFilter.doFilterInternal(RazorWebRequestFilter.java:156) at com.apple.sse.razor.web.RazorWebRequestFilter.doFilter(RazorWebRequestFilter.java:76) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:502) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) at java.base/java.lang.Thread.run(Thread.java:834) ```</comment>


StarCraft AI Competition Results Announced - <AUTHOR> http://eis-blog.ucsc.edu/2010/10/starcraft-ai-competition-results/ <comment><USER2> More detail on the winning bot Overmind:

[http://www.youtube.com/watch?v=fWtpTu9gB20&feature=playe...](http://www.youtube.com/watch?v=fWtpTu9gB20&feature=player_embedded)

They had a team of 13 Berkeley AI researchers working on this bot.

</comment><comment><USER3> Thread on Team Liquid forums (Starcraft community site as well as Starcraft team) about this: [http://www.teamliquid.net/forum/viewmessage.php?topic_id=160...](http://www.teamliquid.net/forum/viewmessage.php?topic_id=160539)

</comment><comment><USER4> Man, watching those mutas fly around really makes me wish _I_ could personally interface with BWAPI. I've always wished it was possible to manage each unit individually, even in combat.

I guess that's what turn-by-turn games like Advance Wars are for though.

</comment><comment><USER2> The winning bot's strategy seems a bit one-sided (mutalisk-heavy). I guess no bots were good enough to build real counters to that? Looking at the videos, everyone is trying to kill mutalisk with Goliaths, which is not exactly the strongest tactic.

<comment><USER5> Goliaths are the standard response to mutalisks, as goliaths are Terran's strongest anti-air unit. They have a pretty good dps vs air, and they significantly outrange mutalisks.

The Berkeley bot's mutalisk micro was just too good.

<comment><USER2> Goliaths alone? I don't think so. Any player with good micro (and we're talking bots here) will keep dancing out the damaged mutas, since Goliaths can't follow to kill. You should at least throw a couple of Valks into the mix. A bot could also pull off the cloaked Wraith + medic combo, perhaps.

<comment><USER6> Scourge snipe valks since they cannot move between attacks #1 and 8.

Valks also cannot fire once there are too many sprites/actions going on. They may have been excluded because of that if you didnt see any.

</comment></comment></comment></comment><comment><USER7> Does anybody know how these bots perform against humans players? This seems to be early enough in its infancy that I would expect humans to outperform computer players pretty significantly but I might have too much faith in my own race.

<comment><USER8> In a straight up game, if the human plays standard then the computer will have a pretty good chance.

The main issue is stracraft is pretty complex and if the computer is predictable, a human can just exploit that for easy victory. (always 6 pooling for example)

<comment><USER9> Yes. Although build orders are not a very good example --- because that's on area where computers can be made more flexible and random without too much difficulty.

I guess that bots' micromanagement will become superior to humans, if it isn't already. A bot won't have any problem coordinating three or four battles at the same time. For humans it's quite hard to fight a multi-front war given StarCraft's UI.

</comment></comment></comment><comment><USER4> Are there any plans for the winner to assimilate the loosers, as it wasn't hands-down the best?</comment>


Google's Anti-Bullying AI Mistakes Civility for Decency - <AUTHOR> https://motherboard.vice.com/en_us/article/qvvv3p/googles-anti-bullying-ai-mistakes-civility-for-decency <comment><USER2> Sounds great. I hope some forums implement this so that people can have discussions about horrible topics in a civilized manner, instead of everyone just shunning people who think differently, whether that person is otherwise decent or not.

I'd love a chance to have civilized discussions with people who I think are very, very wrong. It'd be a chance to actually convince them they're wrong, instead of just screaming hateful things at them and walking away.

I'm not at all worried about them convincing me to start hating people, or even to convince other non-hateful people to start.

<comment><USER3> As an aside, It would also be a great way to throttle yourself.

Eg, I too would love to have the discussions you speak of. Despite this, I often see an escalation in tone and fight the urge to respond in kind. I often fail at not responding in kind. Doing so of course escalates the conversation, something I've now contributed to, and it will likely escalate yet again. Over and over, until all reasonability in the conversation is dead.

If I knew it wasn't allowed, and especially if it gave me some type of non- public meter of how much further I can go before my conversation will be blacklisted/etc, then people like me have clear visual feedback over .. well, not being such a douche.

It would be like having a state patrol a few lanes over on the interstate. If one is around, most people behave quite well, because we can all see what will happen if we step out of line. Likewise, our speedometer gives us the visual feedback to know what is out of line _(with regards to speeding of course)_.

It would feel very weird at first, especially if the system was not perfect, but at it's root I think it's needed for us to be able to discuss sensitive topics. Which, tend to be the ones we need to discuss the most.

<comment><USER4> So you would rather sit in a traffic jam because everyone is scared they'll be the one who gets made an example out of for behaving normally?

That's what having visible cops patrolling the highway devolves into and it's pretty terrible.

I'm not sure if your opinions are bad or you just made bad comparison.

<comment><USER5> Your last paragraph is definitely uncivil. The other two, maybe borderline uncivil in tone, though accurate in reality.

</comment></comment></comment></comment><comment><USER6> This is what you get from non-technical people projecting their understanding onto tech. It's not that Google's AI is trained to make sure everyone is civil, it simply requires less sophisticated language understanding/modeling to determine civility, and Google's results show the limitations or current ML/NLP technologies more than the data it was trained on, this is clearer when you see that it can't handle pretty serious threats because they don't have profanity - these things definitely fall into the bucket of what would make users leave a platform.

<comment><USER7> Alternatively, technical people projecting their understanding onto culture.

</comment></comment><comment><USER8> Yeah anyone who vaguely understands AI could see that this would be the case. It's not some kind of conspiracy by sexists.

<comment><USER9> In spite of current confusion about these two terms, I think it's extremely important to differentiate between AI and ML. Perspective is a model example of ML in action. With AI, the authors would at least make some effort to classify phrases based on their meaning, not just words. As it is now, Perspective is just a profanity filter based on some training data, it's very far from AI.

<comment><USER10> It's an AI (artificial intelligence), but it's a long way from AGI(Artificial general intelligence) / strong AI / full AI.

Removing your hand from fire is generally an intelligent reflexive action ~= AI. Understanding implied meaning of arbitrary text is orders of magnitude more complex ~= AGI.

</comment></comment></comment><comment><USER11> There was an article in the Guardian at the weekend about people from the US having terrible problems in the UK (particularly London) where people would say very nasty things very politely... which is a _very_ middle class bit of British behaviour.

<comment><USER12> Indeed an excellent example of this is the houses of parliament. Personal attacks or questioning another house member's honor is completely forbidden. So in order to insult someone, they often use complex analogs of what they mean, leading to such great slurs as:

Terminological inexactitude [0]

Economical with the truth

Tired and emotional

[0][https://en.wikipedia.org/wiki/Terminological_inexactitude](https://en.wikipedia.org/wiki/Terminological_inexactitude)

<comment><USER13> "Half the Tory members opposite are crooks."

"Withdraw that remark"

"Ok, half the Tory members are not crooks"

[http://www.theweek.co.uk/amp/62692/dennis-skinner-quotes- the...](http://www.theweek.co.uk/amp/62692/dennis-skinner-quotes-the-beast-of- bolsover-in-full-flow)

</comment></comment></comment><comment><USER14> >"toxic" being defined as a "rude, disrespectful, or unreasonable comment that is likely to make you leave a discussion."

This is why who programs the AI has such influence over the value judgement. Just because AI does it, doesn't mean there is no human influence over it. Actually AI doing it instead of army of humans means handful of people have control over the outcome.

That definition of "toxic" is defined for Google's business. Keep the user's attention and eyes on Google's web properties serving Ads.

What is toxic? Anything that makes a person leave, reducing Ad imprints.

A person may stop commenting if they are convinced or challenged of their views. In a normal conversation, all tools of a language, comedy, sarcasm, hyperbole etc. can be used to show someone a new way to look at things.

Google AI is going to put evolutionary pressures on language features. Language features that keep a person watching Ads on Google properties will be selected for propagation.

</comment><comment><USER15> Well, it reflects one-dimensionalness of SV hipsterish big co. pop-culture: it is "I like it" or "I don't like it" and nothing in between or off-axis.

It is not in how it scores, but in the very fact that people who built it are normally incapable of giving a given sentiment more than one thought.

</comment><comment><USER16> > "while a 100+ subthread about 'was slavery really that bad?'"

(Edit) The article implies that such a discussion implies that someone wants to promote slavery.

I would think that such a discussion would be very productive about reminding those of us who didn't live through slavery why it was that bad.

If we can't discuss "was slavery really that bad," there are people who will go around really believing that slavery really isn't a bad thing. That's why these kinds of discussions are critically important.

</comment><comment><USER17> Machine learning, aka. "Mining your data for bias".

</comment><comment><USER18> This reminds me of the saying, _No one means to write "ducking" in a text_. For some reason, using the word fuck automatically equates to rude, toxic speech when the reality is that the word has multiple uses and sets a variety of tones, both good and bad.

I understand that the AI is merely doing what was programmed in and there are limitations, but it still draws me to the conclusion that it is really more of a moral thing than something to weed out toxic speech, as evidenced by the hard lines taken against folks telling an aggressor to "fuck off".

And for something interesting:

 _You 've been eating paint chips and chasing them with leaded water, haven't you?_ only ranks in at 25% toxic.

<comment><USER19> As a non-native English speaker, who learned much of the language trough absorbing pop-culture, I feel especially guilty of this.

I tend to use words considered "rude", to many native English speakers, merely for flavor when I'm passionate about a certain topic or argument.

To be fair: I do the same in my native language, I tend to use quite colorful language sometimes, so it's probably more of a personality thing.

<comment><USER18> It isn't just you, to be sure. I'm a native English speaker, but live in Norway. My Norwegian isn't strong enough to converse at length yet (I'm getting there) so most of my in-person communication is with non-native english speakers, including the spouse.

Some phrases simply translate in a rude way: Norwegians seem to have a liking for the word "fuck", which has made its way into Norwegian slang as well. It can come off quite rude back home. For folks I meet that learn mostly through television, it can get even worse because the shows don't always portray dialog in a natural way.

<comment><USER19> > For folks I meet that learn mostly through television, it can get even worse > because the shows don't always portray dialog in a natural way.

Those folks should start watching some fucking proper television ;)

Good point about "fuck" creeping into the slang of a lot of other languages, I've witnessed the same very often but never really noticed until you pointed it out like that.

Curse words seem to have a certain attraction in that regard, I probably know the equivalent of "fuck" in like 4-5 different languages, while understanding literally not other phrases in those languages.

</comment></comment></comment></comment><comment><USER20> I'm cognisant of the fact that it's very easy for "conversations" on the internet to devolve into ugly, unproductive masses of human mental refuse at a much more accelerated pace than offline, but we also have to be aware that letting machines filter what we can or can't say based on "decency" or "toxicity".

It's fine if the system reminds you that you are not being particularly polite or toxic, but filtering communication on the internet by this manner can't be the solution.

'Do you know that Newspeak is the only language in the world whose vocabulary gets smaller every year?'

</comment><comment><USER21> Thoughtful SOA. Morals and ethics are baked into the code.

<comment><USER22> ... complete with lingo ("toxic") that is vague enough that it cannot be defined or disputed. Convenient!

<comment><USER23> Yet it is defined right in the article:

..."toxic" being defined as a "rude, disrespectful, or unreasonable comment that is likely to make you leave a discussion."

<comment><USER24> Make who leave a discussion?

<comment><USER25> The reader who finds the statements to be toxic.

</comment></comment></comment></comment></comment><comment><USER26> I'm surprised there isn't more discussion about hype cycles and the poor efficacy of "AI" here. Sentiment analysis (find the uncivil words) is a trivial solved problem in 2017, and is many, many orders of magnitude less computationally complex than the semantic intelligence problem that would have to be solved in order for robots to be useful here.

</comment><comment><USER27> So the Google has turned itself into all censoring AI-apparatus?

<comment><USER28> [https://news.ycombinator.com/item?id=14998429](https://news.ycombinator.com/item?id=14998429) \- Youtube "AI" censors War Crime evidence [https://news.ycombinator.com/item?id=14975338](https://news.ycombinator.com/item?id=14975338) \- Google censoring World Socialist Workers

</comment></comment><comment><USER29> Yeah this is just click bait. I haven't looked at the model they deployed, but it's likely just not sophisticated enough to represent aspects like tone and frame of reference. It might just be a great word-based language model. That doesn't mean it's intentionally biasing against civility.

</comment><comment><USER30> Pretty fucking judgmental about occupation.

Larry sells donkeys: 87%

Larry sells llamas: 16%

Larry sells beef: 17%

Larry sells bananas: 45%

<comment><USER15> The idea of scoring sentiment on a linear scale is kinda pointless on itself, people usually start to realize that by the time they graduate a primary school.

</comment></comment><comment><USER31> Sounds like the author wants an AI that only allows 'good' ideas to be discussed.

<comment><USER32> I wouldn't jump to that. I'd hope the author wants human wisdom used more and is wary of AI in general, but I'm not sure.</comment></comment>


Paid Blogger - <AUTHOR> http://techcrunch.com/2012/10/23/paid-blogger/ <comment><USER2> He was "unfired"? What a joke. Arrington is overrated and the tech equivalent of Paris Hilton; famous for no good reason.

Though, the article TechCrunch wouldn't publish is actually halfway decent.

<comment><USER3> I would say he is more similar to Perez Hilton than Paris Hilton.

</comment></comment><comment><USER4> Terrible title, other discussion: <http://news.ycombinator.com/item?id=4688798>

</comment><comment><USER5> So if he's not allowed to talk about something (among which his investments) on TechCrunch he'll talk about it anyway on Uncrunched? Cool story, bro. I see it as a win-win. For him <http://cl.ly/KN0U></comment>


Ask HN: Tutorial for syncing cameras with recorded audio? - <AUTHOR> There is a method to sync the frames of multiple cameras close together with recorded audio (albeit with a margin of error due to the relatively low speed of sound). Is there any literature on this? I know video editing software probably uses it but I'd like a deep look at the methodology so I can create an algorithm adjusted for my purposes. <comment><USER2> My understanding is you're looking for landmarks in the audio and then matching/aligning on those.

Shenidam is open source software which does the whole process, site offline, GitHub still up: [https://web.archive.org/web/20160309034204/http://shenidam.o...](https://web.archive.org/web/20160309034204/http://shenidam.org/) and [https://github.com/stendardo/shenidam](https://github.com/stendardo/shenidam)

A node stream module: [https://github.com/adblockradio/stream-audio- fingerprint](https://github.com/adblockradio/stream-audio-fingerprint)

Python: [https://github.com/dpwe/audfprint](https://github.com/dpwe/audfprint)

A blog post explaining fingerprinting: [https://willdrevo.com/fingerprinting- and-audio-recognition-w...](https://willdrevo.com/fingerprinting-and-audio- recognition-with-python/)

Commercial software: [https://www.redgiant.com/products/shooter- pluraleyes/](https://www.redgiant.com/products/shooter-pluraleyes/)

</comment><comment><USER3> _ith a margin of error due to the relatively low speed of sound_

The typical frequency of video (frames) is ~30Hz. Maybe 24Hz for cinematic effect. Maybe 240Hz for super slow motion (but then you're not syncing with sound). 60Hz (sixty frames per second) is probably the upper end of what you are likely to have sync.</comment>


Euro has 1-in-5 chance of lasting decade: UK think-tank - <AUTHOR> http://www.reuters.com/article/idUSTRE6BU0QI20101231 <comment><USER2> Typical think tank thinking: make an outrageous statement; lots of contracts if you are right; no one remembers if you are wrong. There is so much political and economic damage to be done that the euro wont be allowed to tank. Restructuring of banking relationships, sure.</comment>


Python.org Redesign Proposals due in 7 days - <AUTHOR> http://jessenoller.com/2012/07/14/python-org-redesign-proposals-due-in-7-days/

<comment><USER2> It's interesting that they're getting a redesign - I've always thought Python.org was one of the nicest, cleanest sites for an open source project.

Here's their reasoning for a redesign: [http://pythonorg- redesign.readthedocs.org/en/latest/#current...](http://pythonorg- redesign.readthedocs.org/en/latest/#current-issues)

</comment><comment><USER3> Am I correct in saying the proposals are not yet available to look at? I think I would understand the reason, but still wondered.

In any event I'm happy that python.org renews. When I wanted to learn Python and Ruby, I checked out Ruby first because the materials seemed more up to date (at the time there was no other way to prioritize and it wasn't important either.)

Can't wait to see the winner!

</comment><comment><USER4> Copy PHP.net's format. Part of the reason PHP remains popular is its the online documentation.

<comment><USER5> How is Python's documentation any different? Do you think it's too verbose? Having used both, I'm not sure I see much of a difference aside from Python tending to document an entire module in a single page.

<comment><USER6> Personally, i find the python documentation a little overwhelming, while i found PHP's much clearer and more straightforward, despite learning PHP first. Much easier to figure out something quickly. Its hard to pin down but if i had to i'd say it can be too verbose, there can be too much on a page, and too little white-space. I'd also like to see it more example driven.

Having said this i rarely if ever hear any criticism of the python docs from others.

E: sorry, why was stating my opinion, when sought, deserving of downvoting? If you disagree then say so-- i even stated i thought my opinion was a minority one!

<comment><USER5> I'm not sure why you were downvoted. Thanks for your honest response, though.

(Sometimes when it's hard to put into words an exact reasoning for something you feel it turns out to be worth investigating.)

</comment></comment></comment></comment><comment><USER7> Is there anything considered wrong or no longed suited to the current requirements in the present design?

<comment><USER8> Explained here: <http://pythonorg-redesign.readthedocs.org/en/latest/></comment></comment>


Compare Valuation History of Startups (such as Lime vs. Flexport) - <AUTHOR> http://188.8.131.52/ <comment><AUTHOR> Hi HNers, I built this MVP over the weekend. Let me know if you find it interesting or useless ;)</comment>


How GPS Came to Be – And How It May Be Altering Our Brains - <AUTHOR> http://www.bloomberg.com/news/articles/2016-04-21/how-gps-came-to-be-and-how-it-may-be-altering-our-brains <comment><USER2> Stupid article generalizes from "people make mistakes due to assumptions" to "GPS is altering brains" with no support.</comment>