5 ms·

This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.

by shawn 8y ago

King-Aaron 8y ago
> having a blast ignoring us and building the apps of the future Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.
sonnyblarney 8y ago
My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.
BigJono 8y ago
Nah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems. IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion. For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise. The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it). The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day). I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)
pjmlp 8y ago
Yeah and then they all jump around React as some amazing achievement, having rediscovereed how 90's native UI do event handling.
- chadcmulligan 8y ago
  and think vi is great
- akx 8y ago
  Event handling isn't special in React. One-way data flow and UI-as-a-function-of-state are. Which 90s native UI toolkits do that?
  - pjmlp 8y ago
    "Flux is the new WndProc" https://news.ycombinator.com/item?id=10381015 https://news.ycombinator.com/item?id=10381015
- jhomedall 8y ago
  React isn't really anything like 90s UI libraries. It is, however, very much like the fairly recent native immediate-mode GUIs that have come out (https://github.com/ocornut/imgui https://github.com/ocornut/imgui, https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod, etc). The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your current UI state to the new UI state (hide this button, disable this input, etc).
  - pjmlp 8y ago
    Smalltalk UIs used a pattern called dependency propagation to make objects update themselves based on system wide notifications. Similar idea was used on Oberon System 3 Gadgets toolkit. Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.
    - 8y ago

This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.

by shawn 8y ago

This is what us older people would like to believe. Meanwhile the young webdevs are having a blast ignoring us and building the apps of the future.

King-Aaron 8y ago

> having a blast ignoring us and building the apps of the future Building technical debt for the future I tend to think, which I guess is good for keeping future devs employed.

sonnyblarney 8y ago

My experience is that young web-devs don't even know the dystopian matrix they live in, and when they discover 'regular programming', in many ways their perspective changes. Both web and regular dev have their faults but the the King of Byzantium is HTML5.

BigJono 8y ago

Nah, it's mostly true (I'm one of those young webdevs), but I'd attribute the pain points in front-end development to slightly different problems than the state of browser inconsistencies and spec problems. IME 70% of the problems people run into are self-inflicted due to overengineered solutions. I spend a lot of time lurking front-end IRC channels and most of the problems that get posted is stuff that I have never had trouble with, with libraries I'd never even consider using, that I don't have the first clue how to fix without going back to square one and re-engineering the solution from the ground up. The advice given by people that do attempt to help with these problems is often awful and creates more confusion. For the most part, I don't think people realise that libraries add to the complexity of their software, rather than abstracting it away. Every front-end dev desperately needs to go and read the Law of Leaky Abstractions, because they're getting smoked by it on a daily basis and they don't realise. The other 30% of problems come down to what GP mentioned, ambiguous specs, browser inconsistencies etc. Stuff like the relationship between x-overflow and y-overflow, little flexbox niggles like different behaviour depending on if flex-direction is set to row or column etc etc. This stuff can often be worked around with simple but unintuitive fixes (usually some fuckery with negative marigns and such), the two difficulties lie in discovering the solution to begin with (there's boatloads of bad and outdated advice everywhere), and running into these solutions when they haven't been properly documented (usually the case if some junior programmer has just ripped the hack off SO without understanding the theory behind it). The secret to being good at front-end dev is to develop strategies to handle these problems, and to pick your resources very carefully (much as you would in any other ecosystem beset with noobs, like PHP back in the day). I believe (based on my experience) that it's possible to build very successful software with very horrible engineering. Good and successful aren't necessarily synonymous in the world of big VC money. A great example is this: I need two hands to count the critical failure bugs I've run into with Uber's products in the last year. By critical failures I mean things that have flat out stopped me from being able to use it. I strongly suspect (a subset of) their engineering sucks (sorry to anyone here that works for them!). But hey, I don't own a squillion dollar company so what do I know? ;)

pjmlp 8y ago

Yeah and then they all jump around React as some amazing achievement, having rediscovereed how 90's native UI do event handling.

chadcmulligan 8y ago
and think vi is great
akx 8y ago
Event handling isn't special in React. One-way data flow and UI-as-a-function-of-state are. Which 90s native UI toolkits do that?
- pjmlp 8y ago
  "Flux is the new WndProc" https://news.ycombinator.com/item?id=10381015 https://news.ycombinator.com/item?id=10381015
jhomedall 8y ago
React isn't really anything like 90s UI libraries. It is, however, very much like the fairly recent native immediate-mode GUIs that have come out (https://github.com/ocornut/imgui https://github.com/ocornut/imgui, https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod, etc). The core feature of React is that your UI is a pure function of your application state. In (e.g.) the Win32 UI, you would receive events, and then need to manually transition your current UI state to the new UI state (hide this button, disable this input, etc).
- pjmlp 8y ago
  Smalltalk UIs used a pattern called dependency propagation to make objects update themselves based on system wide notifications. Similar idea was used on Oberon System 3 Gadgets toolkit. Also java.util.Observable based on the same Smalltalk ideas was already part of Java 1.0.
  - 8y ago