Dan Abramov - Live React: Hot Reloading with Time Travel at react-europe 2015

As somebody who hasn't worked with react before I find this talk very interesting: ▶ this video He talks about improving the development workflow by hot reloading parts of the application during runtime. Slow workflows affect every developer and the idea from this talk can be used to build tools for other stacks or languages.

in “Ask HN: Best (Tech) talks from 2015” · View on HN

I think if you take a lot at the motivations that Dan Abramov had for creating Redux [1], you'll see that improving debugging was at the centre of it. Check out his talk he gave at React-Europe. He basically is talking about improving developer tools. The functional approach Redux takes allows for you to see state transitions and replay actions - making it relatively trivial (compared to say Angular.js) to understand how to reproduce a buggy state. [1] [link] [2] ▶ this video

in “The 3REE Stack: React, Redux, RethinkDB and Express.js” · View on HN

Though I don't have experience with a large rewrite like this. I am really liking what I see in React. React + Redux for the Flux pattern seems to be the best combination available right now. Watch this talk by Jessica Kerr - Functional Principles In React [link] about why Functional / Declarative approach is good for front end development. Also Dan Abramov (Redux Author) Talk - Live React: Hot Reloading with Time Travel ▶ this video introducing Redux is great. Watch this awesome talk by Ryan Florence - Don't Rewrite, React! [link] on how to approach rewrites bottom up and he rewrites a part of the TodoMVC written in Backbone.js.

in “Ask HN: Which is best React or Angular?” · View on HN

Hey, lib author here. Let me first explain Flux in five seconds. Instead of mutating your models, any data mutation in your app is described as a plain object describing “what happened” (e.g. { type: LIKED_POST, postId: 42 }) and broadcasted globally. Models (called Stores in Flux) have no setters and change their internal state in response to specific mutation objects (called Actions). The goal of Flux is to have single source of truth and make it easy to avoid race conditions and cascading updates. If some data is wrong, just repeat the same Actions in the same order, and you'll get the same data in Stores. Very easy to debug. Now, for Redux. It keeps the properties of Flux (mutations described as objects), but instead of Stores mutating internal state, it has Reducers—pure functions with (state, action) => state signature. While writing Flux apps, I noticed that the _essence_ of every Store I ever wrote was a reducer function. It turns out that using pure functions instead of event emitters has many benefits: they are composable ( [link] ), it is possible to hot reload their logic ( [link] ). I wrote Redux for my React Europe talk about Hot Reloading and Time Travel ( [link] ). It got popular before I explained _why_ I made it. In my talk I show what kind of powerful devtools it is possible to build on top of Redux. The video of my talk will be up soon, you can check when it appears here: [link] . Also check out my article on the subject: [link] EDIT: THE VIDEO IS UP! [VID

in “Redux: Atomic Flux with Hot Reloading” · View on HN

Directives are replaced by React components. I would argue, IMO, that directives are actually a half-assed implementation of components. In terms of services, I would recommend using Flux to perform actions / store your state. This is what a lot of developers are leaning towards these days. There was a great talk at React Conf about Reflux, I've never used it, but the presentation has convinced me to try it out on my next project: ▶ this video When you build with React, imagine building an application in Angular using only Directives. It isn't that simple, but that is sort of the idea with React components. I started with Angular (and still work day to day with it at work) but if someone asked me how I would architect an application tomorrow, I would go with Flux + React + ES6, no questions asked. Also, Angular2 is heavily influenced by React, so learning React now will allow you to have a better understanding of Angular2.

in “Angular vs. React – the tie breaker” · View on HN

This is out-dated from my perspective. Check Redux ▶ this video [link] Many Flux implementation lucks of isomorphic, proper hot-reloading, etc. ES6 transition is on its way. Most code will be abandoned. Alt, Reflux, etc are all in trouble.

in “Flux Architecture Visual Cheatsheet” · View on HN

If you're wondering about which flux implementation to start with, I'd highly recommend checking out Redux : [link] The main idea is to think of stores as reducers (redux = reducers + flux). He also gave a very good talk on it at react-europe: ▶ this video

in “Flux Architecture Visual Cheatsheet” · View on HN

Dan Abramov 2015 ▶ this video But there was one earlier presentation I cannot find it, guy was showing live debugging of the video game. Not sure is it TED or one of conferences ... Edit: This is it: Bred Victor: [link] 2013 Future of programming [link]

in “Show HN: Time travel debugger for web development” · View on HN

That's wrong. Dan created Redux while he was actually unemployed. I'd have to check the exact timeline, but I believe he left Stampsy in late 2014 or early 2015, and was actually getting some funding from an OSS collective-type thing while he developed Redux in preparation for React Europe. Redux was developed in June/July 2015, and demoed at React Europe on July 5, 2015 [0]. Redux 1.0 was released on Aug 14, 2015 [1]. Per the tweet linked from that page [2], Dan didn't join Facebook until November 2015, well after Redux had been released. So, he most definitely was _not_ working at FB when he developed Redux. [0] ▶ this video [1] [link] [2] [link]

in “Comparing Svelte and React” · View on HN

Is Apollo good? I feel like I’ve been aware of their existence for a long time — they have a large marketing presence but I don’t actually have any idea what it is ... there’s a server for making graphql servers and a client for doing ...??? I know they have tools for compiling graphql queries into various typed language interfaces which I have lusted for. I feel like every blog post of theirs I’ve ever clicked is high percentage marketing and not a lot of focused explanation ... They have a tough communication nut to crack — they have to sell to people who’ve never heard of graphql, to people who’ve lusted after the vision communicated very clearly by Facebook for graphql and relay, to people using redux and the disarray of different mechanisms for straddling the various in practice divides between local and server state. Being able to map rest apis into graphql apis on the browser side seems like a nice migration strategy but there still seems like something missing to me to feel like I know what the value proposition of the Apollo Client is ... Are there any good live demo style introductions to Apollo — something gripping like the original redux conference demo[1] ...? [1] ▶ this video

in “Apollo Client 2.0” · View on HN

Hey there, I'll start with the disclaimer, as lately HN comments have tendency of becoming toxic - everything I write is my personal opinion. With that behind us I can start. I'll try to write this for someone who knows very little about JS, but knows her/his way around basic programming/cs. Firstly I love JavaScript, I have been writing it for 10 years now, but there are bad parts of it as well. Let's start with good stuff * It is evolving in the right direction * You can do a lot of things with it (web apps, games, mobile apps, server...) * Materials for learning are everywhere * It will be easy to find a job Bad stuff * It is moving at crazy to follow pace * There are a lot of different ways of doing same things * As it is very hip thing to do, there is a lot of bu___hit (beware of the hype train) Learn plain javascript before moving to frameworks. Focus on ES6 and new stuff as it will make your life way easier. * Someone already mentioned Dr. Axel Rauschmayer, pick any of his books - [link] * Another good one is You Dont Know JS - [link] Try to make small app on your own. You'll get into all sort of problems, but that's the fun part I guess. That will help you to understand what frameworks are trying to solve. Then you can start learning one of the frameworks. React, Vue, Angular are all solid choices. My pick is React, as I know it best. Apply the same mindset as with learning plain JS. Try to write your own stuff on a small scale before importing huge libraries. Good ex

in “Ask HN: Experienced JavaScript programmers, what are your recommendations?” · View on HN

I've a good few years web programming experience: Rails, PHP, HTML/CSS/JS (jQuery), SQL, ... you get the idea. Apart from keeping up to date with Rails nothing 'modern'. I've spent the last week (finally!) trying and in the end succeeding to wrap my head around React+Redux. It took a many many many hours of puzzlement. I began with the react+slingshot[0] @coryhouse made as a starter kit and going through the React docs and Redux docs. I guess my desire stemmed from seeing Dan's demo of Redux's time-travel and hot reloading ability, I was intrigued. I copied the TODO example from the Redux docs and fashioned it to my liking exploring all the parts. I'm here to tell you that it's not easy. The landscape is still in flux (buh-dum-tish, I'll be here all week folks) and that for every piece of the dev tool puzzle you've two or three options. I think you can get away with React+Redux on the client side which replaces the V in your MVC. {This in practice means the `react', `react-dom', `react-redux', and `redux' files. _Everything_ else is tooling, but my God so much tooling}. YMMV. That's as far as I'd go, otherwise you're throwing out all your server-side dev experience, and why would you want to do that? What I'd like to ask folks is: what happens to my nice static HTML/CSS pages if React+Redux is all JS? Server-side rendering? I'll come back and edit this and put in a few more links I found handy. Do believe the hype, React+Redux is pretty neat. [0] [link] --- Edit! React docs:

in “Ask HN: How does a 1990s web developer get back on track?” · View on HN

I agree that it sucks when the "worse" technology wins, but your points on why React is an example of one of these "worse" technologies are seriously misinformed regarding its shortcomings and have largely glossed over some of its most significant merits over existing technology. > React seems to be designed to ignore 40 years of accumulated software best practices. Best practices in software is not set in stone. Sometimes you need to break from existing best practices of the past in order to arrive at truly powerful new approaches to solving problems that may not seem intuitive at first, but eventually manage to redefine best practices through their technical merits. The Virtual DOM and re-rendering on every change is one such approach popularized by React, but it's definitely not the only one, nor is it even the most significant one, in my humble opinion. Before React, mutable models was the only game in town. Angular imposed mutable models, Ember imposed mutable models, Backbone imposed mutable models, your average custom ad-hoc JQuery framework probably also imposed mutable models. Everyone blindly followed this "best practice" simply because this was the status quo ever since the earliest days of UI development. React is the first JS UI framework that does not impose a mutable model. And as a result, the ClojureScript community was able to build on top of it and show the world that change detection can be implemented as a constant-time reference comparison when immutable

in “What is a coder's worst nightmare? (2014)” · View on HN

But most things we see are 2D outputs (webpages, world if you close one eye, text console,..). I think the closer we are to the bret Victor's ideal (of seeing what you do directly) is this: ▶ this video (react-hot-loader + redux). And this is already practical. Another nice tool who's the near his ideal is the chrome dev console: visual interaction, live edit, start/stop debugging,.. The future is bright.

in “Working Toward Bret Victor's “Learnable Programming”” · View on HN