React/JavaScript fatigue • Hacker News Board

Re: React/JavaScript fatigue

#121

Post by dclowd9901 » Mon, Dec 28, 2015, 8:46 AM UTC

jameslk wrote: post #102

I can hardly relate. Perhaps I got lucky, but my experience with the React ecosystem has not been painful. Coming from Angular previously ($watch? isolate scope?? transclusion???), it was a breath of fresh air. It might also be due to my avoidance of certain rabbit holes that are prevalent around React. One of those being the React community's love affair with immutability (immutable.js, Redux, etc). JavaScript is no…

There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?

Re: React/JavaScript fatigue

#122

Post by amorphid » Mon, Dec 28, 2015, 8:47 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.

The JavaScript "community" feels like more a large country.

Re: React/JavaScript fatigue

#123

Post by frik » Mon, Dec 28, 2015, 8:59 AM UTC

aikah wrote: post #2

previous discussion here : https://news.ycombinator.com/item?id=10796567

What we need is Shadow DOM support: http://caniuse.com/#feat=shadowdom

Re: React/JavaScript fatigue

#124

Post by Joeri » Mon, Dec 28, 2015, 8:59 AM UTC

frik wrote: post #114

It's interesting that first little JavaScript libraries and one-liners were popular in the 1990s. Then AJAX and large framework libraries like Yahoo YUI, Ext JS, Google Web Toolkit (GWT) got popular. Then JQuery a more lightweight library got popular. Then John Resig's (JQuery) book "Pro JavaScript Techniques" (2006). Later Douglas Crockford's book "JavaScript the Good Parts" (2008) were highly influential. HTML5 and…

The fat vs thin client cycle has been happening for far longer than web dev. It's been going pretty much since we have interactive computers. Neither strategy is really the right one, it depends on the context of what you're trying to do. If only all young programmers could be taught a history of programming class where they analyze old deprecated technologies that used to be popular, and form an understanding why they rose to prominence and why they faded away. Maybe we could avoid new generations making the same mistakes over and over again with different technologies.

Re: React/JavaScript fatigue

#125

Post by jameslk » Mon, Dec 28, 2015, 9:00 AM UTC

dclowd9901 wrote: post #121

jameslk wrote: post #102

I can hardly relate. Perhaps I got lucky, but my experience with the React ecosystem has not been painful. Coming from Angular previously ($watch? isolate scope?? transclusion???), it was a breath of fresh air. It might also be due to my avoidance of certain rabbit holes that are prevalent around React. One of those being the React community's love affair with immutability (immutable.js, Redux, etc). JavaScript is no…

There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?

I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant...). Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7c...) to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html

Re: React/JavaScript fatigue

#126

Post by SureshG » Mon, Dec 28, 2015, 9:09 AM UTC

moonchrome wrote: post #13

Bahamut wrote: post #3

This is probably my biggest criticism of React (and by extension similar such as Angular 2, although React's choice of JSX is a clear exacerbation of this problem) - the move towards more tooling is terrible for what should be something simple. HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. It is developers making things more complicated by having us use a…

Angular choses TS (well it's optional but so is jsx). This is also my no.1 pain point with typescript - they focus on the typechecking part only - you want new JS features ? Use custom js transpilers, polyfills, etc. This means setting up custom typings, build system, module loader, etc. JS land is just a huge mess to put it nicely because of th inherent problem with browser portability but its made much worse by the…

Reg dart js interoperability check - http://news.dartlang.org/2015/11/dart-113-brings-improved-ja...

Re: React/JavaScript fatigue

#127

Post by cageface » Mon, Dec 28, 2015, 9:15 AM UTC

mbrock wrote: post #107

lopatin wrote: post #61

I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other wonderful work being done by the community. It was just too much. And as a result I became happier and more productive. My passion is my pet project which uses JS, not the JS ecosystem itself. I'll wait a year for build tools to become easier and React archite…

When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to…

React is still pretty new and doesn't really proscribe anything beyond the view layer. So when people jump into it they go online to try to get an idea of how they should structure their apps they find a lot of buzz around things like Redux and React-Router. Those are both good tools but the combined learning curve for those + ES6 + Webpack + Babel can be pretty steep.

But, like you say, for a lot of apps you can start with a much simpler stack. I did the same thing when I was getting started. My "stores" were just simple JS objects with some subscribe methods. This worked well enough that I was able to focus on building my app and to see first hand how great the React model is for building UIs.

Re: React/JavaScript fatigue

#128

Post by ilostmykeys » Mon, Dec 28, 2015, 9:16 AM UTC

Skinney wrote: post #108

ilostmykeys wrote: post #82

Earlier quoted context omitted.

I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now. What nudged me out of my love affair with CLJS is when I needed to implement a really simple async patte…

> What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. What? Async/await in CLJS is: (defn async-fn [] (go true)) (go ( How is that syntactically and conceptually complicated compared to async/await?

Why don't you go further and try/catch that to make it usable in a real app? How do you handle async errors?

Re: React/JavaScript fatigue

#129

Post by mbrock » Mon, Dec 28, 2015, 9:23 AM UTC

cageface wrote: post #127

mbrock wrote: post #107

Earlier quoted context omitted.

When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to…

React is still pretty new and doesn't really proscribe anything beyond the view layer. So when people jump into it they go online to try to get an idea of how they should structure their apps they find a lot of buzz around things like Redux and React-Router. Those are both good tools but the combined learning curve for those + ES6 + Webpack + Babel can be pretty steep. But, like you say, for a lot of apps you can sta…

Yeah. I guess I'd recommend a patient approach of first making sure to learn what the library itself does, and then being cautious about importing too much stuff up front. Because that does lead to fatigue and confusion.

Re: React/JavaScript fatigue

#130

Post by Corrado » Mon, Dec 28, 2015, 9:27 AM UTC

masonicb00m wrote: post #80

Nodded my head all through the article. Project setup hurts. "What folder do I put my components in? Even the ones that only get used on one page?" We need a DHH.js to rise up and bring us "Rails, for React".

Opinionated programming was/is Rails' major contribution to the web world, as far as I'm concerned. By providing a baseline of things you need (directory structure, modules, logic flow, etc.) it made starting a project easy. In fact, it's just a single command.

I think having all of these (ever changing) options is a sign of Javascripts immaturity; it's not bad, it's just growing pains. Hopefully someone will step up with a cookbook of best practices which will be respected and used throughout the community.