Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React/JavaScript fatigue

medium.com

Post reply on HN
Print view View original

41–50 of 187 posts

Re: React/JavaScript fatigue

#41

Post by baddox »

MatthewPhillips wrote: post #36
baddox wrote: post #31

Earlier quoted context omitted.

Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state). Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, si…

How can I write reusable components if my domain logic must be separate from my view logic?

I was responding to a question about separating "the unique parts of your app" from other concerns like DOM and the network. I interpreted "the unique parts of your app" to be the way application state is represented and modified, which is a pretty reasonable definition for the common term "business logic."

Library-agnostic reusable components is another question, and certainly a good one. There doesn't seem to be a good answer right now. Web Components appears to be intended to solve that problem, but it isn't looking so good in my opinion.

I would probably go with a similar approach to reducers in Redux: a simple function that takes a state object and returns some library-agnostic representation of DOM. Of course there is no standard representation of DOM that I know of, but you could just output a plain JS object representing the DOM tree. There are probably many libraries out there offering a way to represent DOM that could easily to plugged into (with a simple wrapper) whatever new DOM rendering library is hot.

Re: React/JavaScript fatigue

#42

Post by tptacek »

hoodoof wrote: post #40
tptacek wrote: post #39

Earlier quoted context omitted.

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

My (simplistic) understanding is that webpack is more simple than grunt and gulp to configure. Backed up by my observation that most of the most current projects seem to be embracing it - that's enough for me, it's the current winner so it's what I use. I don't have time and I'm not interested in doing a detailed technical analysis - my approach is just to try to understand what technologies are the latest - and on t…

This response sums up something important about the Javascript development community that I cannot put into words.

Re: React/JavaScript fatigue

#43

Post by onewaystreet »

tptacek wrote: post #39
hoodoof wrote: post #33

The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell . How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even co…

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

http://survivejs.com/webpack_react/webpack_compared/

https://medium.com/@housecor/browserify-vs-webpack-b3d7ca08a...

Re: React/JavaScript fatigue

#44

Post by zachrose »

baddox wrote: post #31
zachrose wrote: post #25

I have a suggestion to this, but I don't know how to get it out there. I can't build a library because the point is to not depend on libraries. My suggestion is that if your going to build an application in the browser, your project needs an architecture that will last beyond today's libraries and tooling. You want to recognize what's unique about your app and express those parts without touching the DOM or network,…

Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state). Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, si…

Totally. But if I'm being extreme I would say that keeping your application state "memoized" into a single value may or may not be necessary for your application. If it's not, you've just coupled all of the data models in your application to into the same entity, which makes it easier to turn those couplings into dependencies, which makes them harder to test and use separately later.

Re: React/JavaScript fatigue

#45

Post by peterhunt »

tptacek wrote: post #39
hoodoof wrote: post #33

The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell . How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even co…

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

In order to be sold on webpack you need to understand the stack of problems it solves. I tried to do this during a talk last year; the relevant part is https://youtu.be/VkTCL6Nqm6Y?t=9m39s

Re: React/JavaScript fatigue

#46

Post by epoch1970 »

snaky wrote: post #29
pbhowmic wrote: post #9

This is something I have observed about every language/framework front end combo I have ever used and I have done it long enough to go all the way back to Qt 3 and even before. There is no terse way to describe a UI. Period. C++ or Java I understand they are typed languages with an avowed aim of giving the programmer fine grained control over the program. Objective C may have become popular more recently but it too i…

> There is no terse way to describe a UI Did you ever seen Tk?

Tk was only ever feasible for very simple, often throw-away, UIs, and not much more than that. Tk can't be compared to Qt or the other full-featured UI toolkits that exist.

Re: React/JavaScript fatigue

#47

Post by clessg »

hoodoof wrote: post #40
tptacek wrote: post #39

Earlier quoted context omitted.

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

My (simplistic) understanding is that webpack is more simple than grunt and gulp to configure. Backed up by my observation that most of the most current projects seem to be embracing it - that's enough for me, it's the current winner so it's what I use. I don't have time and I'm not interested in doing a detailed technical analysis - my approach is just to try to understand what technologies are the latest - and on t…

> webpack is more simple than grunt and gulp to configure

That's the first time I've heard that one. In my opinion, what makes Webpack great is its raw power and module-based (rather than file-based) focus. Browserify is easy to work with and get started with but less powerful. (Granted, it's quickly catching up.) Webpack is a lot of things, but easy to configure is not one of them.

By the way, Webpack doesn't really replace Grunt or Gulp. It replaces Browserify. That said, if you use Webpack, you can easily get by with npm scripts instead of Grunt/Gulp.

Re: React/JavaScript fatigue

#48

Post by spicyj »

tptacek wrote: post #39
hoodoof wrote: post #33

The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell . How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even co…

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

I am not sure why the parent compares webpack to gulp/grunt. The latter are generalized task runners (think "make"), but the former is a tool for bundling together many small JS files into one.

Webpack (and browserify, a competitor that's very similar) bring you a module system so that dependencies are explicit with a require() call and you don't have a global namespace with hundreds of objects. JS doesn't have any such system built in. Packaging it into one file in the end, which they do, is necessary for performance so you don't make hundreds of network requests.

Re: React/JavaScript fatigue

#49

Post by modarts »

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure?

- You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,)

- Don't need to bring a functional utility lib (lodash/ramda/etc)

- The build ecosystem revolves around a really solid piece of software in Leiningen (that has a ridiculously high level of adoption)

- Hot reloading (mainly through Figwheel) is simply magical (it's stable and "just works".) The amount of work to get a hot reloading environment setup and maintained with Webpack and various loaders is way too much, and often involves actual changes to application code to support it, which is unacceptable.

- The language itself is designed from the ground up to be functional

This is just what I can think of off the top of my head after a few glasses of wine, but there's a ton of reasons why we as JS developers should start taking a hard look at Clojurescript again.

Re: React/JavaScript fatigue

#50

Post by carbocation »

spicyj wrote: post #48
tptacek wrote: post #39

Earlier quoted context omitted.

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

I am not sure why the parent compares webpack to gulp/grunt. The latter are generalized task runners (think "make"), but the former is a tool for bundling together many small JS files into one. Webpack (and browserify, a competitor that's very similar) bring you a module system so that dependencies are explicit with a require() call and you don't have a global namespace with hundreds of objects. JS doesn't have any s…

Bundling JS files into one big file is obviated by http2.
Post reply on HN