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

91–100 of 187 posts

Re: React/JavaScript fatigue

#91

Post by Lazare »

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 was hired to write JS code on a team of people who know JS, by a company that is comfortable writing significant chunks of code in JS. If I try and check in some Clojure into our repo, I'll fail code review. If I suggest adopting Clojure on a new project, it'll be shot down. And for good reason; nobody here knows Clojure, we're not a Clojure shop, we don't even know the right questions to be asking about risks and issues of adopting Clojure, much less the answers.

If we were going to adopt a new language, I think I could make a solid case for Typescript that might get accepted. I could see making a case for Elm or Purescript, but I don't think either will fly. But Clojure is a lot further out there in terms of adding it to an existing team of PHP/JS/HTML/CSS devs.

In addition, while you note that the JS ecosystem is basically just playing catchup with Clojure, it is (slowly!) catching up. More to the point, ES6 is the future of browsers; we're using Babel and polyfills as a stopgap, but the code we're writing is code which is increasingly capable of running on the browsers on our dev machines. Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. JS, as a language, is getting better, JS build tools are getting better, and the JS ecosystem is getting better. It may have a long way to go, and it may be slow, but it's getting there. From where I stand, the gap between JS and Clojure is just going to get narrower (it's always easier to copy than innovate after all). Why shouldn't I just wait and get the benefits for free?

(Disclaimer: I love the idea of Clojure, and I actively looked for Clojure/Clojurescript jobs the last time I was on the market. But what I found was a job writing ES6/React/Redux, which is almost as good as the hypothetical Clojure job, and has the advantage of existing.)

Re: React/JavaScript fatigue

#92

Post by sotojuan »

lsdafjklsd wrote: post #52
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 diff…

Question (from a newbie): Why didn't you stay with Ember, now that it has a similar engine as React yet comes with a CLI tool and strong community conventions that get rid of any build tool frustrations?

Re: React/JavaScript fatigue

#93

Post by sotojuan »

bsuh wrote: post #90
jkldotio wrote: post #64

Many of the newer Javascript libraries seem massively over-engineered compared to what you actually gain over using jQuery, or even just plain Javascript. I don't want to detract from the complexity of what some of these frameworks can achieve but at the same time it's not like they are doing complex 3D or machine learning. For me it's about readability and maintainability. I can come back to a program weeks, months…

It seems like no one asks "Just because we can use Javascript for everything, should we?" Pros: AJAX for loading content makes requests smaller making your app more performant. Cons: The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO, and breaking the back button (no, I don't want to scroll again from the top through the 5 posts I already r…

> Facebook doesn't use ReactJS for Facebook. They use PHP to render HTML on the server.

This is false. Facebook is a huge user of React—it's one of their "pros" over Angular (which Google doesn't use as much).

The entire Instragram site is built with React, and all new development is with it[1], as well as parts of their existing UIs[2]. They are gradually replacing everything with it because redoing the whole site at once is impossible to do. They are also putting a ton of work into React Native and use it in some of their products [3].

Facebook seems to put some of their smartest engineers in the React and React Native teams as well as related projects like Immutable.js, and grab talent as quickly as they can (like Dan Abramov). It's silly to think that they're spending so much money on it for nothing.

[1] https://www.quora.com/Who-is-using-Facebook-React

[2] https://groups.google.com/forum/#!topic/reactjs/5K4fXu1aCTs

[3] https://facebook.github.io/react-native/showcase.html

Re: React/JavaScript fatigue

#94

Post by DCoder »

bphogan wrote: post #67
statictype wrote: post #53

Earlier quoted context omitted.

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…

> If I could get away with a Makefile, I probably would. You kinda can. I'm seriously considering that in conjunction with " rel="nofollow">http://entrproject.org/> for watching file changes. I wrote the book Automate With Grunt out of anger at the terrible docs for Grunt and my displeasure that there was yet another build system out there. And just as the book was released, Gulp came along. Then Webpack. And now the…

Nitpick - Grunt is a task runner, Gulp and Brunch are build tools, Webpack is just a module bundler, it's not a full build tool - it's more a replacement for r.js than for Gulp (and it's remarkably faster than r.js).

After trying out Grunt and Gulp, I found Gulp to be more to my liking because the tasks are written as actual JS code, not as a pile of configuration. Plus, it runs the tasks in parallel if they don't depend on each other, whereas Grunt defaults to running them sequentially.

Re: React/JavaScript fatigue

#95

Post by aidenn0 »

I use React, but I never jumped on all the other various projects surrounding React, because (as far as I could tell) none of them solved any problems that I was having.

Re: React/JavaScript fatigue

#96

Post by voltagex_ »

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…

>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.

Thank you!

I had to pick up Node.JS and npm for a project recently. Apart from it not working properly in an enterprise environment (NTLM proxy and interception certificates) there are so many things to remember on top of my normal Visual Studio knowledge.

I know Microsoft is moving in this direction with DNX and I think it's a good thing, but also could lead to a lot of unnecessary complexities. No one's going to miss XML-based project files though (sln and vcproj are being replaced by json files)

Re: React/JavaScript fatigue

#97

Post by gedy »

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…

I think it's due to Webpack replacing/eliminating much of what we used to do "manually" in Grunt/Gulp such as transpiling, building, combining, etc.

In most of my projects, I no longer needed Grunt for anything aside from deploying to production, etc.

Re: React/JavaScript fatigue

#98

Post by innocentoldguy »

G4BB3R wrote: post #14

Just use Elm instead of Javascript + Frameworks Simple, Fast, Reactive, Functional http://elm-lang.org

I agree. I've been using Elm on one of my current projects and my experience with it has been great. Of course, I do hate Javascript with a passion, so there's always that bias to consider.

Re: React/JavaScript fatigue

#99

Post by bsuh »

sotojuan wrote: post #93
bsuh wrote: post #90

Earlier quoted context omitted.

It seems like no one asks "Just because we can use Javascript for everything, should we?" Pros: AJAX for loading content makes requests smaller making your app more performant. Cons: The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO, and breaking the back button (no, I don't want to scroll again from the top through the 5 posts I already r…

> Facebook doesn't use ReactJS for Facebook. They use PHP to render HTML on the server. This is false. Facebook is a huge user of React—it's one of their "pros" over Angular (which Google doesn't use as much). The entire Instragram site is built with React, and all new development is with it[1], as well as parts of their existing UIs[2]. They are gradually replacing everything with it because redoing the whole site a…

I didn't mean to imply Facebook doesn't use ReactJS at all. The point was they use it on a need by need basis, not all in SPA all the time.

Re: React/JavaScript fatigue

#100

Post by sotojuan »

bsuh wrote: post #99
sotojuan wrote: post #93

Earlier quoted context omitted.

> Facebook doesn't use ReactJS for Facebook. They use PHP to render HTML on the server. This is false. Facebook is a huge user of React—it's one of their "pros" over Angular (which Google doesn't use as much). The entire Instragram site is built with React, and all new development is with it[1], as well as parts of their existing UIs[2]. They are gradually replacing everything with it because redoing the whole site a…

I didn't mean to imply Facebook doesn't use ReactJS at all. The point was they use it on a need by need basis, not all in SPA all the time.

Ah I see. Sorry for misreading. Still better than Angular's situation though, and I'd argue React Native is more important/more likely to be fully used at Facebook.
Post reply on HN