8 ms·

Where Yegge’s Wrong

126 points by pw 9y ago

draw_down 9y ago
It's not like I disagree, but the first point is the same god damn pedantic point that gets hit over and over again, that Google's customers are advertisers rather than users. We get it already, and it ignores Yegge's actual point to say the same thing we've heard a million times before. If I never have to read "Unless you're paying, you're not the customer you're the product" again, that shit will be too soon. If they don't make something that people actually want to use, there will be no audience for advertisers. Come on. Lastly, I thought it was funny that both Yegge and Bray can agree to take shots at JavaScript. There's another thing you'd think nerds would get tired of already.
- zeveb 9y ago
  > Lastly, I thought it was funny that both Yegge and Bray can agree to take shots at JavaScript. There's another thing you'd think nerds would get tired of already. Why? JavaScript is really, truly, awfully horrible. It's a local maximum which could easily be escaped with just a very little bit of effort, and the fact that no-one has done so is one of the strongest-possible condemnations of our industry. JavaScript is a shame, an embarrassment and a squandered opportunity. When one thinks that we could have had Scheme, and instead thanks to a benighted Netscape executive we're stuck with JavaScript forever — it is to weep.
  - seibelj 9y ago
    I disagree, I enjoy programming in JavaScript, and I've been around the block. Language and ecosystem improvements have made it a productive (if somewhat quirky) language. We use NodeJS as our backend language at our (serious) software company and it's well tested, clean, and maintainable.
  - erpellan 9y ago
    Feel free to exert that 'just a very little bit of effort', for all our sakes. If it's that easy it shouldn't take more than a couple of days, right? :) I jest. ECMAScript is the most widely installed programming platform on the planet. Ever. How do you even begin to shift that?
    - seanmcdirmid 9y ago
      I'm not sure what JavaScript being the most widely installed platform on the planet has to do with it being a good programming experience. You want to program for the web? You must use Javascript (or something that compiles to Javascript), I don't think many choose Javascript because it is a great programming experience.
      - arvinsim 9y ago
        You comment seems to miss the point of the parent. Regardless of the programming experience, lots and lots of people and platforms use it. Due to network effects, it would be very difficult to shift all of those to a different language.
        seanmcdirmid 9y ago
        Yes, and I was pointing out that parent’s post missed the point of grandparent’s post.
  - deleted 9y ago
    [deleted]
  - dahart 9y ago
    > When one thinks that we could have had Scheme My understanding is that we do (or did) mostly have Scheme with the first release of JavaScript, just with different syntax. What about Scheme, what features or syntax, would be so much better than JS that we should switch? Would you elaborate on what makes JavaScript so bad? How much have you used it yourself? Having done lots of C++ in my life, I find writing JavaScript quite a bit more enjoyable. Especially recently now that the dev tools in all the major browsers have gotten so good.
  - deckard1 9y ago
    Eventually WebAssembly will allow you to use whatever language you want. > When one thinks that we could have had Scheme This may have been true 5 years ago. I'm probably the biggest Scheme fan there is. I've created assemblers, compilers, and even started an OS in Scheme. I've been using Scheme since the late '90s. Modern ES6 and beyond JavaScript is quite nice. I really don't miss Scheme at all. Scheme, mind you, was incredibly limited in R4RS and R5RS, around the time Netscape would have adopted it anyway. It didn't even have a module system, much like old JavaScript. We would be stuck with the largest problem still facing JS: multiple sucky module systems requiring a webpack-like monstrosity.
    - anothergoogler 9y ago
      Single-threaded in a multicore world is nice? Implicit type coercion on par with PHP is nice? Implicit var args are nice??? (That's the worst part by far). I would choose pretty much any non-shell mainstream programming language over JavaScript for a program with results I care about (that is, a useful program). Throwing a bag of syntactic sugar (ES6) on a rotten language is meaningless.
      - kybernetikos 9y ago
        > Single-threaded in a multicore world is nice? Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good model for people who want to write multi-threaded code that doesn't break. This is important when coding for a very open platform like the web. Confusion about what is running on the UI thread and what isn't and how to communicate between them is the kind of error that pops up in java ui code. I wouldn't want that for the web. Besides, the threading approach is more about the runtime rather than the language. There are lots of clustering and threading libraries on npm if you want them for your server-side code, and you have WebWorkers in the browser. Sure, the implicit type coercion (pretty much everyone hates this) and var args (hasnt bothered me as much as it seems to have bothered you) were not good choices, although compare it to other languages of the time - first class functions were by no means universally available and now almost every modern language has them. A literal notation for maps in the language was a great decision too. Prototype inheritance may be a little weird but it is elegant, more general and radically simpler than class based inheritance. Javascript certainly has its warts but I find it fairly productive to code in. Plus it's paired with a runtime that has seen a shocking level of genius engineering over the last 10 years. The speed of iteration is unparalleled. The reach of a deployed piece of code is unique and likely to remain so for the foreseeable future. There aren't many other platforms that have developer tools for inspecting a running system, visualizing ui, network and detailed render performance that are as good.
  - mcphage 9y ago
    > It's a local maximum which could easily be escaped with just a very little bit of effort, and the fact that no-one has done so is one of the strongest-possible condemnations of our industry. I figure, there are 3 possibilities: (1) you're right, and that Javascript is horrible, and the entire software development industry is lazy in not replacing it. (2) it's actually very difficult to replace (3) it's not as bad as you think it is. I'm not sure which is correct, but I wouldn't expect it to be the one that requires malice or incompetence on the part of an entire industry of people who love replacing thing.
  - acheron 9y ago
    Your "Javascript delenda est" comment from a few years ago -- https://news.ycombinator.com/item?id=11447851 https://news.ycombinator.com/item?id=11447851 -- is still one of the best things I've ever read on HN.
    - zeveb 9y ago
      Thank you so very much! It really wasn't written to be persuasive — it's not an argument but rather a series of assertions — but I stand by it today. JavaScript delenda est.
- derefr 9y ago
  I don’t think it’s a pedantic point here; it’s one of the only times this statement is truly relevant to the conclusion you’ll draw from the data. To rephrase Yegge’s original question with this lens: is Google focused more on generating revenue from its customers (advertisers) by hooking users into their service ecosystem? Or are they being unwarrantedly distracted by “competitors” of their offerings, when users’ interest in those competitive offerings isn’t actually decreasing their attachment to the Google services ecosystem at all? See? Very different question.
- dahart 9y ago
  > If I never have to read "Unless you're paying, you're not the customer you're the product" again, that shit will be too soon. If they don't make something that people actually want to use, there will be no audience for advertisers. Come on. Your point is great, and important. The situation is more nuanced than customers vs users. Google has multiple types of customers, and both are important. Free customers using search still have to be appeased by search features, and not too irritated by ads, otherwise ad revenue goes away. Ads customers have to reach a large audience, otherwise they go away. Like many companies, internally Google has departments that are in a sort of competition with each other, and the tension has to maintain an important balance. Ads can't be the only customer, and it can't be the only thing Google cares about. While I'd agree it's getting a bit tired, the context where this aged phrase makes more sense is when discussing privacy. I've seen it most often used to try to get the point across that privacy will never be a goal of free ad-supported internet services. Tired as it is, that point might be worth repeating until the general population and the government actually take it seriously. BTW, I didn't see any shots at JavaScript here, my take was he was defending it.
- wpietri 9y ago
  You may be familiar with it, but reading Yegge's post, I'm still not confident he understands the difference. At least in that section, he seems to treat "customers" and "users" as equivalent groups. For some businesses that's fine, but it's definitely not so for Google. It seems like his real point is that Google is not being innovative on the grand scale. Which is fine, but that's distinct from not being user-focused, and distinct again from not being customer-focused. Those are three different problems, and they get solved three different ways.
IBM 9y ago
> Steve says Android is Google’s most important channel. That’s only if you don’t measure by money. From a business point of view, AdWords is five times more important than anything else. How is AdWords the channel? It seems like the product to me, while Google Search is the vehicle for delivering them. >My personal opinion is that Android originally existed to prevent Apple getting a monopoly lock on the hand-held market and lock Google entirely out of mobile ads. Apple's business model doesn't lend itself to getting a monopoly lock on any business they're in. Apple was always destined to having a nice chunk of the premium market, but someone else would have sprung up to serve everyone else. It could have been Symbian, Blackberry, Microsoft, etc.
- mattnewton 9y ago
  I think it’s easy to look at it with hindsight and say that Apple’s positioning was inevitable, but I certainly didn’t feel that way ten or even five years ago. As is, google pays Apple already a lot of money to be the default search engine on their phones. I imagine that number could have been triple that if no credible rival emerged in the medium/high end phone space.
  - ocdtrekkie 9y ago
    There's about a 0% chance of a company that doesn't license or open up their platform not having a credible rival, because by default, there's a huge open market they're leaving on the table. This is the same with Tesla, and why Tesla cannot be more than a niche member of the EV market in the long run. If anything, the companies we need to worry about are those who offer extensible "open" platforms that build partnerships with most of the industry, while retaining control and decisionmaking authority over them all.
    - mattnewton 9y ago
      What’s wrong with a possible universe where the iPhone is the only modern smartphone, ubuntu/sailfish/Firefox rules the low end, and Tizen or something is keeping one manufacturer alive in the medium end? There are very strong network effects to an app ecosystem, and you can imagine a future where all the high end users are on iOS.
zachrose 9y ago
> Steve correctly notes that front-end programming is hard, but leaves out maybe the single most important reason why: It’s super-hard to unit-test properly. Can anyone elaborate on this?
- contingencies 9y ago
  See Selenium, Chrome headless, Firefox headless, etc.
  - hittaruki 9y ago
    AFIK, thats not unit testing. When you can write unit tests, they are usually lighter, faster to run and easier to maintain. You would use Selenium for integration testing.
- ender7 9y ago
  - UI code spends most of its time interacting with a UI API (Android view framework, whatever iOS uses, DOM/CSS in web). These APIs are enormous and are rarely designed with testing in mind. Mocking or faking the pieces of API that you need to interact with is frequently a daunting or impossible task. - Followup to the above: because so much of the "work" involved with UI code involves interacting with another API, usage of that API tends to spread itself through the entire codebase like cancer. You can create a careful separation of concerns, but it takes a lot of upfront work, verbose boilerplate code, and constant vigilance -- if you're just handed an existing UI codebase you won't have that luxury. - UI code is highly stateful and highly mutable. A core skill in UI programming is managing your app's enormous state profile. Single-path, whole-world rendering techniques like React/other shadow DOM techniques really help here. - UI is highly temporal. It needs to change over time. Testing anything to do with time is an enormous headache. Animations can force you to temporarily separate your underlying state from its representation, which is a testing nightmare. But just in general, writing unit tests that involve time passing is infuriating and fragile (even if you can control time passing via a mocked clock object). - A lot of core functionality in UI involves different pieces handing off to each other -- one window transitions to another window, etc. To test that properly you need integration tests, but now your integration tests also need to interact with the underlying OS/browser (because you can't separate any of that stuff out). So your integration tests are in general way flakier than you can get on UI-less systems that really only need to worry about faking out a DB of some kind.
jeremiep 9y ago
> And last time I looked, all the coolest, hippest, “thought-leader-ish” people I know are building radical JavaScript frameworks. Is he being serious? I can't tell if its a joke or not.
- ardit33 9y ago
  It is sarcasm
  - swyx 9y ago
    is it, actually? the broader context is him saying frontend is hard.
    - ardit33 9y ago
      “thought-leader-ish” people --- the author doesn't really respect those people, and thinks JS is not a great language to build anything game changing.
- deleted 9y ago
  [deleted]
- hliyan 9y ago
  This is the man who wrote "Execution in the Kingdom of Nouns" (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...), one of my all-time favorites. Of course he's joking.
  - faitswulff 9y ago
    > And last time I looked, all the coolest, hippest, “thought-leader-ish” people I know are building radical JavaScript frameworks. Tim Bray wrote this, not Steve Yegge.
pfarnsworth 9y ago
Where Yegge is wrong is that he thinks somehow Grab has moral authority or high ground over Uber. Once he finds out all the scummy things they and everyone else has done in South East Asia, he might have second thoughts about his holier-than-thou attitude.
- jpatokal 9y ago
  Any pointers to "all the scummy things"? Or even some.
ttul 9y ago
“Snoot Mountain” I want a picture of this.
swyx 9y ago
So it looks like Tim Bray is not refuting Yegge's central point: that Android is vulnerable to "stealing" due to someone else (the RN community, which i have to point out is much bigger than Facebook at this point) developing a true xplatform alternative. Thats a very non obvious conclusion and I went from total ignorance to completely agreeing with it in the span of one post. Do people actually agree that Android is that vulnerable? and what -is- the deal with Flutter? Is it Dart 2.0?
- on_and_off 9y ago
  FWWIW, the article was discussed a bit in the Android slack I hang around, and quickly dismissed. The consensus is that there are always big downsides to cross platform solutions and that it is not going to change anytime soon. They have their niche, but currently have zero chances to replace native. Flutter is a runtime for Android and iOS powering apps written in Dart. Flutter itself is written in c++ and Dart. The main originality is that it uses it's own runtime instead of using the platform widgets. It is not as original as its creators would like you to believe though since that's basically what all the cross platform toolkit running in a webview has been doing. The difference is that performances are not atrocious with flutter but they still fall short of being any better than native apps. Flutter could be a big deal if/when Fuchsia becomes a thing it is adopted as its main app runtime. And by 'become a thing' I mean that it completely replaces Android. You would get native dev on 'android z+' and high quality iOS ports very easily.
coldtea 9y ago
>Steve correctly notes that front-end programming is hard, but leaves out maybe the single most important reason why: It’s super-hard to unit-test properly Yeah, no, that's hardly the reason. Besides, it's wrong. It might be harder to functional or integration test properly, but unit-testing front-end code properly is not an issue.
- discodave 9y ago
  100% agree on functional/integ/end to end testing being harder for fronentd. On the other hand, nobody seems to unit-test Javascript where I am. Maybe they're just silly, or maybe it's harder, maybe it's just a lack of tooling. As an aside, it is actually more important to unit test lest "safe" languages. E.g. Java ensures you're passing correct types around at compile time. But with JS/Python et al. you need to unit test to check that you're passing, say a String rather than a tomato.
  - kybernetikos 9y ago
    There are a lot of good unit testing frameworks for javascript. I've worked on teams using them for significant codebases with high unit test coverage for more than 15 years.
  - reggieband 9y ago
    >nobody seems to unit-test Javascript where I am That is an engineering culture thing. I work on a small JS project (node.js server + React FE) that has >95% unit test code coverage. It isn't even difficult to do - it is just not a major part of a lot of front-end teams culture.
commandlinefan 9y ago
> I think a whole lot of programmers would rather work in high-level languages like Ruby and Python That doesn't mean that C++ programmers aren't looking down on those people, though.

126 points by pw 9y ago

It's not like I disagree, but the first point is the same god damn pedantic point that gets hit over and over again, that Google's customers are advertisers rather than users. We get it already, and it ignores Yegge's actual point to say the same thing we've heard a million times before. If I never have to read "Unless you're paying, you're not the customer you're the product" again, that shit will be too soon. If they don't make something that people actually want to use, there will be no audience for advertisers. Come on. Lastly, I thought it was funny that both Yegge and Bray can agree to take shots at JavaScript. There's another thing you'd think nerds would get tired of already.

zeveb 9y ago
> Lastly, I thought it was funny that both Yegge and Bray can agree to take shots at JavaScript. There's another thing you'd think nerds would get tired of already. Why? JavaScript is really, truly, awfully horrible. It's a local maximum which could easily be escaped with just a very little bit of effort, and the fact that no-one has done so is one of the strongest-possible condemnations of our industry. JavaScript is a shame, an embarrassment and a squandered opportunity. When one thinks that we could have had Scheme, and instead thanks to a benighted Netscape executive we're stuck with JavaScript forever — it is to weep.
- seibelj 9y ago
  I disagree, I enjoy programming in JavaScript, and I've been around the block. Language and ecosystem improvements have made it a productive (if somewhat quirky) language. We use NodeJS as our backend language at our (serious) software company and it's well tested, clean, and maintainable.
- erpellan 9y ago
  Feel free to exert that 'just a very little bit of effort', for all our sakes. If it's that easy it shouldn't take more than a couple of days, right? :) I jest. ECMAScript is the most widely installed programming platform on the planet. Ever. How do you even begin to shift that?
  - seanmcdirmid 9y ago
    I'm not sure what JavaScript being the most widely installed platform on the planet has to do with it being a good programming experience. You want to program for the web? You must use Javascript (or something that compiles to Javascript), I don't think many choose Javascript because it is a great programming experience.
    - arvinsim 9y ago
      You comment seems to miss the point of the parent. Regardless of the programming experience, lots and lots of people and platforms use it. Due to network effects, it would be very difficult to shift all of those to a different language.
      - seanmcdirmid 9y ago
        Yes, and I was pointing out that parent’s post missed the point of grandparent’s post.
- deleted 9y ago
  [deleted]
- dahart 9y ago
  > When one thinks that we could have had Scheme My understanding is that we do (or did) mostly have Scheme with the first release of JavaScript, just with different syntax. What about Scheme, what features or syntax, would be so much better than JS that we should switch? Would you elaborate on what makes JavaScript so bad? How much have you used it yourself? Having done lots of C++ in my life, I find writing JavaScript quite a bit more enjoyable. Especially recently now that the dev tools in all the major browsers have gotten so good.
- deckard1 9y ago
  Eventually WebAssembly will allow you to use whatever language you want. > When one thinks that we could have had Scheme This may have been true 5 years ago. I'm probably the biggest Scheme fan there is. I've created assemblers, compilers, and even started an OS in Scheme. I've been using Scheme since the late '90s. Modern ES6 and beyond JavaScript is quite nice. I really don't miss Scheme at all. Scheme, mind you, was incredibly limited in R4RS and R5RS, around the time Netscape would have adopted it anyway. It didn't even have a module system, much like old JavaScript. We would be stuck with the largest problem still facing JS: multiple sucky module systems requiring a webpack-like monstrosity.
  - anothergoogler 9y ago
    Single-threaded in a multicore world is nice? Implicit type coercion on par with PHP is nice? Implicit var args are nice??? (That's the worst part by far). I would choose pretty much any non-shell mainstream programming language over JavaScript for a program with results I care about (that is, a useful program). Throwing a bag of syntactic sugar (ES6) on a rotten language is meaningless.
    - kybernetikos 9y ago
      > Single-threaded in a multicore world is nice? Javascripts approach to threading - default single threaded event loop, but with message passing to communicate with other threads is actually a pretty good model for people who want to write multi-threaded code that doesn't break. This is important when coding for a very open platform like the web. Confusion about what is running on the UI thread and what isn't and how to communicate between them is the kind of error that pops up in java ui code. I wouldn't want that for the web. Besides, the threading approach is more about the runtime rather than the language. There are lots of clustering and threading libraries on npm if you want them for your server-side code, and you have WebWorkers in the browser. Sure, the implicit type coercion (pretty much everyone hates this) and var args (hasnt bothered me as much as it seems to have bothered you) were not good choices, although compare it to other languages of the time - first class functions were by no means universally available and now almost every modern language has them. A literal notation for maps in the language was a great decision too. Prototype inheritance may be a little weird but it is elegant, more general and radically simpler than class based inheritance. Javascript certainly has its warts but I find it fairly productive to code in. Plus it's paired with a runtime that has seen a shocking level of genius engineering over the last 10 years. The speed of iteration is unparalleled. The reach of a deployed piece of code is unique and likely to remain so for the foreseeable future. There aren't many other platforms that have developer tools for inspecting a running system, visualizing ui, network and detailed render performance that are as good.
- mcphage 9y ago
  > It's a local maximum which could easily be escaped with just a very little bit of effort, and the fact that no-one has done so is one of the strongest-possible condemnations of our industry. I figure, there are 3 possibilities: (1) you're right, and that Javascript is horrible, and the entire software development industry is lazy in not replacing it. (2) it's actually very difficult to replace (3) it's not as bad as you think it is. I'm not sure which is correct, but I wouldn't expect it to be the one that requires malice or incompetence on the part of an entire industry of people who love replacing thing.
- acheron 9y ago
  Your "Javascript delenda est" comment from a few years ago -- https://news.ycombinator.com/item?id=11447851 https://news.ycombinator.com/item?id=11447851 -- is still one of the best things I've ever read on HN.
  - zeveb 9y ago
    Thank you so very much! It really wasn't written to be persuasive — it's not an argument but rather a series of assertions — but I stand by it today. JavaScript delenda est.
derefr 9y ago
I don’t think it’s a pedantic point here; it’s one of the only times this statement is truly relevant to the conclusion you’ll draw from the data. To rephrase Yegge’s original question with this lens: is Google focused more on generating revenue from its customers (advertisers) by hooking users into their service ecosystem? Or are they being unwarrantedly distracted by “competitors” of their offerings, when users’ interest in those competitive offerings isn’t actually decreasing their attachment to the Google services ecosystem at all? See? Very different question.
dahart 9y ago
> If I never have to read "Unless you're paying, you're not the customer you're the product" again, that shit will be too soon. If they don't make something that people actually want to use, there will be no audience for advertisers. Come on. Your point is great, and important. The situation is more nuanced than customers vs users. Google has multiple types of customers, and both are important. Free customers using search still have to be appeased by search features, and not too irritated by ads, otherwise ad revenue goes away. Ads customers have to reach a large audience, otherwise they go away. Like many companies, internally Google has departments that are in a sort of competition with each other, and the tension has to maintain an important balance. Ads can't be the only customer, and it can't be the only thing Google cares about. While I'd agree it's getting a bit tired, the context where this aged phrase makes more sense is when discussing privacy. I've seen it most often used to try to get the point across that privacy will never be a goal of free ad-supported internet services. Tired as it is, that point might be worth repeating until the general population and the government actually take it seriously. BTW, I didn't see any shots at JavaScript here, my take was he was defending it.
wpietri 9y ago
You may be familiar with it, but reading Yegge's post, I'm still not confident he understands the difference. At least in that section, he seems to treat "customers" and "users" as equivalent groups. For some businesses that's fine, but it's definitely not so for Google. It seems like his real point is that Google is not being innovative on the grand scale. Which is fine, but that's distinct from not being user-focused, and distinct again from not being customer-focused. Those are three different problems, and they get solved three different ways.

IBM 9y ago

> Steve says Android is Google’s most important channel. That’s only if you don’t measure by money. From a business point of view, AdWords is five times more important than anything else. How is AdWords the channel? It seems like the product to me, while Google Search is the vehicle for delivering them. >My personal opinion is that Android originally existed to prevent Apple getting a monopoly lock on the hand-held market and lock Google entirely out of mobile ads. Apple's business model doesn't lend itself to getting a monopoly lock on any business they're in. Apple was always destined to having a nice chunk of the premium market, but someone else would have sprung up to serve everyone else. It could have been Symbian, Blackberry, Microsoft, etc.

mattnewton 9y ago
I think it’s easy to look at it with hindsight and say that Apple’s positioning was inevitable, but I certainly didn’t feel that way ten or even five years ago. As is, google pays Apple already a lot of money to be the default search engine on their phones. I imagine that number could have been triple that if no credible rival emerged in the medium/high end phone space.
- ocdtrekkie 9y ago
  There's about a 0% chance of a company that doesn't license or open up their platform not having a credible rival, because by default, there's a huge open market they're leaving on the table. This is the same with Tesla, and why Tesla cannot be more than a niche member of the EV market in the long run. If anything, the companies we need to worry about are those who offer extensible "open" platforms that build partnerships with most of the industry, while retaining control and decisionmaking authority over them all.
  - mattnewton 9y ago
    What’s wrong with a possible universe where the iPhone is the only modern smartphone, ubuntu/sailfish/Firefox rules the low end, and Tizen or something is keeping one manufacturer alive in the medium end? There are very strong network effects to an app ecosystem, and you can imagine a future where all the high end users are on iOS.

zachrose 9y ago

> Steve correctly notes that front-end programming is hard, but leaves out maybe the single most important reason why: It’s super-hard to unit-test properly. Can anyone elaborate on this?

contingencies 9y ago
See Selenium, Chrome headless, Firefox headless, etc.
- hittaruki 9y ago
  AFIK, thats not unit testing. When you can write unit tests, they are usually lighter, faster to run and easier to maintain. You would use Selenium for integration testing.
ender7 9y ago
- UI code spends most of its time interacting with a UI API (Android view framework, whatever iOS uses, DOM/CSS in web). These APIs are enormous and are rarely designed with testing in mind. Mocking or faking the pieces of API that you need to interact with is frequently a daunting or impossible task. - Followup to the above: because so much of the "work" involved with UI code involves interacting with another API, usage of that API tends to spread itself through the entire codebase like cancer. You can create a careful separation of concerns, but it takes a lot of upfront work, verbose boilerplate code, and constant vigilance -- if you're just handed an existing UI codebase you won't have that luxury. - UI code is highly stateful and highly mutable. A core skill in UI programming is managing your app's enormous state profile. Single-path, whole-world rendering techniques like React/other shadow DOM techniques really help here. - UI is highly temporal. It needs to change over time. Testing anything to do with time is an enormous headache. Animations can force you to temporarily separate your underlying state from its representation, which is a testing nightmare. But just in general, writing unit tests that involve time passing is infuriating and fragile (even if you can control time passing via a mocked clock object). - A lot of core functionality in UI involves different pieces handing off to each other -- one window transitions to another window, etc. To test that properly you need integration tests, but now your integration tests also need to interact with the underlying OS/browser (because you can't separate any of that stuff out). So your integration tests are in general way flakier than you can get on UI-less systems that really only need to worry about faking out a DB of some kind.

jeremiep 9y ago

> And last time I looked, all the coolest, hippest, “thought-leader-ish” people I know are building radical JavaScript frameworks. Is he being serious? I can't tell if its a joke or not.

ardit33 9y ago
It is sarcasm
- swyx 9y ago
  is it, actually? the broader context is him saying frontend is hard.
  - ardit33 9y ago
    “thought-leader-ish” people --- the author doesn't really respect those people, and thinks JS is not a great language to build anything game changing.
deleted 9y ago
[deleted]
hliyan 9y ago
This is the man who wrote "Execution in the Kingdom of Nouns" (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...), one of my all-time favorites. Of course he's joking.
- faitswulff 9y ago
  > And last time I looked, all the coolest, hippest, “thought-leader-ish” people I know are building radical JavaScript frameworks. Tim Bray wrote this, not Steve Yegge.

pfarnsworth 9y ago

Where Yegge is wrong is that he thinks somehow Grab has moral authority or high ground over Uber. Once he finds out all the scummy things they and everyone else has done in South East Asia, he might have second thoughts about his holier-than-thou attitude.

jpatokal 9y ago
Any pointers to "all the scummy things"? Or even some.

ttul 9y ago

“Snoot Mountain” I want a picture of this.

swyx 9y ago

So it looks like Tim Bray is not refuting Yegge's central point: that Android is vulnerable to "stealing" due to someone else (the RN community, which i have to point out is much bigger than Facebook at this point) developing a true xplatform alternative. Thats a very non obvious conclusion and I went from total ignorance to completely agreeing with it in the span of one post. Do people actually agree that Android is that vulnerable? and what -is- the deal with Flutter? Is it Dart 2.0?

on_and_off 9y ago
FWWIW, the article was discussed a bit in the Android slack I hang around, and quickly dismissed. The consensus is that there are always big downsides to cross platform solutions and that it is not going to change anytime soon. They have their niche, but currently have zero chances to replace native. Flutter is a runtime for Android and iOS powering apps written in Dart. Flutter itself is written in c++ and Dart. The main originality is that it uses it's own runtime instead of using the platform widgets. It is not as original as its creators would like you to believe though since that's basically what all the cross platform toolkit running in a webview has been doing. The difference is that performances are not atrocious with flutter but they still fall short of being any better than native apps. Flutter could be a big deal if/when Fuchsia becomes a thing it is adopted as its main app runtime. And by 'become a thing' I mean that it completely replaces Android. You would get native dev on 'android z+' and high quality iOS ports very easily.

coldtea 9y ago

>Steve correctly notes that front-end programming is hard, but leaves out maybe the single most important reason why: It’s super-hard to unit-test properly Yeah, no, that's hardly the reason. Besides, it's wrong. It might be harder to functional or integration test properly, but unit-testing front-end code properly is not an issue.

discodave 9y ago
100% agree on functional/integ/end to end testing being harder for fronentd. On the other hand, nobody seems to unit-test Javascript where I am. Maybe they're just silly, or maybe it's harder, maybe it's just a lack of tooling. As an aside, it is actually more important to unit test lest "safe" languages. E.g. Java ensures you're passing correct types around at compile time. But with JS/Python et al. you need to unit test to check that you're passing, say a String rather than a tomato.
- kybernetikos 9y ago
  There are a lot of good unit testing frameworks for javascript. I've worked on teams using them for significant codebases with high unit test coverage for more than 15 years.
- reggieband 9y ago
  >nobody seems to unit-test Javascript where I am That is an engineering culture thing. I work on a small JS project (node.js server + React FE) that has >95% unit test code coverage. It isn't even difficult to do - it is just not a major part of a lot of front-end teams culture.

commandlinefan 9y ago

> I think a whole lot of programmers would rather work in high-level languages like Ruby and Python That doesn't mean that C++ programmers aren't looking down on those people, though.