5 ms·
I am willing to concede your pedigree as a developer as necessary but I've been writing all manner of languages and environments since 99 and I'm sorry to say t
by weego 9y ago
I am willing to concede your pedigree as a developer as necessary but I've been writing all manner of languages and environments since 99 and I'm sorry to say there's no revolution here, no battlefield to die on. It's a poor model that has been tried and abandoned any number of times in my career. The ubiquity of platforms that suit these ideas and developers who think Web development began with node and spas isn't confirmation that every idea is the future.
Moreover, the notion that because FB or whoever went "hmm nothing solves our domain problem, we have the resources to solve it ourselves" that suddenly they solved every domain problem is equally naive. It's likely that people quoting react stacks are solving issues that never existed for them with libraries they don't need.
- aaron-lebo 9y agoYour comment expresses a really common sentiment, but it also vague and offers no supporting evidence. When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.
- Silhouette 9y agoWhen was a model like React + Redux (or Elm) used previously, and why did it fail? What do you mean "a model like React + Redux"? Programmers have been separating underlying state, rendering and interactions since at least the earliest days of MVC in the '70s. We've been diffing model states to identify changes to act on for as long as we've had explicit isolated state management, which again is several decades. We've been identifying specific parts of a display to rerender fully because doing the whole thing was too expensive since the earliest graphical video games. We've been using markup languages to describe UI layouts declaratively for a long time too. Adopting similar techniques in browsers was likely as soon as serious front-end coding to build larger client-side web apps became viable, and they have much the same pros and cons now as they did in other UI development before. React and its surrounding ecosystem may have been the first JS libraries to popularise the ideas for a new generation, and IMHO those early versions of React were well done and useful, but let's not pretend the underlying concepts are radical and new in themselves.
- aaron-lebo 9y agoYes, but that's never been attached to a frontend that reaches billions of people. But like you said, those are good ideas, they didn't fail.
- Silhouette 9y agoWhy does the number of people using a UI make any difference to whether the UI does its job well or whether the underlying technologies are appropriate, though? Would any of the arguments for different ways of building UIs change materially if Facebook had a million active users instead of a billion?
- aaron-lebo 9y agoI'm just saying that even with that model before, we never had tech with the reach or capability as we do now, which makes that interesting. If it was a good model for building UIs in 1970 and it proved itself then, we should be taking advantage of that on the frontend as well, instead of ignoring it.
- Silhouette 9y agoIn that case, perhaps our views here aren't so different. I'd agree that React was a relatively rare qualitative step forward in the tools available in web development, precisely because it did bring some ideas and programming styles into the front-end JS community for probably the first time. I just disagree with the idea that this was unlike anything that had gone before, because essentially the same fundamental ideas and programming styles have been used elsewhere in the programming community for a very long time.
- scottmf 9y agoMy problem is that every JS-framework story on HN is full of comments either a) showing a lack of understanding of the tech like the parent, or b) bringing up "fundamental issues" with SPAs which are either nonexistent or long-solved. That isn't to say some concerns might not have merit, but SEO/SSR/shared routing/state/templates are problems with production-ready OOTB solutions. If someone isn't familiar with the basic SoTA then they should refrain from commenting so harshly on it.
- mattgreenrocks 9y agoThe real problem React solves is enabling many people to work on parts of the same page without stepping on each other. The declarative nature is brilliant, but if the messy MVC diagram slides in the reveal presentation are real, then I feel confident in labeling React this way.
- zsck 9y agoThis is an incredibly common stance, and it's also very obviously problematic. No one is saying that your experience in software is invalid or that you're wrong about "these modern frameworks" having been wrong in their time. However, if you aren't yourself working as a frontend developer in a modern startup-ey development environment, you aren't in a position to make so many assumptions about the problems such developers do or do not have. Surely, as professionals and adults, we can all appreciate that we are each dealing with problems in the world for which people believe we deserve to be paid. We all take what we do seriously, and are trying to build the best tools we can to do the best work possible. Even if something comes in as a fad, what good is it to bawk at a perfectly valuable learning experience?