5 ms·

I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the diff

by heyoni 7y ago

I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.

slx26 7y ago
Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!
- dpau 7y ago
  For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)
- EpicEng 7y ago
  For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening. Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why. Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
  - xrd 7y ago
    And the documentation is written by fanboys who are marketing it more than they are documenting it.
    - EpicEng 7y ago
      Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.
- heyoni 7y ago
  And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\
- Dig1t 7y ago
  To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.
  - rhn_mk1 7y ago
    With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?). Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
- jdashg 7y ago
  Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.
- gerbilly 7y ago
  It's the difference between a difficult problem, and a complex one. I think most of us here would find complexity more interesting. Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
- muzani 7y ago
  I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.
hajile 7y ago
Flexbox? That's way easier than float design and both of those are way easier than designing everything with tables.
- heyoni 7y ago
  I know...and I kind of got the gist of it except I had a lot of trouble developing an intuition for it by trying to understand the history, other methods and just basically copying source code from existing websites...it's just my process for learning new things and it quickly gets overwhelming with front-end development...
  - afarrell 7y ago
    Repeatedly playing https://flexboxfroggy.com/ https://flexboxfroggy.com/ is better for developing intuition.
    - heyoni 7y ago
      I absolutely need to get back into front-end so thanks for that!
    - scns 7y ago
      https://mastery.games https://mastery.games is fun too
  - benbristow 7y ago
    I see what you mean. I've been using flexbox for a while now and still get muddled up if align- or justify- is vertical or horizontal Thankfully with modern browsers nowadays you can open up their dev tools and use them as a 'scratchpad' to play about with CSS.
  - wlesieutre 7y ago
    I like this guide for flexbox: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Breaks it down into simple pieces and explains with clear diagrams.
taf2 7y ago
Really? I mean sure maybe the solution to your race condition is a thread safe queue... but if that’s not it then I definitely think fixing an issue with css is way easier... also The DOM api is finite and pretty well documented... MDN has done a pretty good job. Maybe something with WebRTC is trickier?
jancsika 7y ago
I'll take flexbox then. And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.
dexwiz 7y ago
I don't know, but I would rather weld steel together in a sky scraper than figure out how to hang cabinets or even understand all the different types of crown molding. I always think the backend versus front end statements are hilarious when cast to other activites. They always carry a tone of derision while completely missing the point that they are different problem spaces and skill sets.
- saidajigumi 7y ago
  Also, {french cleats,flexbox} are awesome for {hanging stuff, sane and responsive page layout} and really pretty simple. [1] https://en.wikipedia.org/wiki/French_cleat https://en.wikipedia.org/wiki/French_cleat
baddox 7y ago
Might that be simply because you are more interested in the one thing than the other? I can't come up with any objective measure of complexity that could show flexbox as being more complex than multithreading.
- heyoni 7y ago
  A large part is definitely because I get overwhelmed and have trouble ignoring the "magic" that the article talks about.
jwilliams 7y ago
Actually agree -- but with some nuance. I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal... Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."
reroute1 7y ago
To be fair you can have most of this on the front end also
robocat 7y ago
> rather fix a race condition on a multithreaded application You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks). Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout(). Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(
arithma 7y ago
Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism. The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated. I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up. Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack. I would not dread doing frontend development, if allowed to do things correctly.
austincheney 7y ago
The DOM is stupid easy. Start with this: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml

by heyoni 7y ago

I don't know, but I do know I would rather fix a race condition on a multithreaded application than figure out how flexbox works or even understand all the different parts of the DOM.

slx26 7y ago

Heh. I kinda felt: "hey, I agree with that", so I started asking myself why. What's the difference? Somehow, it looks like the difference is that on one side you have a very complicated problem but in a potentially well defined and bounded environment, and on the other you may have "smaller" problems, but on an environment so vast and complex that's kinda impossible to assert that you are doing things "properly". There are so many parts always changing at the same time!

dpau 7y ago
For me it's more related to why i became a developer- i love coming up with elegant solutions to interesting, challenging problems. trying to figure out why some inane CSS rule isn't working in an old version of IE due to some arcane non-compliant vendor-specific implementation just isn't very fun. (But thats also why i use frameworks like bootstrap and bulma.)
EpicEng 7y ago
For me, having come from robotics/digital imaging/signal processing and now doing web dev, I feel exactly this. My old problems were far more technical, but I could always form a complete mental model of what was happening. Now I feel like I have little hope. I'm under the foot of 117 leaky abstractions which all have their own opinion as to how things should work. It's near impossible to peek too deeply inside, so I just try shit until it works and then attempt to figure out why. Some of my happier moments are when I get to add to one of our older sites that use server side generated pages. Even then though... not the same as debugging an errant pixel.
- xrd 7y ago
  And the documentation is written by fanboys who are marketing it more than they are documenting it.
  - EpicEng 7y ago
    Yeah, it's really hit or miss. I enjoyed my 320 page manuals written by cynical, hardened, life-worn EE's.
heyoni 7y ago
And everything carries over too. Parts of the DOM are historical or there to fix historical incompatibilities, there are 18 different ways to create your CSS grids, many of which are outdated...oddly enough, I had no problem understanding how/why observability works, but really disliked writing JavaScript :\
Dig1t 7y ago
To me, the difference feels like in one scenario you are solving problems fundamental to computing and the other you are struggling to wrangle with a dumb arbitrary API that someone made up. The former is much more exciting to me, and I suspect most CS people. That's not to say web development is all dumb arbitrary API's or you don't get to solve interesting problems, just much less cool/interesting IMO.
- rhn_mk1 7y ago
  With the given example of working with threads, I don't get the feeling that the problem is somehow fundamental to computing. It would involve the somewhat-arbitrary threading interface, with decisions differing based on the API (WinAPI? POSIX? cooperative multithreading?) someone made up, with a set of locking primitives currently in vogue (mutexes? semaphores? lockless? message passing?). Having done a lot of systems programming, my main complaint is that I'm almost always dealing with other people's models. I might be coming across fundamental problems in algorithms, but those are a tiny part of my work.
jdashg 7y ago
Known unknowns vs unknown unknowns. "I know how this should work but something's wrong" vs "how am I supposed to do this? Should I do this? Will this other thing change?" Hackers are fine with it, but system architects hate that uncertainty.
gerbilly 7y ago
It's the difference between a difficult problem, and a complex one. I think most of us here would find complexity more interesting. Most difficult problems are difficult for uninteresting reasons (uncertainty about how some API works, having to maintain poorly written code, unclear requirements or business rules...)
muzani 7y ago
I think it's the difference between trying to keep a log cabin up and trying to keep a sand castle steady. The sand castle gives so much more anxiety and a fix threatens to break other fixes.

hajile 7y ago

Flexbox? That's way easier than float design and both of those are way easier than designing everything with tables.

heyoni 7y ago
I know...and I kind of got the gist of it except I had a lot of trouble developing an intuition for it by trying to understand the history, other methods and just basically copying source code from existing websites...it's just my process for learning new things and it quickly gets overwhelming with front-end development...
- afarrell 7y ago
  Repeatedly playing https://flexboxfroggy.com/ https://flexboxfroggy.com/ is better for developing intuition.
  - heyoni 7y ago
    I absolutely need to get back into front-end so thanks for that!
  - scns 7y ago
    https://mastery.games https://mastery.games is fun too
- benbristow 7y ago
  I see what you mean. I've been using flexbox for a while now and still get muddled up if align- or justify- is vertical or horizontal Thankfully with modern browsers nowadays you can open up their dev tools and use them as a 'scratchpad' to play about with CSS.
- wlesieutre 7y ago
  I like this guide for flexbox: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ https://css-tricks.com/snippets/css/a-guide-to-flexbox/ Breaks it down into simple pieces and explains with clear diagrams.

taf2 7y ago

Really? I mean sure maybe the solution to your race condition is a thread safe queue... but if that’s not it then I definitely think fixing an issue with css is way easier... also The DOM api is finite and pretty well documented... MDN has done a pretty good job. Maybe something with WebRTC is trickier?

jancsika 7y ago

I'll take flexbox then. And while my upstream devs will be happily accepting my patch because it quite obviously visually fixes the problem, you'll still be explaining to your upstream why their "perfect" ad hoc threading abstraction is indeed broken.

dexwiz 7y ago

I don't know, but I would rather weld steel together in a sky scraper than figure out how to hang cabinets or even understand all the different types of crown molding. I always think the backend versus front end statements are hilarious when cast to other activites. They always carry a tone of derision while completely missing the point that they are different problem spaces and skill sets.

saidajigumi 7y ago
Also, {french cleats,flexbox} are awesome for {hanging stuff, sane and responsive page layout} and really pretty simple. [1] https://en.wikipedia.org/wiki/French_cleat https://en.wikipedia.org/wiki/French_cleat

baddox 7y ago

Might that be simply because you are more interested in the one thing than the other? I can't come up with any objective measure of complexity that could show flexbox as being more complex than multithreading.

heyoni 7y ago
A large part is definitely because I get overwhelmed and have trouble ignoring the "magic" that the article talks about.

jwilliams 7y ago

Actually agree -- but with some nuance. I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal... Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."

reroute1 7y ago

To be fair you can have most of this on the front end also

robocat 7y ago

> rather fix a race condition on a multithreaded application You can fix race conditions on single threaded JavaScript code now we have async (and promises): it scares me how little this is recognised as a downside and in my experience few people are good at recognising or writing code that avoids race conditions (I have seen competent programmers in denial about the risks). Before async I found race conditions in popular (and well written) JavaScript code that used setTimeout(). Personally I think anyone that enjoys chasing race conditions is mad: I loath reproducing transient errors. I have mostly tried hard to avoid async code in my own JavaScript, but sometimes it is forced upon me :-(

arithma 7y ago

Everyone expects the frontend to be easy, especially non-engineers: "hey, it's just a box, and you can just resize it and center it just that way..", while non-engineers would just move away when you mention thread/concurrency/parallelism. The outside perception, I am afraid, affects me. I don't want to be stuck all the time doing things that are equally hard, but much less appreciated. I have a lot of respect for frontend development, and approach it with the same kind of caution and respect that I do the backend stuff, however that is not always appreciated, and since it can get complicated fast, and people are expected to finish quickly as if on a treadmill, those things get messed up, hacked, and brittled up. Another analysis paralysis issue with frontend is cost/benefit for doing it "right." Since frontend is a leaf and not the dependency of another layer in the application, it becomes dispensible to a certain extend in some scenarios. It is seen as replaceable and not worth spending a lot of time on. So when working on frontend, second guessing whether it will be scrapped off later is always hanging in there, paralysing you between "engineering" mode, or just give it a quick hack. I would not dread doing frontend development, if allowed to do things correctly.

austincheney 7y ago

The DOM is stupid easy. Start with this: https://prettydiff.com/2/guide/unrelated_dom.xhtml https://prettydiff.com/2/guide/unrelated_dom.xhtml