4 ms·

After reading the entire thread I am still in the dark about what exactly the author wants to see changed. The narrative that frameworks = bad and vanilla js =

by stemuk 4y ago

After reading the entire thread I am still in the dark about what exactly the author wants to see changed. The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.

Aeolun 4y ago
I’ve heard stuff like this before. The people that say it are generally advocating for plain HTML/CSS/JS.
cynicalreason 4y ago
I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete
- rubyfan 4y ago
  I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.
  - expanseoftrees 4y ago
    Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?
  - smt88 4y ago
    I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else. Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
    - drewcoo 4y ago
      > Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. True, but Twitter threads are the Burma Shave signs of the tech-gentsia. https://en.wikipedia.org/wiki/Burma-Shave https://en.wikipedia.org/wiki/Burma-Shave https://www.legendsofamerica.com/66-burmashave/2/ https://www.legendsofamerica.com/66-burmashave/2/
  - scrapcode 4y ago
    At first I found it surprising to start finding all of these Twitter threads making it to the front of HN and thought "well, it must be a really compelling message..." Now I just ignore them altogether. It is a very distracting medium for the longer posts, and that distraction shows through from the writers side as well.
  - alcover 4y ago
    > hate Twitter threads Me too. They are absurd, hard to read and a waste of resource (load time, requests, steaming pile of JS). They sould be penalized/barred.
- Gigachad 4y ago
  Sums up the majority of whinging about JS you see online. I’m confused what “the front end community” even is.
Retric 4y ago
JavaScript and CSS both provide abstractions for complexity. So, I am not sure exactly what your point is?
talkingtab 4y ago
I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?
- slightlyoff 4y ago
  OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor). More pithily, maybe PHP was good, actually? Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls. Some of that is captured in this post; hope it helps: https://infrequently.org/2022/05/performance-management-maturity/ https://infrequently.org/2022/05/performance-management-matu...
  - em-bee 4y ago
    so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote: JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff. what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency. my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast. to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s
distopico 4y ago
I think is because JS is one of the few languages that has practically always been used with a layer on top, before with Jquery or other libraries and now with frameworks, that is not so common in other languages, JS has an external layer for everything
azangru 4y ago
> The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion. Consider that Chrome Dev Tools are built with vanilla js (plus web components). I would call it a medium-to-large-sized project, wouldn't you? Although Chrome Dev Tools isn't the kind of use case that Alex has in mind when he rants on Twitter. His concern is the mobile web; his reference is a weak Android device (used to be a Moto G4) on a 4g mobile network. Which kinda ignores that there are valid use cases for sites that are built as apps primarily for stationary desktop users.

by stemuk 4y ago

Aeolun 4y ago

I’ve heard stuff like this before. The people that say it are generally advocating for plain HTML/CSS/JS.

cynicalreason 4y ago

I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete

rubyfan 4y ago
I couldn’t even get through it. I sort of hate Twitter threads. Lost are the days of making your point in 140 characters or less.
- expanseoftrees 4y ago
  Haha I created an account just to agree. There’s no content to this twitter thread. I think he’s anti mainstream? That’s his signal?
- smt88 4y ago
  I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else. Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
  - drewcoo 4y ago
    > Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. True, but Twitter threads are the Burma Shave signs of the tech-gentsia. https://en.wikipedia.org/wiki/Burma-Shave https://en.wikipedia.org/wiki/Burma-Shave https://www.legendsofamerica.com/66-burmashave/2/ https://www.legendsofamerica.com/66-burmashave/2/
- scrapcode 4y ago
  At first I found it surprising to start finding all of these Twitter threads making it to the front of HN and thought "well, it must be a really compelling message..." Now I just ignore them altogether. It is a very distracting medium for the longer posts, and that distraction shows through from the writers side as well.
- alcover 4y ago
  > hate Twitter threads Me too. They are absurd, hard to read and a waste of resource (load time, requests, steaming pile of JS). They sould be penalized/barred.
Gigachad 4y ago
Sums up the majority of whinging about JS you see online. I’m confused what “the front end community” even is.

Retric 4y ago

JavaScript and CSS both provide abstractions for complexity. So, I am not sure exactly what your point is?

talkingtab 4y ago

I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?

slightlyoff 4y ago
OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor). More pithily, maybe PHP was good, actually? Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls. Some of that is captured in this post; hope it helps: https://infrequently.org/2022/05/performance-management-maturity/ https://infrequently.org/2022/05/performance-management-matu...
- em-bee 4y ago
  so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote: JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff. what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency. my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast. to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s

distopico 4y ago

I think is because JS is one of the few languages that has practically always been used with a layer on top, before with Jquery or other libraries and now with frameworks, that is not so common in other languages, JS has an external layer for everything

azangru 4y ago

> The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion. Consider that Chrome Dev Tools are built with vanilla js (plus web components). I would call it a medium-to-large-sized project, wouldn't you? Although Chrome Dev Tools isn't the kind of use case that Alex has in mind when he rants on Twitter. His concern is the mobile web; his reference is a weak Android device (used to be a Moto G4) on a 4g mobile network. Which kinda ignores that there are valid use cases for sites that are built as apps primarily for stationary desktop users.