5 ms·

I 100% feel your pain. I used to work for a very large financial news company. They were all javascript. I though to my self: I learnt JS in 2008, this should

I 100% feel your pain. I used to work for a very large financial news company. They were all javascript. I though to my self: I learnt JS in 2008, this should be easy (it was 2014). Apparently very hard. HTML isn't HTML anymore JS is forced everywhere, and everything has a different name. Anyway, I disappeared back into HPC/VFX/machinelearning, to re-appear into webdev in 2020. I was forced to do some front end work as part of a bootcamp. It took the best part of a week to make a bit of text a link. The template library was so far removed from anything googleable, there was no documentation, worse still no style guide or example style guide. I am glad I don't do web GUIs, they are hard and nasty.

woutr_be 7y ago
Honestly, they're only hard and nasty if you make them hard and nasty. A text link is as easy as <a href="">...</a>. You can of course use React with 2 different libraries to achieve the same goal, but why would you do that.
- realharo 7y ago
  React by itself isn't difficult either. Anyone who has an hour or so to spare can go through the tutorial https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html. They need to rewrite it to use hooks at some point, but it's still a pretty good intro.
  - moring 7y ago
    > They need to rewrite it to use hooks at some point What is the reason that not using hooks is so frowned upon? When I took my first steps with React, I didn't know hooks, so I write component classes and it immediately "clicked" with me because it behaves like most other GUI frameworks do, from Win32-based (1) to X-based to Android to iOS to macOS to Java, and tons of higher-level frameworks in between. It also feels obvious to write a component class because you are describing the behavior of a stateful thing, that is, exactly what classes are made for. With hooks, OTOH, we have a stateful "function", but all state is implicit, which describes behavior other than its main behavior (rendering) but that is implicit too... I can see why developers outside the React world don't "get" hooks, because I can't even remember seeing this idiom outside the React world. (BTW, I've seen the claim that hooks are easier to reason about, for which I found the opposite to be true, and the claim that this makes the main function stateless, which is absurd since the state just becomes implicit). (1) the raw system-level APIs are often not class-based, but nearly all frameworks above it are. edit: the footnote broke formatting
    - TsiCClawOfLight 7y ago
      Classes look familiar, but that's misleading because they don't actually work like one would expect. Hooks are actually much closer to what react does internally, and therefore behave much less surprisingly once you get into advanced things. Think of hooks like a missing primitive (similar to functions, classes and closures) that are critical to the react language, but don't actually exist in JavaScript and thus have to be approximated.
      - moring 7y ago
        > Classes look familiar, but that's misleading because they don't actually work like one would expect. Can you give an example for that? So far, they worked pretty much as I expected. (Coming from a mostly Java background, which is relevant for what I expect).
    - realharo 7y ago
      Regardless of how you feel about hooks, they are, or are quickly becoming, the new standard for most React code, so a React tutorial obviously needs to familiarize people with them. The current tutorial is good at explaining React concepts though, so making the jump to hooks after reading it and doing a few simple playground projects should be trivial. As for why people like them so much as opposed to classes, my guess would be that they let people more easily write reusable behaviors for common tasks (e.g. look at this one for integrating with RxJS Observables for projects using RxJS https://github.com/LeetCode-OpenSource/rxjs-hooks#examples https://github.com/LeetCode-OpenSource/rxjs-hooks#examples - with classes you would have to put code in several lifecycle methods, sometimes duplicate code, for each individual component).
    - dynamite-ready 7y ago
      Hooks are a fair bit easier to manage than classes in React. It won't change what you do with React much, but from file to file, it's more pleasant to read a hook based component, when compared to a class based component, once you're used to it. Hooks also simplify working with React context a great deal. If that's your option for state management.
  - dynamite-ready 7y ago
    As a frontend developer with a great deal of React experience, I respectfully disagree. React is unnecessarily hard, and this fact probably keeps the UI development out of the hands of the people who could potentially do the best work (graphic designers). If you want, there are APIs and frameworks that will allow programmers to configure print layouts and typography by hand. As you can imagine, they're not as well known or as popular as the Adobe tools used for this work. I'm not saying that web based UI development isn't without its unique challenges (state management), but I will say that things could stand to change, and we should move towards simplifying stacks, for what will ultimately be the user's sake.
LifeIsBio 7y ago
> JS is forced everywhere I think this has a lot to do with it, interestingly. The web has become so ubiquitous, and the major players are so resourced, that the barrier to entry can seem really high. Maybe I'm wrong, but my perception is that potential customers wouldn't take a second glance at my sight if it were plain html with minimal CSS and didn't render perfectly on mobile. > I am glad I don't do web GUIs Same.
- noahtallen 7y ago
  You can make a very lovely site with just HTML and CSS! CSS is extremely powerful by itself. As long as you don’t need any dynamic content or dynamic UI, you can likely avoid JS entirely :)
  - saagarjha 7y ago
    You can, but if you’re doing any sort of non-static website then you still have complexities in the backend to deal with. (For static sites, I fully agree that HTML and CSS are more than enough most of the time; at least, they’re good enough for my website!)
  - MattGaiser 7y ago
    > As long as you don’t need any dynamic content or dynamic UI People seem to be ordering more of that, not less. Look at Reddit. They have all manner of stupid animations now.
    - Hasu 7y ago
      You can do all kinds of stupid animations with pure CSS.
onion2k 7y ago
It took the best part of a week to make a bit of text a link. This highlights the problem with web dev quite nicely. Not doubt you weren't really just making some text in to a link. I know the sort of thing bootcamps do, so you were probably installing and learning React, displaying a set of components, implementing React Router, and figuring out how to update app state based on the browser's History API. All with a template library that was a terrible choice for learning (because it didn't have docs). You could summarize that as "making a bit of text a link", but that's glossing over the details. What you were really doing was learning component orchestration, reactive state management, and a browser API. Why wouldn't that take a week? So the problem with web dev is actually that it's really, really easy to trivialize. You can make hard things sound like they should be very straightforward because they look a lot like something simple from the past. And when people find that they're not really doing the simple thing any more they complain because the new, harder way of doing something (which is actually doing something completely different eg reactive state management and in-browser routing vs asking the browser to do a GET) is hard.
- dynamite-ready 7y ago
  And there's the problem... "...component orchestration, reactive state management..." Webdev tool makers are sadists, and many of the 'thought leaders' in the field have Stockholm syndrome. Some aspects of web development certainly are hard (security especially). Frontend development however, does not need to be as hard as it currently is. At the very least, I think there's an opportunity to simplify that layer of the stack, and give the control back to design professionals. Dreamweaver to my mind, represented a more productive direction than React currently does.
  - reroute1 7y ago
    Sure there's lots of reasons to not use React and many places don't. Bad management/decision making is more to blame in this case than anything.
  - onion2k 7y ago
    On the contrary, front end isn't good enough yet, and getting to the point where it's ideal will require more complexity. Users want things to work fast. If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency. That's the goal - your app has to work well for that guy. You can't get it to be fast if you're using the network a lot. We need concurrent rendering, async background processing, and as much work shifted on to worker threads as we can manage. All the things that native apps do to crank up the performance need to happen on the web too. Also, don't forget that the web is fantastically backwards compatible. You can write web apps without the complexity if you want to. You can use Dreamweaver! You can server-side render every page. It works. If that's what you want to serve your users then you should do that. Just don't complain when they use the competitor's app that's faster, more responsive, and does fun things like working offline.

woutr_be 7y ago

Honestly, they're only hard and nasty if you make them hard and nasty. A text link is as easy as <a href="">...</a>. You can of course use React with 2 different libraries to achieve the same goal, but why would you do that.

realharo 7y ago
React by itself isn't difficult either. Anyone who has an hour or so to spare can go through the tutorial https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html. They need to rewrite it to use hooks at some point, but it's still a pretty good intro.
- moring 7y ago
  > They need to rewrite it to use hooks at some point What is the reason that not using hooks is so frowned upon? When I took my first steps with React, I didn't know hooks, so I write component classes and it immediately "clicked" with me because it behaves like most other GUI frameworks do, from Win32-based (1) to X-based to Android to iOS to macOS to Java, and tons of higher-level frameworks in between. It also feels obvious to write a component class because you are describing the behavior of a stateful thing, that is, exactly what classes are made for. With hooks, OTOH, we have a stateful "function", but all state is implicit, which describes behavior other than its main behavior (rendering) but that is implicit too... I can see why developers outside the React world don't "get" hooks, because I can't even remember seeing this idiom outside the React world. (BTW, I've seen the claim that hooks are easier to reason about, for which I found the opposite to be true, and the claim that this makes the main function stateless, which is absurd since the state just becomes implicit). (1) the raw system-level APIs are often not class-based, but nearly all frameworks above it are. edit: the footnote broke formatting
  - TsiCClawOfLight 7y ago
    Classes look familiar, but that's misleading because they don't actually work like one would expect. Hooks are actually much closer to what react does internally, and therefore behave much less surprisingly once you get into advanced things. Think of hooks like a missing primitive (similar to functions, classes and closures) that are critical to the react language, but don't actually exist in JavaScript and thus have to be approximated.
    - moring 7y ago
      > Classes look familiar, but that's misleading because they don't actually work like one would expect. Can you give an example for that? So far, they worked pretty much as I expected. (Coming from a mostly Java background, which is relevant for what I expect).
  - realharo 7y ago
    Regardless of how you feel about hooks, they are, or are quickly becoming, the new standard for most React code, so a React tutorial obviously needs to familiarize people with them. The current tutorial is good at explaining React concepts though, so making the jump to hooks after reading it and doing a few simple playground projects should be trivial. As for why people like them so much as opposed to classes, my guess would be that they let people more easily write reusable behaviors for common tasks (e.g. look at this one for integrating with RxJS Observables for projects using RxJS https://github.com/LeetCode-OpenSource/rxjs-hooks#examples https://github.com/LeetCode-OpenSource/rxjs-hooks#examples - with classes you would have to put code in several lifecycle methods, sometimes duplicate code, for each individual component).
  - dynamite-ready 7y ago
    Hooks are a fair bit easier to manage than classes in React. It won't change what you do with React much, but from file to file, it's more pleasant to read a hook based component, when compared to a class based component, once you're used to it. Hooks also simplify working with React context a great deal. If that's your option for state management.
- dynamite-ready 7y ago
  As a frontend developer with a great deal of React experience, I respectfully disagree. React is unnecessarily hard, and this fact probably keeps the UI development out of the hands of the people who could potentially do the best work (graphic designers). If you want, there are APIs and frameworks that will allow programmers to configure print layouts and typography by hand. As you can imagine, they're not as well known or as popular as the Adobe tools used for this work. I'm not saying that web based UI development isn't without its unique challenges (state management), but I will say that things could stand to change, and we should move towards simplifying stacks, for what will ultimately be the user's sake.

LifeIsBio 7y ago

> JS is forced everywhere I think this has a lot to do with it, interestingly. The web has become so ubiquitous, and the major players are so resourced, that the barrier to entry can seem really high. Maybe I'm wrong, but my perception is that potential customers wouldn't take a second glance at my sight if it were plain html with minimal CSS and didn't render perfectly on mobile. > I am glad I don't do web GUIs Same.

noahtallen 7y ago
You can make a very lovely site with just HTML and CSS! CSS is extremely powerful by itself. As long as you don’t need any dynamic content or dynamic UI, you can likely avoid JS entirely :)
- saagarjha 7y ago
  You can, but if you’re doing any sort of non-static website then you still have complexities in the backend to deal with. (For static sites, I fully agree that HTML and CSS are more than enough most of the time; at least, they’re good enough for my website!)
- MattGaiser 7y ago
  > As long as you don’t need any dynamic content or dynamic UI People seem to be ordering more of that, not less. Look at Reddit. They have all manner of stupid animations now.
  - Hasu 7y ago
    You can do all kinds of stupid animations with pure CSS.

onion2k 7y ago

It took the best part of a week to make a bit of text a link. This highlights the problem with web dev quite nicely. Not doubt you weren't really just making some text in to a link. I know the sort of thing bootcamps do, so you were probably installing and learning React, displaying a set of components, implementing React Router, and figuring out how to update app state based on the browser's History API. All with a template library that was a terrible choice for learning (because it didn't have docs). You could summarize that as "making a bit of text a link", but that's glossing over the details. What you were really doing was learning component orchestration, reactive state management, and a browser API. Why wouldn't that take a week? So the problem with web dev is actually that it's really, really easy to trivialize. You can make hard things sound like they should be very straightforward because they look a lot like something simple from the past. And when people find that they're not really doing the simple thing any more they complain because the new, harder way of doing something (which is actually doing something completely different eg reactive state management and in-browser routing vs asking the browser to do a GET) is hard.

dynamite-ready 7y ago
And there's the problem... "...component orchestration, reactive state management..." Webdev tool makers are sadists, and many of the 'thought leaders' in the field have Stockholm syndrome. Some aspects of web development certainly are hard (security especially). Frontend development however, does not need to be as hard as it currently is. At the very least, I think there's an opportunity to simplify that layer of the stack, and give the control back to design professionals. Dreamweaver to my mind, represented a more productive direction than React currently does.
- reroute1 7y ago
  Sure there's lots of reasons to not use React and many places don't. Bad management/decision making is more to blame in this case than anything.
- onion2k 7y ago
  On the contrary, front end isn't good enough yet, and getting to the point where it's ideal will require more complexity. Users want things to work fast. If you're including a roundtrip to a server your app will never be good enough for a user on a rural 1Mbps satellite connection with 500ms latency. That's the goal - your app has to work well for that guy. You can't get it to be fast if you're using the network a lot. We need concurrent rendering, async background processing, and as much work shifted on to worker threads as we can manage. All the things that native apps do to crank up the performance need to happen on the web too. Also, don't forget that the web is fantastically backwards compatible. You can write web apps without the complexity if you want to. You can use Dreamweaver! You can server-side render every page. It works. If that's what you want to serve your users then you should do that. Just don't complain when they use the competitor's app that's faster, more responsive, and does fun things like working offline.