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

131–140 of 187 posts

Re: React/JavaScript fatigue

#131

Post by dev360 »

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…

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

Re: React/JavaScript fatigue

#132

Post by mbrock »

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.

Maybe not. I don't mind, I have incremental search. For me, wading around 200 files in subdirectories is more tedious. But it seems to be a matter of preference.

Re: React/JavaScript fatigue

#133

Post by jskulski »

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…

Exactly. My experience with JS (which is entering non-trivial amounts) has been this:

Either get a boilerplate, generator or spend frustrating afternoons configuring to the start line. Then once you start work spend hours reading docs to figure out what all that stuff you installed actually does.

OR

Build from scratch, build the simple stuff, then when your brain says 'hey someone must of done this', look for a library and plug it in. Then at least you understand a general idea of what you're installing.

An over simplification, of course, but building rudimentary routers, event managers, mvc structures etc helped me immensely.

Re: React/JavaScript fatigue

#134

Post by Skinney »

ilostmykeys wrote: post #128
Skinney wrote: post #108

Earlier quoted context omitted.

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

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

Re: React/JavaScript fatigue

#135

Post by MatthewPhillips »

zachrose wrote: post #58
MatthewPhillips wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: React/JavaScript fatigue

#137

Post by moonchrome »

SureshG wrote: post #126
moonchrome wrote: post #13

Earlier quoted context omitted.

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

Looking at that module : https://www.dartdocs.org/documentation/js/0.6.0/

The only documentation is bare-bones examples - 0 docs about conversion between dartjs objects/collections/closures etc. when crossing JS interfaces. You will agree that this is an area which requires very precise description of semantics - after all we are bridging two dynamic languages with two incompatible object interfaces one on top of the other - reverse engineering the semantics sounds like a nightmare.

From here : https://github.com/dart-lang/js-interop-deprecated I was able to find this : https://docs.google.com/document/d/1X0M7iQ1PraH50353OnjKidgr... which was last updated in 2014 and I'm not sure if it's relevant.

Re: React/JavaScript fatigue

#138

Post by onewaystreet »

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.

Being able to render your javascript server side with isomorphic (or universal) javascript is one of React's big selling points.

Re: React/JavaScript fatigue

#139

Post by ilostmykeys »

Skinney wrote: post #134
ilostmykeys wrote: post #128

Earlier quoted context omitted.

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

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) { ... } }

Re: React/JavaScript fatigue

#140

Post by tptacek »

modarts wrote: post #55
tptacek wrote: post #42

Earlier quoted context omitted.

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?

It has nothing to do with them being a "beginner".
Post reply on HN