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

141–150 of 187 posts

Re: React/JavaScript fatigue

#141

Post by zachrose »

MatthewPhillips wrote: post #135
zachrose wrote: post #58

Earlier quoted context omitted.

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…

That's fine if my application is a game of solitaire. But what happens when I want to distribute it as a component, ? I can't, because it's not self-contained.

You could package and SolitaireGame together and distribute that? For somebody who just wants to drop a game of solitaire on their page that would work.

Re: React/JavaScript fatigue

#142

Post by Tankenstein »

hellofunk wrote: post #120
Lazare wrote: post #91

Earlier quoted context omitted.

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…

>Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support. But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm n…

He is referring to the fact that his language of choice, es6, will be running natively in chrome, since it's just new javascript.

Re: React/JavaScript fatigue

#143

Post by Tankenstein »

ocean3 wrote: post #65
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…

Why not just npm scripts instead of webpack/grunt/gulp?

Because just bash would be insane to get the features of something like webpack or gulp.

Re: React/JavaScript fatigue

#144

Post by substack »

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…

Webpack doesn't have a monopoly on hot reloading, you can do this in browserify too: `npm install browserify-hmr`

With watchify:

  watchify -p browserify-hmr -o bundle.js
With budo:

  budo main.js -p browserify-hmr
If you're using react, you'll only need a tiny wrapper around the root element to opt in to hot reloading: https://github.com/substack/react-starter-hmr/blob/master/ma...

All of this should fit comfortably in a Makefile (or npm run script) and each piece you add is small and comprehensible.

Re: React/JavaScript fatigue

#145

Post by bphogan »

DCoder wrote: post #94
bphogan wrote: post #67

Earlier quoted context omitted.

> 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 de…

Sure but they all end up being used as a build tool. Webpack may be a module bundler, but it has hot reloading, live reloading, and plugins to transpile. Watch any React tutorial and the first thing they have you do is set up a Webpack config that gives you a live-reloading build system with ES2015. And it's a different one than the one I used 5 months ago.

It's nice that there are people willing to address problems, but it would be nice for web development to grow out of its "oooh shiny" phase.

Re: React/JavaScript fatigue

#146

Post by ebola1717 »

dev360 wrote: post #131
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…

"Two or three files" can also be a terrible idea if a project mushrooms. Nobody wants to wade around 2000 loc files just because its missing tooling, but I can def see your argument.

We have 1 file per react component, and keep our files down to < 200 loc (and we're still using es5). As long as you define your components before mounting any of them, you don't have to worry too much about dependency order.

Re: React/JavaScript fatigue

#147

Post by yogthos »

ilostmykeys wrote: post #82
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 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…

This is a really strange line of argument. While core.async is popular, nothing precludes you from using other libraries such as promesa https://funcool.github.io/promesa/latest/ that have semantics you seem to prefer.

Second, ClojureScript has great interop with Js, so there's absolutely nothing stopping you from using a Js library/feature if you so choose.

>And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types.

It boggles my mind that somebody could see this as a positive. The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png).

I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving.

Re: React/JavaScript fatigue

#148

Post by yogthos »

ilostmykeys wrote: post #139
Skinney wrote: post #134

Earlier quoted context omitted.

Install an exception handler on the channel or return exceptions on the channel. The latter is more common. I've written my own macros to make the latter case pleasant ( (defmacro go-catching [& body] `(go (try ~@body (catch js/Error e# e#)))) (defmacro Used like this: (go-catching (<? (async-fn)))

Can you expand that to the concurrent scenario? Show us how you implement this simple and very common concurrent pattern with ClojureScript. I've seen stuff that implement this in ClojureScript and it ain't pretty (to say the least) Impress me! :) In ES7: async function fAsync() { try { var results = await Promise.all([asyncOpA, asyncOpB, asyncOpC]) } catch (e) { ... } }

impressed? :) https://funcool.github.io/promesa/latest/#error-handling

Re: React/JavaScript fatigue

#149

Post by ilostmykeys »

yogthos wrote: post #147
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…

This is a really strange line of argument. While core.async is popular, nothing precludes you from using other libraries such as promesa https://funcool.github.io/promesa/latest/ that have semantics you seem to prefer. Second, ClojureScript has great interop with Js, so there's absolutely nothing stopping you from using a Js library/feature if you so choose. >And now that we have decorators, typed data structures, it…

promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both? I'd recommend checking oit ESLisp on github, although they're still working on adding ES6/7 support.

To each their own Dimitri :) i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await. Haskell is cool and so is Elm but all of these will ultimately be copied in pieces by the most dominant language on the web (JS) so it's easier to be on the receiving end of all that goodness as opposed to being stuck in any of those niche languages. Appologies. It's just my opinion.

Re: React/JavaScript fatigue

#150

Post by [deleted] »

yogthos wrote: post #148
ilostmykeys wrote: post #139

Earlier quoted context omitted.

Can you expand that to the concurrent scenario? Show us how you implement this simple and very common concurrent pattern with ClojureScript. I've seen stuff that implement this in ClojureScript and it ain't pretty (to say the least) Impress me! :) In ES7: async function fAsync() { try { var results = await Promise.all([asyncOpA, asyncOpB, asyncOpC]) } catch (e) { ... } }

impressed? :) https://funcool.github.io/promesa/latest/#error-handling

[deleted]
Post reply on HN