10 ms·

React/JavaScript fatigue

174 points by pbhowmic 11y ago

aikah 11y ago
previous discussion here : https://news.ycombinator.com/item?id=10796567 https://news.ycombinator.com/item?id=10796567
- frik 11y ago
  What we need is Shadow DOM support: http://caniuse.com/#feat=shadowdom http://caniuse.com/#feat=shadowdom
Bahamut 11y ago
This is probably my biggest criticism of React (and by extension similar such as Angular 2, although React's choice of JSX is a clear exacerbation of this problem) - the move towards more tooling is terrible for what should be something simple. HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. It is developers making things more complicated by having us use a whole smorgasbord of tooling to optimize for using [insert feature] instead of trying to keep things as simple as possible. I just hope that over the next few years that this simplifies so that we don't need to have build tooling run everything.
- moonchrome 11y ago
  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 low barrier to entry community full of noise. I wish Dart had a better JS interop and faster compiler, in theory it solves all of my JS pains (excellent std lib, sane semantics, default package manager, modules from start, etc.) - in practice it produces big js files, compiling takes forever once you include frameworks, talking to JS is c ffi level of tedious (from what I understand they are working on improving it but its still non trivial with a significant performance overhead)
  - SureshG 11y ago
    Reg dart js interoperability check - http://news.dartlang.org/2015/11/dart-113-brings-improved-javascript.html http://news.dartlang.org/2015/11/dart-113-brings-improved-ja...
    - moonchrome 11y ago
      Looking at that module : https://www.dartdocs.org/documentation/js/0.6.0/ https://www.dartdocs.org/documentation/js/0.6.0/ The only documentation is bare-bones examples - 0 docs about conversion between dart<->js 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 https://github.com/dart-lang/js-interop-deprecated I was able to find this : https://docs.google.com/document/d/1X0M7iQ1PraH50353OnjKidgrd0EK6NpLNXVI27jitFY/edit https://docs.google.com/document/d/1X0M7iQ1PraH50353OnjKidgr... which was last updated in 2014 and I'm not sure if it's relevant.
- baddox 11y ago
  > the move towards more tooling is terrible for what should be something simple. I couldn't disagree more. I think the advances in tooling around web development is extremely exciting and absolutely necessary if we as an industry want to get our act together writing complex web applications. It's worse for getting new people into programming or web development, but there are always pretty simple drop-in scripts people can use to play with things like Babel, React, or even crazy stuff like full client-side module loading with SystemJS: https://gist.github.com/cem2ran/9be3dd3499566302d5ae https://gist.github.com/cem2ran/9be3dd3499566302d5ae > HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. I think that's extremely dismissive, and woefully underestimates the difficulties one faces building a complex long-lived web application.
bradhe 11y ago
I seriously don't understand the issue here. I find the overhead completely negligible. I've worked on many React apps. I've worked on innumerable apps in other, different frameworks, tools, etc. too. I still find my React stack (I say "my" because I'm sure my stack is different than yours in one way or another) to be the best solution, and this debate to be tedious. That said, I feel like every ecosystems works this way: Complaints about lack of good tools/solutions, myriad tools/solutions are built, then there are complaints about the overabundance of tools and complexity of the ecosystem, so everyone abandons whatever the status quo is, and then...back to square one.
- orf 11y ago
  > (I say "my" because I'm sure my stack is different than yours in one way or another) I think that's the problem. For a beginner what is their stack? It's a wild west of 'this months hip library' and for a beginner it's unintelligible.
  - bradhe 11y ago
    > It's a wild west of 'this months hip library' and for a beginner it's unintelligible. What's wrong with the "just pick one" approach??
    - pavel_lishin 11y ago
      Can you point me to one that'll help me actually get something workable up and running? You say you have one; I assume it's something you've put together over the time you've worked with React, and not something you just pull in from someone else's repo.
      - ocean3 11y ago
        I use very basic npm script with browserify to watch/build the output. browserify uses babelify transformer.
      - yazaddaruvala 11y ago
whistlerbrk 11y ago
The massive amount of great tooling and debugging for React is a strength not a weakness. If people are overwhelmed by React I feel it is likely because: 1. they haven't yet grokked the implications of how re-rendering every single time changes how they have to store the state of their app. (von neumman) 2. related to that, the choice of how to store that state and dispatch to a backend is not baked into React 3. it is harder to build an app up slowly because you have to have a rough idea of what the structure of your app state looks like ahead of time. So, you're forced to actually know more about your UI, UX, and design before you implement it. It takes longer to implement but once it is done, it's done and easy to improve upon - it's not fragile. For hacking something together it might not be the way to go. But for a well thought out implementation of an app which interacts a lot with it's backend, I think it's the only way to go now. I also feel like people will be missing the React wave at their peril. We're on the verge of being able to cleanly abstract out an applications delivery mechanism whether its native, mobile, or web. That is because of things like React and ReactNative and it's immutable render-every-time approach.
- capkutay 11y ago
  I think people try to get started with react and they jump to the boilerplates that are 'production ready'. Those boilerplates include routers, frameworks to bind routers to state, frameworks for server-side rendering, some new ES7 syntactic sugar, a bleeding edge module bundler like Webpack...the list goes on. They may or may not be a great combination of frameworks, but each has their own learning overhead. So people confuse learning react or learning redux with learning how to use every single framework shipped in the common react boilerplates. It can take weeks of studying or learning enough about those frameworks to understand how they all work. React itself is moving along at a healthy pace. Popular frameworks around react change about every week which causes this fatigue that OP speaks of. The most important thing IMO is learning the core concepts behind react, flux, redux, react-router, and worry about product client/server rendering and module bundling later.
- ilostmykeys 11y ago
  I was going say the same thing, a little differently. Only other comment is around having to know your entire app start up front. If you break up your app into micro apps each of which implement a given feature of your site then it's much easier to handle that way.
thirdreplicator 11y ago
I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and finally got a chance to come back to it. I made a couple of pages with vue.js, and I think there is a lot less stuff to do. There's no JSX. Your HTML peppered with vue.js directives is your templating language. There's no server side rendering, but that may be a good thing in the end. Fewer dependencies, less learning curve, less ecosystem to swallow in a single gulp. I hired a fresh grad from the Philippines, and he was able to pick it up and run with it immediately. I've only been using vuejs over Christmas, but I'm looking forward to seeing what else it can do. I'll post a small PHP-backed CRUD app if people are interested.
- onewaystreet 11y ago
  > gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.
  - Touche 11y ago
    After 300+ lines of config spread over 3 files.
  - sergiotapia 11y ago
    "Replace this garbage with this other newer garbage."
  - pavel_lishin 11y ago
    Doesn't that just glue them all together? We're using it at work, and we brought in an in-house React person, but I have no idea what the config does/signifies, and every time they change something, I absolutely don't understand why or how it works. (Our tests currently don't work. I mean, they can run - unless there's an error, in which case it exits early with a 0 status, without running any of the subsequent tests.) This is partially on me - I should read the shit out of the docs - but so far it seems like it just paints over the complexity a little.
pbhowmic 11y ago
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 is an older typed language. The unbrevity of JavaScript is inexcusable and it extends to every UI framework it offers. Tooling is no way to try and ease the problem.
- snaky 11y ago
  > There is no terse way to describe a UI Did you ever seen Tk?
  - epoch1970 11y ago
    Tk was only ever feasible for very simple, often throw-away, UIs, and not much more than that. Tk can't be compared to Qt or the other full-featured UI toolkits that exist.
- pixie_ 11y ago
  The last time I felt productive doing UIs was with WinForms and before that VB6.
  - laichzeit0 11y ago
    At the end of the day, this is what the web community will ultimately end up re-inventing. https://polymer-designer.appspot.com/ https://polymer-designer.appspot.com/
G4BB3R 11y ago
Just use Elm instead of Javascript + Frameworks Simple, Fast, Reactive, Functional http://elm-lang.org http://elm-lang.org
- innocentoldguy 11y ago
  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.
ebola1717 11y ago
Hm, I found that one of the strengths of React is that it's so easy to sidestep a lot of the complexity of it, if you're not building a true SPA. We use React to add some interactivity to our forms and dashboards, so we only need to use state & props. No Flux/Redux/etc backends, and not much messing around with webpack & co.
sudo_bang_bang 11y ago
Build tools are partly necessary because of how many old crusty browsers hang around out there. I mean, I still work on an app that has to support IE8. That's just ridiculous. As it is, ES6/ES7 imports make a lot of the issues of JS inclusion a thing of the past, but the build tools are necessary for packing these together and transpiling down to ES5, to support older browsers. The other tools you see in the React ecosystem do take time to learn for sure. The whole React/Flux paradigm takes a while but once you get it there's not many surprises. I do feel the fatigue though just as the author does. There's a million ways to do what the browsers should just do natively already. In a few years we hopefully won't have to worry about this anymore.
dcsan 11y ago
meteor works nicely with React. It may not be the most optimum route (problems with webpack, outdated node, crappy testing) but is a decent curated way to get started. The official react stack will be supported going forward, and the velocity of changes is not quite as much as the a-la-carte JS environment.
sergiotapia 11y ago
I was lucky that I started on React from within Meteor. Meteor builds everything automatically, and does not require you to spend 5 days tweaking a brittle series of config files. Last week, I wanted to start a React app that talks to a Phoenix API and found out there's a ton of different ways to create a react app. That sucks. There is no 'one obviously better way.' Kudos to Ember for being great in that area. React needs to have an obvious way to start and run an app. Not this gulpwebifypack config garbage Proof is in the pudding, check it out! http://sergiotapia.me/2015/09/18/react-and-meteor-match-made-in-heaven/ http://sergiotapia.me/2015/09/18/react-and-meteor-match-made...
chowes 11y ago
People jumped the Angular / Ember ship for React because those frameworks were too complex. Then they realized they needed additional features. Now there's a push to unify these features into a framework... You have to put your complexity somewhere.
- OSButler 11y ago
  I believe in Angular's case the changes from 1.x to the 2.x branch didn't help much either.
zachrose 11y ago
I have a suggestion to this, but I don't know how to get it out there. I can't build a library because the point is to not depend on libraries. My suggestion is that if your going to build an application in the browser, your project needs an architecture that will last beyond today's libraries and tooling. You want to recognize what's unique about your app and express those parts without touching the DOM or network, even if they seem trivial now. My particular favorite way to do that is using an event bus to create a catalog of custom/domain-specific events, with views emitting operation- or command-like events and internal models emitting new states. This is basically the important part of Flux without the special concepts (stores, dispatcher) that you may be fine without, and is already available in jQuery, Backbone, node's EventEmitter, and many other libraries out there. React and immutability and the rest of Flux are all very reasonable next steps if somehow you come to need them, but you are likely not spreading your UI development across hundreds of engineers. Unnecessary new stuff is just going to steer your conversations towards libraries and away from your domain.
- baddox 11y ago
  Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state). Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, since reducers are pure functions and actions are (or should be) simple JSON-able data. The actual rendering of state to DOM is done completely separately by registering callbacks that listen for application state changes. Of course, if you're using some other architecture to manage application state, results may vary.
  - MatthewPhillips 11y ago
    How can I write reusable components if my domain logic must be separate from my view logic?
    - baddox 11y ago
scope 11y ago
there's NO <insert language/framework/tool here> 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 without using nails at all After sometime, you see another builder 3D printing a house...
- sotojuan 11y ago
  Yeah, this is something I struggle with: Always trying to find something new to learn and not mastering anything. It is exhausting, but ultimately it depends on me. That said, to me the React ecosystem is the opposite of "convention over configuration" which can frustrate a lot of beginners. There's no popular `rails new` or `ember new` to get you started.
- addicted 11y ago
  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 almost the opposite.
  - scope 11y ago
    > 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)
    - awolden 11y ago
hoodoof 11y ago
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 come to understand that in the reactJS world they might be reading something relevant, but then again they might be reading something completely irrelevant and in compatible (i.e. ES2015 verus JS). Really when a new technology comes along that is a clear "winner", serious consideration should be given to just getting rid of the "old" way. Unless Grunt and Gulp are going to somehow make a big comeback, the should be loudly killed off. Damn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still? Old tech should be visibly and loudly killed. No wonder its hard for beginners - its all the damn noise made by the "old" ways of doing things. The react ecosystem is filled with the living dead - technology that has died but just won't go away. 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. Beginners (and I am one) don't need to be shown every possible way to do things - they need be given a rock solid, opinionated path on the current right way to get the job done. I don't care if that opinionated path changes every month, I just want to not have to work it out by fighting through two years of zombie tech to eventually figure it out.
- tptacek 11y ago
  Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.
  - hoodoof 11y ago
    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 the assumption that they are the latest because they are better, and on the assumption that previous technologies that did the same thing will be superseded - I use them. You can criticise this approach as just following the trends but I take this approach because it would be stupid to try to understand every single component of the ecosystem and then make my own careful choices - what is everyone else using right now? Probably good enough unless I know some good reason not to use it. I am a beginner and struggle hard to understand the vast array of tech I need to do reactJS development. It hurts me very badly sometimes and I feel stupid because I don't grasp it all, but I have to get shit built so for the most part I'm just doing what others are doing and as I go I am learning more and more and in areas that I have gained real understanding I then make my own educated decisions about exactly how to do it in the right way.
lsdafjklsd 11y ago
I think the problem is that the people using React see the grand architecture in Relay / Falcor / Om.next, and are trying to recreate those API's using current libs. There are still a lot of parts missing when you try to build an app with the same abstractions as the aforementioned libraries, and I think the author is correct about 2016 being a year where those gaps are filled. What we really need is a translation of om.next to javascript. That library summarizes all the good ideas from Netflix and Facebook into a small library for every day use. The fact that it's in Clojurescript makes it a non-starter for others, too bad because it's a really great eco-system. edit, list technologies: React + Redux is a good start, but we need composable queries and a router (falcor) or reconciler (om.next) that manages data fetching / caching. JLongster has done some experimentation here with datascript integration https://github.com/jlongster/redux-experiments/blob/master/static-queries-datascript/main.js https://github.com/jlongster/redux-experiments/blob/master/s...
modarts 11y ago
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 solid piece of software in Leiningen (that has a ridiculously high level of adoption) - Hot reloading (mainly through Figwheel) is simply magical (it's stable and "just works".) The amount of work to get a hot reloading environment setup and maintained with Webpack and various loaders is way too much, and often involves actual changes to application code to support it, which is unacceptable. - The language itself is designed from the ground up to be functional This is just what I can think of off the top of my head after a few glasses of wine, but there's a ton of reasons why we as JS developers should start taking a hard look at Clojurescript again.
- AlwaysBCoding 11y ago
  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.
  - yogthos 11y ago
    Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that: Install OpenJDK: http://www.azul.com/downloads/zulu/ http://www.azul.com/downloads/zulu/ Install Leiningen: http://leiningen.org/ http://leiningen.org/ Create a new project and run it: lein new reagent myapp cd myapp lein figwheel Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React. I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.
lopatin 11y ago
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 architectures to stabilize. Until then, my code won't be the holy grail of immutable flux, but my users will never know that. My re-builds take a couple seconds and I don't have hot code reloading. And I'm ok with that. I work with (what I consider to be) the bare minimum: React, Babel, Browserify, and fswatch. It's all wired together in my Makefile. It works pretty well. When something clearly needs improvement then I'll address it. Maybe I'll switch to Webpack and integrate hot code reloading to improve build times when I have some free time. But only as a luxury. I can get by without it. The above sounds easier for build tools than for JS architecture. After all, switching from Browserify to Webpack is a lot easier than refactoring your code from your existing setup to something like Relay, Om, etc... What I say to that is this: Gradually integrating flux (vanilla or Redux) into an existing React app is actually very simple. Extract local state, throw it into a store, and add a subscription. I wouldn't expect any refactoring headaches at all if your component hierarchy makes sense. Everything else (for example anything related to GraphQL, ClojureScript, you see where I'm going) counts as "not boring technology" and significantly increases the risk of being pulled back into the unproductive search of JavaScript enlightenment. I certainly don't want to discourage library authors in any way. If that's what you're passionate about then don't let my jaded thoughts stop you from building something great. We are in a period of great discovery, innovation, and change. I just wanted to share my thoughts about making a conscious effort to minimize my toolset and accepting the tradeoffs of not having the latest tech.
- voltagex_ 11y ago
  >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)
jkldotio 11y ago
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 or years after it is written; I most likely want to just be able to read, understand and edit it quickly. As soon as something has a huge infrastructure, setup, tooling, transpiling or whatever it just becomes burdensome. Intercooler.js (http://intercoolerjs.org/ http://intercoolerjs.org/) demonstrates a good philosophy.
- lopatin 11y ago
  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".
- bsuh 11y ago
  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 read when I come back to your site). You hate maintaining an entire application in Javascript so you get to learn all the joy of transpilers and a build system to build whatever not Javascript language you chose and your tens of module dependencies because you decided everything had to be done in Javascript or TypeScript or ES2015 or CoffeeScript or ES7. Oh and when a new language supersedes the language you decided to use, you happily spend weeks moving your codebase to a new language, thinking "Wow static typing in 2015?! My code is so much more maintainable now!" It says it all that the benchmark for comparing frameworks is TodoMVC, a simple CRUD application for which client side rendering is unnecessary. People are not thinking at all about the pros and cons of client-side rendering and reaching for it for any web applications. Google doesn't use AngularJS for Gmail. They use GWT to render HTML on the server. Side note: AngularJS 2 beta is 500KB. Fucking laughable. Oh and they suggest loading both the AngularJS 1 and AngularJS 2 frameworks on your page to help you migrate. Facebook doesn't use ReactJS for Facebook. They use PHP to render HTML on the server. Edit: Yes Facebook uses ReactJS for a lot of side stuff, but not for big items like their newsfeed. Twitter doesn't use client side rendering. They tried it but reverted, because the time to first see the content was too long. People are building a mountain of abstractions and investing so much time to over-engineer everything in Javascript. WHY?!
deleted 11y ago
[deleted]
masonicb00m 11y ago
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".
- lopatin 11y ago
  I put my components into app/components. This is the one, true directory structure. All other directory structures are wrong. \s
- Corrado 11y ago
  Opinionated programming was/is Rails' major contribution to the web world, as far as I'm concerned. By providing a baseline of things you need (directory structure, modules, logic flow, etc.) it made starting a project easy. In fact, it's just a single command. I think having all of these (ever changing) options is a sign of Javascripts immaturity; it's not bad, it's just growing pains. Hopefully someone will step up with a cookbook of best practices which will be respected and used throughout the community.
aidenn0 11y ago
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.
jameslk 11y ago
I can hardly relate. Perhaps I got lucky, but my experience with the React ecosystem has not been painful. Coming from Angular previously ($watch? isolate scope?? transclusion???), it was a breath of fresh air. It might also be due to my avoidance of certain rabbit holes that are prevalent around React. One of those being the React community's love affair with immutability (immutable.js, Redux, etc). JavaScript is not itself designed around the concept of immutability. Mixing the concepts has only led me to fight with the language and the existing ecosystem. Immutable patterns work best in a world where most things are immutable to begin with, not when you're trying to coerce a world of mutable tools to be immutable. I'll admit, walking on some of these landmines initially was pretty painful, but I've been working with large codebases in React (SPAs and projects with tens of thousands lines of code) that I feel I've discovered the right paths to take. Here's my takeaways for modern frontend projects using React: - Keep code organized in modules (a la CommonJS) so code doesn't become a big ball of mud. - Use React Router to enforce that organization. - Stick to vanilla JS- ES5/ES6/ES7--it's better documented. - Use Grunt, and then add in Gulp when needed, otherwise you'll be writing a lot more boilerplate. - Use Browserify, not Webpack--it doesn't try to do everything. - Use a reactive data paradigm to keep data flow simple (observables, e.g. Mobservable works really well) instead of Flux/Redux/*ux. - Stick to real CSS and use namespaces (or web components), not React's hijacked inlined version of it. These practices have helped the teams I've worked in get stuff done and have scaled quite well.
- dclowd9901 11y ago
  There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?
  - jameslk 11y ago
    I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant-a-baobab-tree-in-your-flux-application.html http://christianalfoni.github.io/javascript/2015/02/06/plant...). Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.t5fhdnhsc https://medium.com/@dan_abramov/smart-and-dumb-components-7c...) to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html https://mweststrate.github.io/mobservable/best/store.html
frik 11y ago
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/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd... Shadow DOM hasn't been integrated in other browser (http://caniuse.com/#feat=shadowdom 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.
- Joeri 11y ago
  The fat vs thin client cycle has been happening for far longer than web dev. It's been going pretty much since we have interactive computers. Neither strategy is really the right one, it depends on the context of what you're trying to do. If only all young programmers could be taught a history of programming class where they analyze old deprecated technologies that used to be popular, and form an understanding why they rose to prominence and why they faded away. Maybe we could avoid new generations making the same mistakes over and over again with different technologies.
hugozap 11y ago
Just do the simplest thing that works. This is the same hype as Angular 1 had. People will move on eventually.

174 points by pbhowmic 11y ago

aikah 11y ago

previous discussion here : https://news.ycombinator.com/item?id=10796567 https://news.ycombinator.com/item?id=10796567

frik 11y ago
What we need is Shadow DOM support: http://caniuse.com/#feat=shadowdom http://caniuse.com/#feat=shadowdom

Bahamut 11y ago

This is probably my biggest criticism of React (and by extension similar such as Angular 2, although React's choice of JSX is a clear exacerbation of this problem) - the move towards more tooling is terrible for what should be something simple. HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. It is developers making things more complicated by having us use a whole smorgasbord of tooling to optimize for using [insert feature] instead of trying to keep things as simple as possible. I just hope that over the next few years that this simplifies so that we don't need to have build tooling run everything.

moonchrome 11y ago
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 low barrier to entry community full of noise. I wish Dart had a better JS interop and faster compiler, in theory it solves all of my JS pains (excellent std lib, sane semantics, default package manager, modules from start, etc.) - in practice it produces big js files, compiling takes forever once you include frameworks, talking to JS is c ffi level of tedious (from what I understand they are working on improving it but its still non trivial with a significant performance overhead)
- SureshG 11y ago
  Reg dart js interoperability check - http://news.dartlang.org/2015/11/dart-113-brings-improved-javascript.html http://news.dartlang.org/2015/11/dart-113-brings-improved-ja...
  - moonchrome 11y ago
    Looking at that module : https://www.dartdocs.org/documentation/js/0.6.0/ https://www.dartdocs.org/documentation/js/0.6.0/ The only documentation is bare-bones examples - 0 docs about conversion between dart<->js 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 https://github.com/dart-lang/js-interop-deprecated I was able to find this : https://docs.google.com/document/d/1X0M7iQ1PraH50353OnjKidgrd0EK6NpLNXVI27jitFY/edit https://docs.google.com/document/d/1X0M7iQ1PraH50353OnjKidgr... which was last updated in 2014 and I'm not sure if it's relevant.
baddox 11y ago
> the move towards more tooling is terrible for what should be something simple. I couldn't disagree more. I think the advances in tooling around web development is extremely exciting and absolutely necessary if we as an industry want to get our act together writing complex web applications. It's worse for getting new people into programming or web development, but there are always pretty simple drop-in scripts people can use to play with things like Babel, React, or even crazy stuff like full client-side module loading with SystemJS: https://gist.github.com/cem2ran/9be3dd3499566302d5ae https://gist.github.com/cem2ran/9be3dd3499566302d5ae > HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. I think that's extremely dismissive, and woefully underestimates the difficulties one faces building a complex long-lived web application.

bradhe 11y ago

I seriously don't understand the issue here. I find the overhead completely negligible. I've worked on many React apps. I've worked on innumerable apps in other, different frameworks, tools, etc. too. I still find my React stack (I say "my" because I'm sure my stack is different than yours in one way or another) to be the best solution, and this debate to be tedious. That said, I feel like every ecosystems works this way: Complaints about lack of good tools/solutions, myriad tools/solutions are built, then there are complaints about the overabundance of tools and complexity of the ecosystem, so everyone abandons whatever the status quo is, and then...back to square one.

orf 11y ago
> (I say "my" because I'm sure my stack is different than yours in one way or another) I think that's the problem. For a beginner what is their stack? It's a wild west of 'this months hip library' and for a beginner it's unintelligible.
- bradhe 11y ago
  > It's a wild west of 'this months hip library' and for a beginner it's unintelligible. What's wrong with the "just pick one" approach??
  - pavel_lishin 11y ago
    Can you point me to one that'll help me actually get something workable up and running? You say you have one; I assume it's something you've put together over the time you've worked with React, and not something you just pull in from someone else's repo.
    - ocean3 11y ago
      I use very basic npm script with browserify to watch/build the output. browserify uses babelify transformer.
    - yazaddaruvala 11y ago

whistlerbrk 11y ago

The massive amount of great tooling and debugging for React is a strength not a weakness. If people are overwhelmed by React I feel it is likely because: 1. they haven't yet grokked the implications of how re-rendering every single time changes how they have to store the state of their app. (von neumman) 2. related to that, the choice of how to store that state and dispatch to a backend is not baked into React 3. it is harder to build an app up slowly because you have to have a rough idea of what the structure of your app state looks like ahead of time. So, you're forced to actually know more about your UI, UX, and design before you implement it. It takes longer to implement but once it is done, it's done and easy to improve upon - it's not fragile. For hacking something together it might not be the way to go. But for a well thought out implementation of an app which interacts a lot with it's backend, I think it's the only way to go now. I also feel like people will be missing the React wave at their peril. We're on the verge of being able to cleanly abstract out an applications delivery mechanism whether its native, mobile, or web. That is because of things like React and ReactNative and it's immutable render-every-time approach.

capkutay 11y ago
I think people try to get started with react and they jump to the boilerplates that are 'production ready'. Those boilerplates include routers, frameworks to bind routers to state, frameworks for server-side rendering, some new ES7 syntactic sugar, a bleeding edge module bundler like Webpack...the list goes on. They may or may not be a great combination of frameworks, but each has their own learning overhead. So people confuse learning react or learning redux with learning how to use every single framework shipped in the common react boilerplates. It can take weeks of studying or learning enough about those frameworks to understand how they all work. React itself is moving along at a healthy pace. Popular frameworks around react change about every week which causes this fatigue that OP speaks of. The most important thing IMO is learning the core concepts behind react, flux, redux, react-router, and worry about product client/server rendering and module bundling later.
ilostmykeys 11y ago
I was going say the same thing, a little differently. Only other comment is around having to know your entire app start up front. If you break up your app into micro apps each of which implement a given feature of your site then it's much easier to handle that way.

thirdreplicator 11y ago

I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and finally got a chance to come back to it. I made a couple of pages with vue.js, and I think there is a lot less stuff to do. There's no JSX. Your HTML peppered with vue.js directives is your templating language. There's no server side rendering, but that may be a good thing in the end. Fewer dependencies, less learning curve, less ecosystem to swallow in a single gulp. I hired a fresh grad from the Philippines, and he was able to pick it up and run with it immediately. I've only been using vuejs over Christmas, but I'm looking forward to seeing what else it can do. I'll post a small PHP-backed CRUD app if people are interested.

onewaystreet 11y ago
> gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.
- Touche 11y ago
  After 300+ lines of config spread over 3 files.
- sergiotapia 11y ago
  "Replace this garbage with this other newer garbage."
- pavel_lishin 11y ago
  Doesn't that just glue them all together? We're using it at work, and we brought in an in-house React person, but I have no idea what the config does/signifies, and every time they change something, I absolutely don't understand why or how it works. (Our tests currently don't work. I mean, they can run - unless there's an error, in which case it exits early with a 0 status, without running any of the subsequent tests.) This is partially on me - I should read the shit out of the docs - but so far it seems like it just paints over the complexity a little.

pbhowmic 11y ago

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 is an older typed language. The unbrevity of JavaScript is inexcusable and it extends to every UI framework it offers. Tooling is no way to try and ease the problem.

snaky 11y ago
> There is no terse way to describe a UI Did you ever seen Tk?
- epoch1970 11y ago
  Tk was only ever feasible for very simple, often throw-away, UIs, and not much more than that. Tk can't be compared to Qt or the other full-featured UI toolkits that exist.
pixie_ 11y ago
The last time I felt productive doing UIs was with WinForms and before that VB6.
- laichzeit0 11y ago
  At the end of the day, this is what the web community will ultimately end up re-inventing. https://polymer-designer.appspot.com/ https://polymer-designer.appspot.com/

G4BB3R 11y ago

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

innocentoldguy 11y ago
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.

ebola1717 11y ago

Hm, I found that one of the strengths of React is that it's so easy to sidestep a lot of the complexity of it, if you're not building a true SPA. We use React to add some interactivity to our forms and dashboards, so we only need to use state & props. No Flux/Redux/etc backends, and not much messing around with webpack & co.

sudo_bang_bang 11y ago

Build tools are partly necessary because of how many old crusty browsers hang around out there. I mean, I still work on an app that has to support IE8. That's just ridiculous. As it is, ES6/ES7 imports make a lot of the issues of JS inclusion a thing of the past, but the build tools are necessary for packing these together and transpiling down to ES5, to support older browsers. The other tools you see in the React ecosystem do take time to learn for sure. The whole React/Flux paradigm takes a while but once you get it there's not many surprises. I do feel the fatigue though just as the author does. There's a million ways to do what the browsers should just do natively already. In a few years we hopefully won't have to worry about this anymore.

dcsan 11y ago

meteor works nicely with React. It may not be the most optimum route (problems with webpack, outdated node, crappy testing) but is a decent curated way to get started. The official react stack will be supported going forward, and the velocity of changes is not quite as much as the a-la-carte JS environment.

sergiotapia 11y ago

I was lucky that I started on React from within Meteor. Meteor builds everything automatically, and does not require you to spend 5 days tweaking a brittle series of config files. Last week, I wanted to start a React app that talks to a Phoenix API and found out there's a ton of different ways to create a react app. That sucks. There is no 'one obviously better way.' Kudos to Ember for being great in that area. React needs to have an obvious way to start and run an app. Not this gulpwebifypack config garbage Proof is in the pudding, check it out! http://sergiotapia.me/2015/09/18/react-and-meteor-match-made-in-heaven/ http://sergiotapia.me/2015/09/18/react-and-meteor-match-made...

chowes 11y ago

People jumped the Angular / Ember ship for React because those frameworks were too complex. Then they realized they needed additional features. Now there's a push to unify these features into a framework... You have to put your complexity somewhere.

OSButler 11y ago
I believe in Angular's case the changes from 1.x to the 2.x branch didn't help much either.

zachrose 11y ago

I have a suggestion to this, but I don't know how to get it out there. I can't build a library because the point is to not depend on libraries. My suggestion is that if your going to build an application in the browser, your project needs an architecture that will last beyond today's libraries and tooling. You want to recognize what's unique about your app and express those parts without touching the DOM or network, even if they seem trivial now. My particular favorite way to do that is using an event bus to create a catalog of custom/domain-specific events, with views emitting operation- or command-like events and internal models emitting new states. This is basically the important part of Flux without the special concepts (stores, dispatcher) that you may be fine without, and is already available in jQuery, Backbone, node's EventEmitter, and many other libraries out there. React and immutability and the rest of Flux are all very reasonable next steps if somehow you come to need them, but you are likely not spreading your UI development across hundreds of engineers. Unnecessary new stuff is just going to steer your conversations towards libraries and away from your domain.

baddox 11y ago
Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state). Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, since reducers are pure functions and actions are (or should be) simple JSON-able data. The actual rendering of state to DOM is done completely separately by registering callbacks that listen for application state changes. Of course, if you're using some other architecture to manage application state, results may vary.
- MatthewPhillips 11y ago
  How can I write reusable components if my domain logic must be separate from my view logic?
  - baddox 11y ago

scope 11y ago

there's NO <insert language/framework/tool here> 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 without using nails at all After sometime, you see another builder 3D printing a house...

sotojuan 11y ago
Yeah, this is something I struggle with: Always trying to find something new to learn and not mastering anything. It is exhausting, but ultimately it depends on me. That said, to me the React ecosystem is the opposite of "convention over configuration" which can frustrate a lot of beginners. There's no popular `rails new` or `ember new` to get you started.
addicted 11y ago
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 almost the opposite.
- scope 11y ago
  > 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)
  - awolden 11y ago

hoodoof 11y ago

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 come to understand that in the reactJS world they might be reading something relevant, but then again they might be reading something completely irrelevant and in compatible (i.e. ES2015 verus JS). Really when a new technology comes along that is a clear "winner", serious consideration should be given to just getting rid of the "old" way. Unless Grunt and Gulp are going to somehow make a big comeback, the should be loudly killed off. Damn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still? Old tech should be visibly and loudly killed. No wonder its hard for beginners - its all the damn noise made by the "old" ways of doing things. The react ecosystem is filled with the living dead - technology that has died but just won't go away. 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. Beginners (and I am one) don't need to be shown every possible way to do things - they need be given a rock solid, opinionated path on the current right way to get the job done. I don't care if that opinionated path changes every month, I just want to not have to work it out by fighting through two years of zombie tech to eventually figure it out.

tptacek 11y ago
Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.
- hoodoof 11y ago
  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 the assumption that they are the latest because they are better, and on the assumption that previous technologies that did the same thing will be superseded - I use them. You can criticise this approach as just following the trends but I take this approach because it would be stupid to try to understand every single component of the ecosystem and then make my own careful choices - what is everyone else using right now? Probably good enough unless I know some good reason not to use it. I am a beginner and struggle hard to understand the vast array of tech I need to do reactJS development. It hurts me very badly sometimes and I feel stupid because I don't grasp it all, but I have to get shit built so for the most part I'm just doing what others are doing and as I go I am learning more and more and in areas that I have gained real understanding I then make my own educated decisions about exactly how to do it in the right way.

lsdafjklsd 11y ago

I think the problem is that the people using React see the grand architecture in Relay / Falcor / Om.next, and are trying to recreate those API's using current libs. There are still a lot of parts missing when you try to build an app with the same abstractions as the aforementioned libraries, and I think the author is correct about 2016 being a year where those gaps are filled. What we really need is a translation of om.next to javascript. That library summarizes all the good ideas from Netflix and Facebook into a small library for every day use. The fact that it's in Clojurescript makes it a non-starter for others, too bad because it's a really great eco-system. edit, list technologies: React + Redux is a good start, but we need composable queries and a router (falcor) or reconciler (om.next) that manages data fetching / caching. JLongster has done some experimentation here with datascript integration https://github.com/jlongster/redux-experiments/blob/master/static-queries-datascript/main.js https://github.com/jlongster/redux-experiments/blob/master/s...

modarts 11y ago

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 solid piece of software in Leiningen (that has a ridiculously high level of adoption) - Hot reloading (mainly through Figwheel) is simply magical (it's stable and "just works".) The amount of work to get a hot reloading environment setup and maintained with Webpack and various loaders is way too much, and often involves actual changes to application code to support it, which is unacceptable. - The language itself is designed from the ground up to be functional This is just what I can think of off the top of my head after a few glasses of wine, but there's a ton of reasons why we as JS developers should start taking a hard look at Clojurescript again.

AlwaysBCoding 11y ago
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.
- yogthos 11y ago
  Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that: Install OpenJDK: http://www.azul.com/downloads/zulu/ http://www.azul.com/downloads/zulu/ Install Leiningen: http://leiningen.org/ http://leiningen.org/ Create a new project and run it: lein new reagent myapp cd myapp lein figwheel Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React. I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.

lopatin 11y ago

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 architectures to stabilize. Until then, my code won't be the holy grail of immutable flux, but my users will never know that. My re-builds take a couple seconds and I don't have hot code reloading. And I'm ok with that. I work with (what I consider to be) the bare minimum: React, Babel, Browserify, and fswatch. It's all wired together in my Makefile. It works pretty well. When something clearly needs improvement then I'll address it. Maybe I'll switch to Webpack and integrate hot code reloading to improve build times when I have some free time. But only as a luxury. I can get by without it. The above sounds easier for build tools than for JS architecture. After all, switching from Browserify to Webpack is a lot easier than refactoring your code from your existing setup to something like Relay, Om, etc... What I say to that is this: Gradually integrating flux (vanilla or Redux) into an existing React app is actually very simple. Extract local state, throw it into a store, and add a subscription. I wouldn't expect any refactoring headaches at all if your component hierarchy makes sense. Everything else (for example anything related to GraphQL, ClojureScript, you see where I'm going) counts as "not boring technology" and significantly increases the risk of being pulled back into the unproductive search of JavaScript enlightenment. I certainly don't want to discourage library authors in any way. If that's what you're passionate about then don't let my jaded thoughts stop you from building something great. We are in a period of great discovery, innovation, and change. I just wanted to share my thoughts about making a conscious effort to minimize my toolset and accepting the tradeoffs of not having the latest tech.

voltagex_ 11y ago
>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)

jkldotio 11y ago

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 or years after it is written; I most likely want to just be able to read, understand and edit it quickly. As soon as something has a huge infrastructure, setup, tooling, transpiling or whatever it just becomes burdensome. Intercooler.js (http://intercoolerjs.org/ http://intercoolerjs.org/) demonstrates a good philosophy.

lopatin 11y ago
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".
bsuh 11y ago
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 read when I come back to your site). You hate maintaining an entire application in Javascript so you get to learn all the joy of transpilers and a build system to build whatever not Javascript language you chose and your tens of module dependencies because you decided everything had to be done in Javascript or TypeScript or ES2015 or CoffeeScript or ES7. Oh and when a new language supersedes the language you decided to use, you happily spend weeks moving your codebase to a new language, thinking "Wow static typing in 2015?! My code is so much more maintainable now!" It says it all that the benchmark for comparing frameworks is TodoMVC, a simple CRUD application for which client side rendering is unnecessary. People are not thinking at all about the pros and cons of client-side rendering and reaching for it for any web applications. Google doesn't use AngularJS for Gmail. They use GWT to render HTML on the server. Side note: AngularJS 2 beta is 500KB. Fucking laughable. Oh and they suggest loading both the AngularJS 1 and AngularJS 2 frameworks on your page to help you migrate. Facebook doesn't use ReactJS for Facebook. They use PHP to render HTML on the server. Edit: Yes Facebook uses ReactJS for a lot of side stuff, but not for big items like their newsfeed. Twitter doesn't use client side rendering. They tried it but reverted, because the time to first see the content was too long. People are building a mountain of abstractions and investing so much time to over-engineer everything in Javascript. WHY?!

deleted 11y ago

[deleted]

masonicb00m 11y ago

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

lopatin 11y ago
I put my components into app/components. This is the one, true directory structure. All other directory structures are wrong. \s
Corrado 11y ago
Opinionated programming was/is Rails' major contribution to the web world, as far as I'm concerned. By providing a baseline of things you need (directory structure, modules, logic flow, etc.) it made starting a project easy. In fact, it's just a single command. I think having all of these (ever changing) options is a sign of Javascripts immaturity; it's not bad, it's just growing pains. Hopefully someone will step up with a cookbook of best practices which will be respected and used throughout the community.

aidenn0 11y ago

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.

jameslk 11y ago

I can hardly relate. Perhaps I got lucky, but my experience with the React ecosystem has not been painful. Coming from Angular previously ($watch? isolate scope?? transclusion???), it was a breath of fresh air. It might also be due to my avoidance of certain rabbit holes that are prevalent around React. One of those being the React community's love affair with immutability (immutable.js, Redux, etc). JavaScript is not itself designed around the concept of immutability. Mixing the concepts has only led me to fight with the language and the existing ecosystem. Immutable patterns work best in a world where most things are immutable to begin with, not when you're trying to coerce a world of mutable tools to be immutable. I'll admit, walking on some of these landmines initially was pretty painful, but I've been working with large codebases in React (SPAs and projects with tens of thousands lines of code) that I feel I've discovered the right paths to take. Here's my takeaways for modern frontend projects using React: - Keep code organized in modules (a la CommonJS) so code doesn't become a big ball of mud. - Use React Router to enforce that organization. - Stick to vanilla JS- ES5/ES6/ES7--it's better documented. - Use Grunt, and then add in Gulp when needed, otherwise you'll be writing a lot more boilerplate. - Use Browserify, not Webpack--it doesn't try to do everything. - Use a reactive data paradigm to keep data flow simple (observables, e.g. Mobservable works really well) instead of Flux/Redux/*ux. - Stick to real CSS and use namespaces (or web components), not React's hijacked inlined version of it. These practices have helped the teams I've worked in get stuff done and have scaled quite well.

dclowd9901 11y ago
There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?
- jameslk 11y ago
  I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant-a-baobab-tree-in-your-flux-application.html http://christianalfoni.github.io/javascript/2015/02/06/plant...). Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.t5fhdnhsc https://medium.com/@dan_abramov/smart-and-dumb-components-7c...) to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html https://mweststrate.github.io/mobservable/best/store.html

frik 11y ago

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/shadowdom/ http://www.html5rocks.com/en/tutorials/webcomponents/shadowd... Shadow DOM hasn't been integrated in other browser (http://caniuse.com/#feat=shadowdom 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.

Joeri 11y ago
The fat vs thin client cycle has been happening for far longer than web dev. It's been going pretty much since we have interactive computers. Neither strategy is really the right one, it depends on the context of what you're trying to do. If only all young programmers could be taught a history of programming class where they analyze old deprecated technologies that used to be popular, and form an understanding why they rose to prominence and why they faded away. Maybe we could avoid new generations making the same mistakes over and over again with different technologies.

hugozap 11y ago

Just do the simplest thing that works. This is the same hype as Angular 1 had. People will move on eventually.