Live data from Hacker News

React/JavaScript fatigue

medium.com

71–80 of 187 posts

Re: React/JavaScript fatigue

#71
post #30

there's NO fatigue, it all depends on YOU & how you're willing to LEARN continuously Let's put it like this, there are many ways to build a house, but you don't see a builder without at least hammer & nails right? One day you see another builder with a nail gun, do you ask the builder about the machine or do you keep building a house using JUST hammer & nails? After sometime, you see another builder building a house…

The flaw with this analogy is that when you need to revisit the house you built with a hammer and nails, you can continue using your nail gun. In S/W development, you have to go back to using the hammer and nails (or at the very least have a strong understanding of the hammer and nails). Furthermore, once you've built a house, it's built, and the work you will be doing on it will be minimal. Software development is a…

> The flaw with this analogy is that when you need to revisit the house you built with a hammer and nails, you can continue using your nail gun.

Say clients wanted a kitchen completely remodeled, you still don't have to use hammer and nails or nail gun --- I could easily demolish the kitchen and 3D print the new kitchen

What you know/done before doesn't necessarily dictate what you'll [can] do (which is the case on the Web)

Re: React/JavaScript fatigue

#72
post #39

Earlier quoted context omitted.

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

In order to be sold on webpack you need to understand the stack of problems it solves. I tried to do this during a talk last year; the relevant part is https://youtu.be/VkTCL6Nqm6Y?t=9m39s

What do you think about jspm and systemjs - the way it separates front end vs back end dependencies and generates a config.js was very nifty.

Re: React/JavaScript fatigue

#73
post #42
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.

I think it sums up the Beginner Community in general, not the JS community. You see this with beginners in everything.

Re: React/JavaScript fatigue

#74
post #60
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…

You admitted to being a beginner - a beginner shouldn't be recommending technology choices beyond that a particular choice might help people get started. There is too much a beginner does not know was his/her point.

Re: React/JavaScript fatigue

#75
post #70
post #9

This is something I have observed about every language/framework front end combo I have ever used and I have done it long enough to go all the way back to Qt 3 and even before. There is no terse way to describe a UI. Period. C++ or Java I understand they are typed languages with an avowed aim of giving the programmer fine grained control over the program. Objective C may have become popular more recently but it too i…

The last time I felt productive doing UIs was with WinForms and before that VB6.

At the end of the day, this is what the web community will ultimately end up re-inventing.

https://polymer-designer.appspot.com/

Re: React/JavaScript fatigue

#76
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…

Also you don't really need to use a flux library or Redux if you're using Reagent, it's pretty much all set up for you.

I've been using ClojureScript/Reagent for about a year now and all this JS tooling talk goes way over my head, I haven't needed to use any tooling other than lein cljsbuild for a while now, and it's glorious. If the Clojure community / ClojureScript was more approachable to beginners I think ClojureScript would be taking over right now.

Re: React/JavaScript fatigue

#77

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…

You say it's about maintainability. Well, that's the whole point of frameworks. Your team grows, your app gets bigger, time to add some more structure to your code. Extract the common patterns into re-usable modules. Enforce conventions. Eventually, in your quest against frameworks, you have created a framework. Except probably worse, and with no documentation.

Take React for example. It's not over-engineered. React is fantastic. I can't imagine how we would have build some of our UI without it. But you're right that there's a bunch of cruft/overhead that comes with it too. Build tools are hard to setup. Front-end architectures are in their infancy. In this sense, it's under-engineered rather than over. I just don't see where the fact that awesome frameworks are hard to use turns into the idea that they are "massively over-engineered".

Re: React/JavaScript fatigue

#78
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…

Isn't Om Next built on ideas pioneered in Relay and Falcor, not the other way around?

Re: React/JavaScript fatigue

#79
post #71

Earlier quoted context omitted.

The flaw with this analogy is that when you need to revisit the house you built with a hammer and nails, you can continue using your nail gun. In S/W development, you have to go back to using the hammer and nails (or at the very least have a strong understanding of the hammer and nails). Furthermore, once you've built a house, it's built, and the work you will be doing on it will be minimal. Software development is a…

> The flaw with this analogy is that when you need to revisit the house you built with a hammer and nails, you can continue using your nail gun. Say clients wanted a kitchen completely remodeled, you still don't have to use hammer and nails or nail gun --- I could easily demolish the kitchen and 3D print the new kitchen What you know/done before doesn't necessarily dictate what you'll [can] do (which is the case on t…

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

Re: React/JavaScript fatigue

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

Post reply on HN