React/JavaScript fatigue • Hacker News Board

Re: React/JavaScript fatigue

#51

Post by NDizzle » Mon, Dec 28, 2015, 5:08 AM UTC

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…

Don't take this the wrong way - I mean this with the most respect possible.

You shouldn't be recommending software to anyone.

Re: React/JavaScript fatigue

#52

Post by lsdafjklsd » Mon, Dec 28, 2015, 5:08 AM UTC

modarts wrote: post #49

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…

I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super difficult

Re: React/JavaScript fatigue

#53

Post by statictype » Mon, Dec 28, 2015, 5:09 AM UTC

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…

Things should remain backward compatible but only for a very short window, it's really unhelpful to have many many different ways of doing the same thing, it fragments everything including the learning curve. Witness Perl.

Sounds like a terrible way to build commercial software.

The problem isn't that old things don't die away quickly - far from it - the problem is that we have too many new things coming in that keep changing every few days.

I'm building a 10k line coffeescript app that works on top of react. All I care about is getting a toolchain to compile the coffeescript and generate source maps.

I don't care about dicking around with npm and node and grunt other than to make the build process work.

Tell me why I should care about grunt or gulp or webpack?

React introduces a massive win over traditional ways of building UIs that makes learning how to write apps with it worth learning. Why should I care about learning grunt and then learning gulp and then learning webpack, when all I'm using it for is to compile my coffeescript?

If I could get away with a Makefile, I probably would.

Re: React/JavaScript fatigue

#54

Post by spicyj » Mon, Dec 28, 2015, 5:09 AM UTC

carbocation wrote: post #50

spicyj wrote: post #48

Earlier quoted context omitted.

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.

You still have the round-trip time for each level of dependencies if they're resolved on the client, at the very least. And a real-world performance comparison where the recursive dependencies are listed up front but sent in separate requests shows unbundling losing:

http://engineering.khanacademy.org/posts/js-packaging-http2....

Re: React/JavaScript fatigue

#55

Post by modarts » Mon, Dec 28, 2015, 5:10 AM UTC

tptacek wrote: post #42

hoodoof wrote: post #40

Earlier quoted context omitted.

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.

You take the struggles of a beginner as an indictment on the broader professional JS development community?

Re: React/JavaScript fatigue

#56

Post by spicyj » Mon, Dec 28, 2015, 5:12 AM UTC

tptacek wrote: post #42

hoodoof wrote: post #40

Earlier quoted context omitted.

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.

I believe (and hope) this is not representative of the JS community.

Re: React/JavaScript fatigue

#57

Post by leo_mck » Mon, Dec 28, 2015, 5:14 AM UTC

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…

I do not think any way of doing things should be killed. People should educate themselves to be able to choose the tool they feel comfortable to do what they need. It is simply as that. If the old tools work and you like them, use them. If you are a beginner and do not know what tools you should use it is your problem. I agree that the things could be better but I think that this idea of making everything super easy for beginners is not a thing we should always focus first. I do not meant to sound harsh but I do not know if things could be much better considering all the things happening with JS on the last years.

Re: React/JavaScript fatigue

#58

Post by zachrose » Mon, Dec 28, 2015, 5:16 AM UTC

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?

The "separation" between your business logic and your view logic is really better thought of as a decoupling.

Let's say for example that your application is a game of solitaire. Rendering the cards is a view concern. Interpreting UI events as game actions is a view concern. Accepting or rejecting those game actions is business concern. Animating that acceptance or rejection is a view concern. Persisting or restoring your moves or game state to an API is a business concern with some networking glued to the side of it.

That's sort of a trivial example, but the event catalog for your application might look like this:

A move event would result in a new state event or a rejection event. Your rendering components don't need to know how that happens or who controls the state. Your core components don't need to know if this game is being played on a server or a browser. Your move events might come from a swarm of multiple players. An analytics component can listen to the bus and fire off things that it's looking for.

Re: React/JavaScript fatigue

#59

Post by Scarbutt » Mon, Dec 28, 2015, 5:17 AM UTC

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…

Damn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still?

Because browsers don't fully support ES2015 yet? not everyone wants to use/learn new buggy transpilers, new build tools, add more boilerplate, etc..

Re: React/JavaScript fatigue

#60

Post by hoodoof » Mon, Dec 28, 2015, 5:18 AM UTC

NDizzle wrote: post #51

hoodoof wrote: post #40

Earlier quoted context omitted.

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…

Don't take this the wrong way - I mean this with the most respect possible. You shouldn't be recommending software to anyone.

I'm sorry you feel that way.

I know a huge amount about software development and work with a wide range of technologies.

Learning some completely new field like browser based development is best done by just jumping in and trying to make stuff work. You learn along the way and much of it will be unfamiliar. Over time things will become more and more familiar until you start to develop expertise across the entire field.

If you are suggesting that instead I should learn by sitting down for six months in an ivory tower and learn all the theory and function of every part of the software ecosystem that I plan to work with so that I can then take every step of my journey as an expert, then you are misguided.

All software developers live in a fog of ignorance which they work to push back. No one knows everything. The best way to push back the fog of igorance is to start working with the technology to get real stuff done. To do so, it is necessary to make pragmatic decisions such as "well it looks like everyone in this field is using technology X - so that's what I'll use until I know enough to decide otherwise".

Are you someone with a deep knowledge of JS and react development? If yes, did you step in to it as an expert in all things? Did you use things without knowing why? Of course you did. Everyone has to.