81–90 of 187 posts
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".
Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure? - You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,) - Don't need to bring a functional utility lib (lodash/ramda/etc) - The build ecosystem revolves around a really…
I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now.
What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS. Everyone pointed me to core.async (later on someone mentioned the cats library which uses monads etc) It didn't feel right to use core.async's syntactically and conceptually complicated CSP pattern to solve a truly simple problem that can be solved far more elegantly with a much simpler and more general pattern using ES7's async/await.
And now that we have decorators, typed data structures, iteration protocols and a myriad of other tools available to us in ES6/ES7 the only thing that is missing is NATIVE immutable types.
Earlier quoted context omitted.
> 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??
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.
2. I generally have `react-fullstack` installed
3. Run `yo react-fullstack`, `cd my_project`, `npm start`
Personally, I think its a bit overkill. I tend to delete most of it and add Bootstrap myself, but its a decent way to start a project.
Search for and pick a generator that suites your needs: http://yeoman.io/generators/
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 think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages.
Clojurescript is a case in point. Statistically its userbase is zero but it's been the source of several useful techniques.
Earlier quoted context omitted.
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.
He said he was a front end JS beginner. He also mentioned being a seasoned software engineer overall.
His advice is completely sound, and a very valid approach: Want to learn a new platform/ecosystem? Take whatever is the most popular and make stuff work. It's the fastest way to learn by far and with an free bonus you get actual valuable software.
Nobody flames people who learn Rails while learning Ruby! What's the matter with you guys?
The only mistake the GP made was "admit" on HN that he's a beginner at something.
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…
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.
Earlier quoted context omitted.
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.
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?
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. 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: ...
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.
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…
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?!