``` Latest posts ``` isn't that div unnecessary?
Things every React.js beginner should know
191–200 of 247 posts
Re: Things every React.js beginner should know
#192Earlier quoted context omitted.
You can run "webpack-dev-server", which uses your Webpack configuration to serve your scripts with its own web server. That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (…
FYI, browserify has support for all the cool tricks you list too now; it's just a question of finding and wiring up all the right plugins. Eg, lessify, css-modulesify, or csvify will handle the cool require tricks, browserify-hmr does the fancy hot module replacement, watchify has incremental recompiliation support if you manage to configure it just right, etc. Mind you, I find webpack easier to configure (all the fa…
Re: Things every React.js beginner should know
#193I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?
$('').append($().text('...')).addClass('...').appendTo($('#selector'));Re: Things every React.js beginner should know
#194Earlier quoted context omitted.
When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at. > b) ids that indicate that a given tag will be replaced with a component With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. With JSX, keeping all of this c…
> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. > it sounds like one must imper…
Again, changing view to mean "template" is a strawman.
> Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons),
Separating state isn't the same as no state. Also imperatively updating the UI on state changes is stateful. Which increases complexity, which for most people makes code hard to reason about.
> but you can make that "always re-render the whole page" if that suits your use case
Anything can be made to do anything, so this point is moot. If this model was trivially applied, would it lead to flickering, lower performance, losing scroll position, losing selection, or losing input focus?
Re: Things every React.js beginner should know
#195What really bothers me about React (and other frameworks) that without JS you do not see anything. No fallback. No progressive enhancement. Is this really the way to go? Did JS replace HTML/CSS as the backbone of websites/applications ?
Re: Things every React.js beginner should know
#196Earlier quoted context omitted.
You describe ES6 as some kind of exotic dependency. Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default.
> You describe ES6 as some kind of exotic dependency. To the non Silicon Valley / Hacker News crowd, it certainly is. And using ES6 means you need to make a choice about which transpiler to use, which build tool to use, etc. > Actually once you get rid of ES6, the only dependencies in your list are immutable.js which is optional, and redux, which has become the well-known default. Well known to who, exactly? Because…
"Flux" was never a "well-known default," because there was no single "Flux" library - only Facebook's little written guide and an implementation of the dispatcher (a small part of the overall Flux architecture).
So, there were about 500 different implementations of "Flux" - none of which I'd say were ever considered a "well-known default" (the biggest ones - Reflux, Alt, Marty, Flummox, and Fluxxor - all have roughly between 1000 - 3000 stars on GitHub).
Then, Redux came on the scene and became the first and only "well-known default". Several of the Flux libraries I just mentioned actually deprecated themselves and put up notices to use Redux instead. As of the time of this writing Redux has almost 13,000 stars on GitHub.
Relay/Falcor are really part of an entirely different thing than React; they are about replacing the traditional REST API with an entirely new paradigm.
Re: Things every React.js beginner should know
#197Earlier quoted context omitted.
I'm a huge fan of Clojure's Hiccup library. It allows the user to make html like the following. Here's a function that always returns true - but it could do any kind of data access. It is just plain Clojure. (defn selected? [] true) Here is a datastructure that represents html: [:h2 {:class (when (selected?) "selected")} "Hello"] Calling the function hiccup.core/html on that datastructure yeilds an html string like t…
I love Clojure, but I'm tired of embedded DSLs, they're a dime a dozen. You can argue the benefits of Hiccup's syntax & s-expr all day, but it's still a different, and unpopular syntax for describing HTML. The ability to copy snippets of HTML from web, or old code when refactoring, or from Clojure/Hiccup to another language & framework, or changes from developer tool, or familiarity for new engineers, or not having t…
Re: Things every React.js beginner should know
#198I'm not a React or Angular expert, but do you really put HTML inside of your JS code? It just bothers me too much. We spent years in early web days learning that code and templates should be separate, yet here we are putting HTML inside of code, which goes against years of practice. Can anyone share their professional thoughts about this?
When I first began delving into reactive client interface frameworks. This was one of my biggest gripes. It looks, and reads like a giant confusing mess. I finally came across http://vuejs.org/ and I haven't looked back. Simple binding syntax to html elements, and powerful enough for most projects without being heavyweight. I mean it doesn't get any more straightforward than this. {{ message }} new Vue({ el: '#app',…
Re: Things every React.js beginner should know
#199So here we see the culmination of the great Frameworks vs. Libraries divide. Frameworks alleviate the need for the type of articles like the one linked here because they eliminate choice paralysis and imposter syndrome. Everyone is worried about whether or not they're doing things The Right Way™ and so they either blaze ahead and hit the same pitfalls everyone else does (and then write blog posts to warn others) or…
If widespread use in production by Facebook isn't real world enough for you, then perhaps it's best to find a slower-moving part of the stack.
Re: Things every React.js beginner should know
#200Someone sell me on Webpack? We use Browserify for no other reason than that someone gave me a boilerplate Gulpfile that relied on it. What part of my life would actually get better if I took the 4 hours of my life I will never get back to make this switch? Thanks!
You can run "webpack-dev-server", which uses your Webpack configuration to serve your scripts with its own web server. That means (1) it can do incremental recompilation, which I can't live without since my build takes 20 seconds; and (2) it can block requests while compiling, which is way better than having a background thing (e.g. watchify) recompile your code, since it means you're never interacting with a stale (…