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

111–120 of 187 posts

Re: React/JavaScript fatigue

#111

Post by zodiac »

hoodoof wrote: post #60
NDizzle wrote: post #51

Earlier quoted context omitted.

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

I completely agree with your characterization of how beginners can feel. That said,

> 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

It's not simply a choice between "learn for 6 months" and "use whatever the latest thing is". You seem to be advocating for the later, which I think is just as unworkable a solution as the former. For instance, a nice medium ground would be to read the github README as well as the front-page website of the candidates.

Also, as someone else here pointed out, you can't kill off gulp/grunt even if webpack exists, because webpack is not a task runner, and some people use the task-runner features of gulp to do more than combine modules, etc.

Re: React/JavaScript fatigue

#112

Post by dev360 »

scope wrote: post #89
awolden wrote: post #79

Earlier quoted context omitted.

Client: I need a modification to this cabinet so I can put in a double stove. Carpenter: Welp, we are gonna have to demolish the whole kitchen. So with the estimate of a full kitchen remodel you are looking at $80k Client: ...

I guess my analogy is being scrutinized (so to speak), that being said; YES!, that WILL happen if the carpenter doesn't know any better (or is a crook). A smart / savvy (or whatever you want to call it) carpenter will easily do the modification[S] without tearing down the entire kitchen. Just like you can drop React into an existing project.

Enough ketcheh! Let's talk Jabascript gais!

Re: React/JavaScript fatigue

#113

Post by reinhardt »

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 don't care if that opinionated path changes every month

Good for you, you'll feel right at home because that's exactly what's happening in JS-land, and it's a major reason many of us opt to stay the hell away from such a fad-driven development ecosystem.

Re: React/JavaScript fatigue

#114

Post by frik »

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 JavaScript5 came along. A new wave of JS5 vanilla style influenced by JS5 and Crockford's book got traction and more and more replaced JQuery (2010 onwards). HTML5 browsers got widespread, the JS performance got a lot faster (JIT VMs) and attracted a lot more developers.

CoffeeScript and new single-page frameworks like AngularJS and Ember.js got popular ca. 2012.

Google initially focused on Dart language as a replacement for Javascript and later transpiled to JS (beside others). Microsoft aquirehired ex-IBM group now known as Monaco code editor (VS Online, VSCode, etc) and created TypeScript that suits their C++/C# massive code base and coding pattern better. They influenced the development of ES6/7 to include "classes" syntax, etc.

Google added "Shadow DOM" feature to Chrome and proposed it as a new HTML5 feature. http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

Shadow DOM hasn't been integrated in other browser (http://caniuse.com/#feat=shadowdom ) though Facebook thought the idea was good ("Virtual DOM") and re-implemented the idea as JavaScript library; what is now known as ReactJS framework (got popular in 2014).

On the otherside NodeJS with NPM and its ecosystem of many tiny libraries got popular in 2011.

ES6/7 got popular on server and client side (though later still needs a transpiler step).

So we are again with huge JS framworks on the client side (1MB minified JS files are common but not funny on mobile devices). And highly modular small libraries on the server side (NodeJS).

Probably in time when full ES6/7 and Shadow DOM support gets traction in all modern browser, we will see another wave of more lean vanilla ES6/7 code without the huge libraries. You can write a super responsive and fast JS web app in less than 300KB code. You ask for trouble with your 1+MB JS file, especially on mobile devices that will crash or the users has to wait 30+sec on a cellular connection.

Lean vanilla JavaScript is great and high performant. Over-engineered frameworks make your life easier to start but will make it harder to stay in touch and maintain. Hopefully ShadowDOM browser support gets traction.

Re: React/JavaScript fatigue

#115

Post by AKifer »

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…

Agree with that attitude, you'll never have enough neurons to follow all the things released. The key is to pick only the minimum you need and forget about the rest. Anyway, as Knuth says, premature optimization is the root of all evils.

Re: React/JavaScript fatigue

#116

Post by frik »

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…

I agree with your standpoint (first two paragraphs).

> Intercooler.js

Why not '' (HTML5 data-* attributes feature!) instead of the non-standard '' ? http://caniuse.com/#feat=dataset

Re: React/JavaScript fatigue

#117

Post by chvid »

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…

Exactly.

The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."

Re: React/JavaScript fatigue

#118

Post by fenomas »

tptacek wrote: post #39
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…

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

Webpack isn't really plumbing like a task runner, it's primarily a dependency wrangler. If you have a page template, which declares dependencies on various partials, each of which declares dependencies on images and JS modules and CSS partials, then Webpack can grok all those dependencies and do things like bundling the images/JS/CSS needed for this or that subset of pages (along with hot loading, source maps, etc.).

Of course, it can also do stuff like minification and transpilation while it does this, so it tends to get compared to grunt/etc. But the magic of webpack isn't the bundling, it's that you can build highly modular pieces of web content and leave webpack to work out what needs bundling.

Re: React/JavaScript fatigue

#119

Post by Skinney »

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…

> The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO...

False. React can be rendered on the server and sent in the initial request using ReactDOM.renderToString.

> You hate maintaining an entire application in Javascript...

No I don't. I'd rather write an entire application in JS than write an application (backend and frontend) in two different languages, or write a frontend as a series of ad-hock JS scripts. If I hated maintaining an entire app in JS, why would I maintain it using JS? I use JS for everything because I prefer it to the alternatives.

> a simple CRUD application for which client side rendering is unnecessary.

No one needs to do an SPA. The world got by just fine without it. For me, the reasons to do an SPA with ES2015 modules had to do with simplifying my frontend architecture. JQuery is easier to get wrong compared to the render-everything mindset of React.

> Google doesn't use AngularJS for Gmail.

Good for them. Angular sucks IMHO. That being said, Gmail came long before Angular, and why migrate when you have a working product?

> Facebook doesn't use ReactJS for Facebook.

Facebook doesn't use ReactJS for --everything-- on Facebook. The fact that React can be gradually migrated into an existing application is one of React's greatest strengths.

Facebook do, however, use React for Instagram. They even use webpack for this.

> Twitter doesn't use client side rendering.

Define client side rendering. When I scroll down on the page and new items magically appear, I would say that is client side rendered. The time to first see the content, using React, could be done by first rendering React on the backend. But why migrate when you got a working product?

> People are building a mountain of abstractions and investing so much time to over-engineer everything in Javascript. WHY?!

Is it over-engineering when it solves a problem and does nothing more than it has to? React renders views, that's it. You can render on the frontend, backend or both. React is easier to use than having many different JQuery-based scripts.

In short. React does one thing. It does it well, and it simplifies my UI code. How is this over-engineering? I could say the same for gulp (for me, easier than bash scripts), webpack (easier than makefiles), ( node+express (waaaaay easier than Java or C#), Immutable.js (makes things easier to reason about) and the rest of my pure JS-stack.

Re: React/JavaScript fatigue

#120

Post by hellofunk »

Lazare wrote: post #91
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…

>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 not sure what exactly you are referring to.

Post reply on HN