10 ms·

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice. Lastly, I wouldn’t underestimate how this has built up slowly over time, and therefore how many people just don’t know any better. Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing react libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done. At the end of that session this developer said to me, “wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.” This is a good, very productive, very fast-learning developer I’m talking about. He literally had never tried to use the DOM api, and didn’t realize it was, you know, useful. I think there’s a lot of that in front end world today.

simonw 6y ago
What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
- duxup 6y ago
  IMO, it's kinda hard not to end up learning those things even if you are in react all day. At one point or another things don't work and it's because of simple HTML... and not react. Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
- MattGaiser 6y ago
  That's what the C devs said about all the people learning Java. "We are raising a cohort of developers who knows nothing about memory management." Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.
  - PaulDavisThe1st 6y ago
    Except that "niche cases" here means "everything you do with software but not in a web browser".
    - MattGaiser 6y ago
      I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something. Although you can use React for mobile (Native) and desktop (Electron)
  - zerkten 6y ago
    > That's what the C devs said about all the people learning Java. That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions! We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
    - MattGaiser 6y ago
      > but for me it's a really wide list of items and not a very tall stack. That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba. But yes, that makes developers wide and not deep.
  - OOPMan 6y ago
    And you know what, the C devs weren't wrong. Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
- mgummelt 6y ago
  React still requires you to write HTML and forms.
  - theonething 6y ago
    And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
    - Polylactic_acid 6y ago
      It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
      - withinboredom 6y ago
        It literally does, unless you have the form POST or GET to an API directly + a redirect from the API. You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
        tomduncalf 6y ago
        You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever. You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever). Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
- millstone 6y ago
  I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
  - curveship 6y ago
    Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ... ... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix. So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career. I did get a $1k security bounty from Google, though, so that was cool. Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736 https://bugs.chromium.org/p/chromium/issues/detail?id=282736 Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.
EGreg 6y ago
Hey all I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React. Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap! Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in. If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also. The React fad is like jQuery.
- jes5199 6y ago
  to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs. And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking. I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back. I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
  - EGreg 6y ago
    Want to jump on a call with me - just for fun - for 10 mins? I will show you our framework that we use internally: https://calendly.com/qbix/meeting https://calendly.com/qbix/meeting IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner. https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools
luxphl 6y ago
This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is. But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package. Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it. I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug
- ithrow 6y ago
  React is not the problem, it's fine as a component in a page. The issue is the abuse of SPAs.
- burlesona 6y ago
  As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.
  - chrischen 6y ago
    Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.
    - TeMPOraL 6y ago
      You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.
goostavos 6y ago
>If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.
mgummelt 6y ago
Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?
- millstone 6y ago
  https://bugs.chromium.org/p/chromium/issues/detail?id=604033 https://bugs.chromium.org/p/chromium/issues/detail?id=604033
  - mgummelt 6y ago
    You want to log an integer to the console 100,000 times? Not sure why you would, but you can do that in a React event handler or lifecycle method.
chrischen 6y ago
A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers. Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility). It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.
- deleted 6y ago
  [deleted]
- zerkten 6y ago
  > A lot things can be easier if you do things the "wrong way". > It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable... I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA. When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion. The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway. When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage. Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.
pcr910303 6y ago
> chances are there’s at least one front-end hipster around who will mock you as outdated Well, React isn't something very 'shiny' anymore, for shiny things you would look at things like svelte or wasm. React is older than jQuery's age when React was first born now.
- nyanpasu64 6y ago
  WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.
arvinsim 6y ago
> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice. This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up". > Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done. I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development - Responsiveness - Browser support - Accessibility - Internationalization That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet. Many people underestimate how much work a good web app entails
- burlesona 6y ago
  1) CSS works great, and while it continues to incrementally improve, has been fairly stable since its introduction. What I meant about "solutions" that don't work well are things like React state which has gone from "not a thing" to "redux" to "redux is an antipattern" to "redux is moot because now graphql" which oh BTW means you now need a whole new API? Ok. That framework churn is because those problems are actually difficult, and to date there's no "one true way" that is pretty straightforward and covers 90% of cases pretty well. By contrast, things like "how to set up a webserver that handles HTTP requests" are easier and already well-solved in every serious language, and thus not so subject to the same degree of churn. 2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.
- thomasfromcdnjs 6y ago
  Yeah I'm also laughing. The senior engineer could have just as easily wrote worse code. Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future. React helps with lots of things; - Testability - Readability - Less side effects - Documentation - Rendering - Error Protection I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun. Frontend development is HARD, factors include; - Plethora of device models/sizes - Latency / Async / Fetching (data) - Rendering speeds based off how you coded it - State Management / Cache Freshness / LocalStorage - Server Side Rendering - Code Bundling (js and css) - Design / Transitions / UX / UI etc Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick. If I could do that with one style tag and one script tag, I would.
pistoriusp 6y ago
> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters." They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.
- ajsnigrutin 6y ago
  The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it. I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...
  - DarkWiiPlayer 6y ago
    > but it seems phpBB is still being developed Doesn't that underline your point though?
    - ajsnigrutin 6y ago
      Does library-support-wise (well, software-wise). Trying to find a developer with phpbb experience now, would be a totally different story.
- burlesona 6y ago
  Haha, that's fair. It would be more fair to say "advocates" or something like that. My bad.
fergie 6y ago
> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising. That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem. If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.
- emerongi 6y ago
  > Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising. Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.
OOPMan 6y ago
Having done some old Skool desktop dev recently I can't shake the feeling that modern web development is mostly just trying to reinvent wheels that have mostly been sorted for 20+ years. I guess it's understandable though, the web was never really designed with its current use-case in mind. People do so love forcing square pegs into round holes though.
ksec 6y ago
>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.” Wow. These two sentences completely capture modern day Web Development, Javascript as assembly. >I think there’s a lot of that in front end world today. In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.
- brlewis 6y ago
  FWIW, the first conference where I heard speakers talk about learning JavaScript first before leaning on a framework, was jQuery 2008. Frameworks are not inherently premature abstractions, but can be used that way.
  - rbanffy 6y ago
    It's always good advice to start with the conceptually simplest tech you can get away with.
MivLives 6y ago
About your junior dev it might also be the way he was taught React. I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research). One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code. An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.
friedman23 6y ago
I find assumptions like "people are lying about liking it" for any popular thing are always wrong.
gofreddygo 6y ago
At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized. I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end. Now things are really fucked. On both ends.

simonw 6y ago

What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!

duxup 6y ago
IMO, it's kinda hard not to end up learning those things even if you are in react all day. At one point or another things don't work and it's because of simple HTML... and not react. Maybe that's not the right path to learn it but we've reached a point where if you want a job, plain HTML and JavaScript isn't it.... plenty of folks who had the benefit of developing their skills from HTML + JS all the way up will bemoan this situation.... but if they're hiring people they're not hiring anyone who just knows HTML and JavaScript without any exposure to anything else.
MattGaiser 6y ago
That's what the C devs said about all the people learning Java. "We are raising a cohort of developers who knows nothing about memory management." Sure, there are things you do not know if all you know is React, but technological changes make it irrelevant in all but the most niche of cases.
- PaulDavisThe1st 6y ago
  Except that "niche cases" here means "everything you do with software but not in a web browser".
  - MattGaiser 6y ago
    I meant to constrain my comment to the web development sphere. Niche cases mean some scenarios where bandwidth limitations prevent the use of React or something. Although you can use React for mobile (Native) and desktop (Electron)
- zerkten 6y ago
  > That's what the C devs said about all the people learning Java. That's not a great argument here. Web development is much more of a continuous spectrum. Programming platforms are designed to hide the the layers beneath to a large degree. I'm not saying there aren't leaky abstractions! We use the term "full stack" for web developers, but people visualize this with layers, but for me it's a really wide list of items and not a very tall stack.
  - MattGaiser 6y ago
    > but for me it's a really wide list of items and not a very tall stack. That is fair. You need a bit of many technologies to launch a website. I always interpreted full-stack to mean that you could launch a site on your own, from the database to the buttons and thus do not require a dedicated frontend, backend, or dba. But yes, that makes developers wide and not deep.
- OOPMan 6y ago
  And you know what, the C devs weren't wrong. Coming back to C++ after a decade of Python I realised I had largely forgotten about how memory management works and that felt bad. I felt stupid, because not thinking about that wasn't necessarily a good thing.
mgummelt 6y ago
React still requires you to write HTML and forms.
- theonething 6y ago
  And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
  - Polylactic_acid 6y ago
    It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
    - withinboredom 6y ago
      It literally does, unless you have the form POST or GET to an API directly + a redirect from the API. You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.
      - tomduncalf 6y ago
        You do have to override the submit functionality if you don't want to load a new page, sure, but that was always the case with plain Javascript or jQuery or whatever. You don't have to maintain the state of what the user inputs if you leave the inputs as uncontrolled (https://reactjs.org/docs/uncontrolled-components.html https://reactjs.org/docs/uncontrolled-components.html) and access their value via a ref. You could even give them IDs and access their value directly via that if you wanted to, just like you would pre-React. But there are clearly advantages to making the inputs controlled by React, otherwise there'd be no reason to bother doing so (not saying that there aren't probaly a lot of cases where you could keep it simpler but people have been led to believe they need to put their form data in Redux so use some elaborate solution which doesn't scale, or whatever). Also if you are doing forms in React, check out formik, it's the nicest library I've found so far. Granted it's not as "easy" as a straight HTML form that POSTs to a new page, of course, but modern web experiences often demand richer functionality than "the old way" allows.
millstone 6y ago
I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
- curveship 6y ago
  Heh, I could almost tell that story. We had a bug in a React app that started when a new Chrome release came out. I boiled it down to a small piece of JS that V8 was clearly misinterpreting and which looked like it might be memory corruption in the JITed code. Yep, I got a Chrome build going and was tracing through to see what was going on ... ... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix. So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career. I did get a $1k security bounty from Google, though, so that was cool. Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736 https://bugs.chromium.org/p/chromium/issues/detail?id=282736 Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.

EGreg 6y ago

Hey all I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React. Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at compile time. Not that you should do any of that crap! Still, React and Angular are insane. React makes you use Babel for JSX and a bunch of esoteric rules that they then make workarounds for, such as “hooks”. And Angular is even more complex, with its digest cycles and mocks and bindings etc. It totally sucks you in. If you want to use a framework that’s much more lightweight, use Vue. Or use the one that we built ;-) It treats CSS, HTML and JS — and the rest of the Web - exactly as it was meant to be, and doesn’t try to reinvent the well. Well, it does use Handlebars for templating, but can support any other one also. The React fad is like jQuery.

jes5199 6y ago
to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs. And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking. I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back. I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
- EGreg 6y ago
  Want to jump on a call with me - just for fun - for 10 mins? I will show you our framework that we use internally: https://calendly.com/qbix/meeting https://calendly.com/qbix/meeting IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner. https://qbix.com/platform/guide/tools https://qbix.com/platform/guide/tools

luxphl 6y ago

This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is. But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package. Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to separate the state of the DOM from manipulating it. I don't buy the hipster-centric logic, for me it comes down to productivity. The bugs of yesteryear, tracking down which procedural code path led to modifying a variable, are mostly gone with React. And if you don't use it (or something like it), you end up implementing a subset of it anyway because it's a foundational part of coordinating UI with business logic. /shrug

ithrow 6y ago
React is not the problem, it's fine as a component in a page. The issue is the abuse of SPAs.
burlesona 6y ago
As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.
- chrischen 6y ago
  Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.
  - TeMPOraL 6y ago
    You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.

goostavos 6y ago

>If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most I see this everywhere in programming, not just frontend. I think this silent peer pressure influences us all to some degree. Whether through not wanting to look outdated or foolish, to just being tired of the uphill battle involved constantly fighting against the unstoppable momentum of the cargo cult.

mgummelt 6y ago

Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?

millstone 6y ago
https://bugs.chromium.org/p/chromium/issues/detail?id=604033 https://bugs.chromium.org/p/chromium/issues/detail?id=604033
- mgummelt 6y ago
  You want to log an integer to the console 100,000 times? Not sure why you would, but you can do that in a React event handler or lifecycle method.

chrischen 6y ago

A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers. Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility). It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.

deleted 6y ago
[deleted]
zerkten 6y ago
> A lot things can be easier if you do things the "wrong way". > It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable... I don't think you are responding to the point that the previous comment is making. The point is that there is a spectrum from let's say, traditional, to full-on SPA. When presented with most spectrums of choice like this, it's expected that most people will weigh in requirements first and choose the solution based on the requirements (if they are an engineer, or pretending to be one.) In terms of expertise, they might love to write SPAs, but they realize that the other options on the spectrum exist for reasons other than being in, or out of fashion. The problem is that some folks overemphasize what's in fashion. There are many reasons for this, and it's something that happens across other disciplines, not just programming. That said, we have a unique situation with programming in that someone can be quite an expert while only understanding one end of the spectrum. It's very easy for these folks to hold sway. When it comes to the "wrong way", I agree with you, but I'd go further. If the requirements demand a SPA then you need to go all in and use the best modern tools. There are a lot of things created as we moved out of the full page render ages which don't result in good SPA development (for users or devs.) Embrace Typescript, React, etc because these solutions have evolved from that in-between stage. Using "browser compatibility, accessibility concerns, localization/internationalization" isn't a great argument here. These are often orthogonal requirement. It's easy to argue that full page rendering, or static HTML meets all these more easily. These apps can't compete if you need particular interactive experiences.

pcr910303 6y ago

> chances are there’s at least one front-end hipster around who will mock you as outdated Well, React isn't something very 'shiny' anymore, for shiny things you would look at things like svelte or wasm. React is older than jQuery's age when React was first born now.

nyanpasu64 6y ago
WASM is entirely different from Svelte/React. WASM is a compilation target for native-code languages, and can't interact with the DOM except through JS shims.

arvinsim 6y ago

> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice. This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up". > Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done. I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development - Responsiveness - Browser support - Accessibility - Internationalization That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet. Many people underestimate how much work a good web app entails

burlesona 6y ago
1) CSS works great, and while it continues to incrementally improve, has been fairly stable since its introduction. What I meant about "solutions" that don't work well are things like React state which has gone from "not a thing" to "redux" to "redux is an antipattern" to "redux is moot because now graphql" which oh BTW means you now need a whole new API? Ok. That framework churn is because those problems are actually difficult, and to date there's no "one true way" that is pretty straightforward and covers 90% of cases pretty well. By contrast, things like "how to set up a webserver that handles HTTP requests" are easier and already well-solved in every serious language, and thus not so subject to the same degree of churn. 2) All those concerns were present in the project I worked with said developer on, and were easy to handle with the basic tools of the browser.
thomasfromcdnjs 6y ago
Yeah I'm also laughing. The senior engineer could have just as easily wrote worse code. Just some weird obscure Javascript floating around editing the DOM directly causing untraceable errors in the future. React helps with lots of things; - Testability - Readability - Less side effects - Documentation - Rendering - Error Protection I could rattle on forever, might be time to write a blog post, gets a bit tiring reading the HN users who think we've just made the frontend complex for fun. Frontend development is HARD, factors include; - Plethora of device models/sizes - Latency / Async / Fetching (data) - Rendering speeds based off how you coded it - State Management / Cache Freshness / LocalStorage - Server Side Rendering - Code Bundling (js and css) - Design / Transitions / UX / UI etc Now why is all this important? Because to be a competitive app, it simply has to be sexy and slick. If I could do that with one style tag and one script tag, I would.

pistoriusp 6y ago

> If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. It sounds like you're reinforcing this divide by classifying people who have a different opinion to you as "hipsters." They label your technology choice as outdated, and you label them as hipsters. You become the thing you fight.

ajsnigrutin 6y ago
The problem with using some shiny new library/software/app/technology is, that it might dissapear in a year. The developers will move on to new companies, and work with some new shiny tech, and all your codebase will be useless due to a unmaintained library and no new people (developers) who know how to use it. I wanted to make an example that it was like starting work at a company, and seeing that they're still using phpBB (but with a 1 year old library)... but it seems phpBB is still being developed...
- DarkWiiPlayer 6y ago
  > but it seems phpBB is still being developed Doesn't that underline your point though?
  - ajsnigrutin 6y ago
    Does library-support-wise (well, software-wise). Trying to find a developer with phpbb experience now, would be a totally different story.
burlesona 6y ago
Haha, that's fair. It would be more fair to say "advocates" or something like that. My bad.

fergie 6y ago

> I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. Yes. And its important to remember that React is heavily marketed to developers by Facebook, just as MS does with Typescript, and Google does with Angular. The point of this marketing is to create a feeling that these technologies are "safe" and "standard". Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising. That said, there are a few major functionality gaps in native JS that leave the door open for front end libs. The biggest one is some kind of sane support for templating, and the second big one is that async is too complicated (people who actually understand callbacks and Promises often dont realize how many devs dont understand them). Facebook, via React, provides solutions to these problems, and leverages them to get users to buy into the React ecosystem. If somebody could show how to make a component in JS that could be included in a page as an HTML tag, and could talk to other components on the page then the need for React would just evaporate.

emerongi 6y ago
> Developers _think_ that they are making up their own mind, but really they are just forming vague opinions based on advertising. Of course. Most devshops don't have the manpower that FB/Google/MS have. You don't really have months to tinker around and create some new framework and then another 2x months to fix bugs and add new features to cover some edge cases. So you pick whatever is backed by a lot of manpower as it has the highest chance of being usable even 3 years from now.

OOPMan 6y ago

Having done some old Skool desktop dev recently I can't shake the feeling that modern web development is mostly just trying to reinvent wheels that have mostly been sorted for 20+ years. I guess it's understandable though, the web was never really designed with its current use-case in mind. People do so love forcing square pegs into round holes though.

ksec 6y ago

>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.” Wow. These two sentences completely capture modern day Web Development, Javascript as assembly. >I think there’s a lot of that in front end world today. In modern Web development, ( and in possibly all area of software development ), instead of making things simpler ( not easier ), it seems we have been building premature abstraction after abstraction.

brlewis 6y ago
FWIW, the first conference where I heard speakers talk about learning JavaScript first before leaning on a framework, was jQuery 2008. Frameworks are not inherently premature abstractions, but can be used that way.
- rbanffy 6y ago
  It's always good advice to start with the conceptually simplest tech you can get away with.

MivLives 6y ago

About your junior dev it might also be the way he was taught React. I'm also a junior and the way I was introduced to React was by teaching me enough JS that I could theoretically write React (with a bunch of research). One of the things I've noticed among other junior engineers (including myself) is tutorial driven development. Through a mixture of inexperience, laziness, and self doubt it can be easier to find someone else who's implemented something and just use theirs. Rather then thinking about a complex problem and naively coding up a solution finding someone else's hopefully battle tested code. An example of this is how I used to make JS based games. I essentially used an array to toggle classes on a grid of divs divs in the style of an LCD screen. I hadn't heard of html's canvas element. My solution worked but I don't think anyone would think it's a particularly good one. If I had found someone's snake game and saw they used canvas I could have saved myself some headache.

friedman23 6y ago

I find assumptions like "people are lying about liking it" for any popular thing are always wrong.

gofreddygo 6y ago

At work, I've been forced to use angular. It's just awfully complicated, breaks subtly, changes (not improves) constantly and has sucked in hundreds of developer hours that could have been better utilized. I was appalled at the state of things in front end development till I realized my current project uses kubernetes (implies docker, helm), spring for implementing REST endpoints and ansible for deployments on the back end. Now things are really fucked. On both ends.