9 ms·

Responsible JavaScript: Part I

132 points by wheresvic1 7y ago

Allower 7y ago
Funny that the usability of this post goes to shit with ad and script blockers. Guess they care more about Luddites than privacy conscious users. Talk about poor judgement..
perttir 7y ago
Anybody else has issue with the side banners being on top of the text in the Firefox?
userbinator 7y ago
We need to know the purpose we’re trying to serve, and only then can we build something that admirably serves that purpose—even if it isn’t exciting to build. I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. There seems to be a very strong "if it's not new it's bad" sentiment[1], and as a result, the amount of churn is also extremely high. What's so "exciting" about doing more with less? As an aside, it is good to see that this article is completely readable without JS. [1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" --- despite it working in more browsers and being over an order of magnitude less code than their proposed "proper web development" solutions. They are correct, I am not a "real web developer", but when I write JS it's usually because I have a problem to solve and don't have any other choice.
- nullandvoid 7y ago
  Did you mean to write `What's so "exciting" about doing more with less?` I think the answer is obvious... More on topic I think more context is needed on your anecdote. Was you developing a small tool that's likely to balloon into a suite of tools etc? There may have been a variety of other factors to consider whether it may be worthwhile investing into a framework in the long term I'm not saying that your sentiment isn't at least a little true - but creating complex modern web applications is hard and frameworks CAN be the right decision depending on requirements.
- hliyan 7y ago
  RE: "not modern enough" I often hear the following versions: "that's not the current paradigm" or, "that's not recommended"
  - TheRealPomax 7y ago
    Those should not be ignored, but they should be immediately followed up with by "why?" because understanding why the old paradigm didn't work, or why something isn't recommended, is important knowledge to have. If you tune out when someone tells you no, without asking why, you haven't started learning yet. There might be great reasons for why the current paradigm is actually preferred, or why that code you wrote is actually really bad because a single edge case that just happens to be severe enough. Until you ask why, you won't know, and your decisions will not be informed decisions.
    - hliyan 7y ago
      The sad part is, those are the answers to my question "why"...
  - JustSomeNobody 7y ago
    > "that's not the current paradigm" or, "that's not recommended" When I see these words, I think these are followers. They don't truly understand why they are doing what they're doing, but "everyone else" is doing it, so it must be good.
- olavgg 7y ago
  I am also a classic web developer, still using vanilla javascript and trying to do as much as possible with just html and css. I feel I can solve any problem fast, quick and with minimal amount of code and bugs. For the recent years I have hired a few javascript developers and a common pattern I see is that the reason why they want to use overcomplicated toolset, is because this helps improving their CV so they are easier to sell. CV building is a thing, and developers also want to stay relevant in the future. For example I went through software developer job listings in my area. Of 100 listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any kind of frontend development like html/css/jquery. The rest is classical back end positions. There is a HUGE demand for frontend expertise these days. If you as a consultant want to sell yourself as a kickass rockstar frontend developer, you want as much React experience as possible on your CV. Some will even turn you down because of the fear of damaging their CV by just doing vanilla javascript work.
  - JohnFen 7y ago
    > still using vanilla javascript and trying to do as much as possible with just html and css. Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much. If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.
  - bernawil 7y ago
    Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.
    - mosdl 7y ago
      React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
- geowwy 7y ago
  > I wonder if there is a common > mindset that the majority of > web developers have which > causes them to love > overcomplexity so much We don’t love complexity, we love ease. The complexity is a side affect of us trying to make our job easy by `npm install`ing various tools/libraries/frameworks :) Another problem is the web is inherently complicated, and people expect more and more from the web. We’re still working out how to best manage the complexity and increased demands.
  - hobs 7y ago
    Taking on a huge amount of dependencies only (potentially) makes your life easier up front. You now get to experience all bugs and side effects for all projects you now took on "due to ease." You now effectively maintain all those projects, instead of your own. You cannot go to your customers and say "well this library isnt working so neither is our website, and we can upgrade without it."
    - jamescostian 7y ago
      You also cannot go to your customers and say "well instead of using a popular library, we used our own and it broke and so did your site" And more importantly, NIH leads to on-boarding issues. Many, many people are React/Angular/Vue developers, but how many are $INTERNAL_RECREATION_OF_REACT developers? By creating a new framework, you waste money (not just on reinventing the wheel and fixing bugs in your new wheel, but also on having every new-hire take even longer to get productive)
      - userbinator 7y ago
        Code that you've written also tends to be code you have an understanding of, and thus much easier to debug than a maze of third-party dependencies. The extreme aversion to "reinventing the wheel" leads to things like left-pad.
- ConfusedDog 7y ago
  It goes into why we need design systems, software architectures, libraries at all? Because of communication and managing complexity. You give 5 developers one single set of requirements, their approach to the problem likely to be drastically different. Could their solutions be effective? Very likely to be. But that's not large projects are about, they are about continuity of the projects without locking into developers. For developers want to solve a problem quickly, you are correct - and more power to you because no one else (mostly) can understand your code. Job security FTW there. I think most of companies starting to realizing they can't keep people like you very long. You are both capable and stubborn (most likely). That's why job market is shifting towards mediumly skilled team and process oriented developers. Hope that makes sense.
- qudat 7y ago
  > I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; This is, in turn, is a weird mindset. Are you suggesting that web developers are somehow unique in the software development space? Here's a hint: they aren't. The problems that web developers have to solve are relatively unique to the platform. When is 1MB of code a lot? This is not amount of code written, this is amount of code used. In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because it doesn't have to be downloaded over HTTP like javascript. That is a unique feature of web development. What do you think would happen if developers around the world started complaining about using `numpy`? It's the same thing with libraries like `react`: they have no credibility because `react` is useful. It has nothing to do with web developer mindset, everyone wants to bring in libraries that make their lives easier.
  - gambler 7y ago
    >In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because some random Joe Schmoe can't replace numpy with a few lines of vanilla Pyton. Because numpy has a governing organization and isn't just an arbitrary library some unknown developer dumped on NPM. Because numpy is over a decade old and isn't any in danger of being superseded on the basis of not being fashionable.
    - phponpcp 7y ago
      Literally none of those things apply to React though.
- jakelazaroff 7y ago
  > I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. Is this really unique to (frontend) web developers? I've heard plenty of stories of people building tangled webs of microservices when a monolith would be fine, using Kubernetes to run their weblog, using Hadoop with small datasets, etc.
- jsight 7y ago
  > [1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" I've said this in code reviews a few times. In ever case, it was because someone was using some construct that would have been needed in older Javascript versions, but was no longer necessary in whatever deployment we were supporting as a minimum. Sometimes it was from taking old Javascript conventions into Typescript. In ever case, the original code was a workaround for old bugs. Can you cite an example?
- Zelphyr 7y ago
  I once worked with a guy who, after looking at a solution provided by our team that not only worked but was fast and efficient, said, “This can’t be any good. You don’t have enough code.” He was in a leadership position. This way of thinking isn’t restricted to our industry. I see it in other areas as well. People naturally equate complexity with quality and actually have a hard time appreciating the beauty of a well-designed, well-thought out, efficient system. Why that is is beyond me.
  - JohnFen 7y ago
    > People naturally equate complexity with quality Which is weird because, generally speaking, higher code complexity is a signal of lower quality.
azangru 7y ago
> Most layout issues JavaScript packages attempt to solve, like box placement, alignment, and sizing, managing text overflow, and even entire layout systems, are solvable with CSS today. This paragraph has surprising links. "Managing text overflow" links to Shave, a library for truncating multiline text[0]. Last time I checked, CSS was capable of truncating single-line text, but could not truncate multiline text (the line-clamp rule is still not universally supported). The first link in that paragraph is to a flexbox polyfill, and obviously, there's a reason why people use polyfills. [0] - https://www.npmjs.com/package/shave https://www.npmjs.com/package/shave
- comis 7y ago
  Yea there's plenty of benefits using a truncation library (we're currently using react-lines-ellipsis) over just css truncation. More control over how the truncation happens, callback so you can do more stuff on the condition that truncation has occurred, multi-line truncation as you mentioned, etc etc. I get the feeling that most of the time when people are complaining about unnecessary libraries they simply haven't personally run into the problem that the library solves yet.
  - draw_down 7y ago
    > I get the feeling that most of the time when people are complaining about unnecessary libraries they simply haven't personally run into the problem that the library solves yet. Ding ding ding. "CSS does that!" is such an easy meme to replicate. Let's all try to consider that web developers are not just insane freaks who love to put JavaScript where it doesn't belong, and instead just regular people trying to solve problems like anyone else.
ChicagoBoy11 7y ago
TL;DR: Use the platform
rmrfrmrf 7y ago
Such are the contradictions of the web that we shun constant code churn while at the same time giving full-throated endorsements of Service Workers.
ascotan 7y ago
This all started with angular imho. There was a time when structure, layout and logic were more cleanly separated. Angular blew this up with <ng-xxx> tags (which was a step backwards towards PHP imho) and this has been driven forward by other frameworks since. It surprising to me how so many people can talk about shadow dom but can't name any of the HTML5 apis or even more than a few tags and what they do (much less anything about CSS3).
- pault 7y ago
  One of my interview questions is "how do you organize logic and state in a react app?" and about 19/20 candidates put their business logic in their view components. I believe the root of the problem is the ecosystem of terrible react tutorials that are targeted at beginners so can't introduce complex architecture. If you spend some time reading react blogs you'll see that almost all of them put their API requests and business logic inside component lifecycle methods. The flood of bootcamp grads has made hiring competent front end devs nearly impossible (not to slander bootcamp grads; I've met a few that are brilliant).
  - ep103 7y ago
    >you'll see that almost all of them put their API requests and business logic inside component lifecycle methods Edit: (I rephrased this post) I understand that logic often makes sense to break out between presentational and container components, and I understand that sometimes api / service calls should be broken out into their own files, but everything I've read states that api logic should be called from ComponentDidMount.... you are saying that you shouldn't make api calls, from component lifecycle methods whatsoever? I'm not sure what the alternative is?
    - c0wboyc0ding 7y ago
      I would also love to see resources that detail how to separate business logic from view components. As a junior dev, I know it's the right thing to do but I'm not sure how. Is it as simple as passing props into a utils file? Any links would be greatly appreciated.
Tade0 7y ago
These are valid concerns and fortunately there are already examples of potential solutions being developed: https://svelte.technology https://svelte.technology Not saying this specific framework is going to be a success, but so far it both: - Is mostly "batteries included". - Indeed does create pretty small bundles.
- moosingin3space 7y ago
  The really nice thing about Svelte is that it treeshakes really well. I wrote a Firefox extension with Svelte (v1), and when Svelte v3 becomes stable I will be very excited to upgrade.
briantakita 7y ago
Here is a "Real World" comparison of Front End Frameworks, which includes payload size. https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075 https://medium.freecodecamp.org/a-realworld-comparison-of-fr...
gorpomon 7y ago
Complexity in JavaScript is not a code issue, it's a UI issue. Complicated UI's necessitate frameworks, not developers. When a website hits a certain level of UI interactions, I arbitrarily say around 10 per page, then HTML/CSS/"A sprinkle of JS" becomes unsustainable. Shipping 400kb of React isn't ideal, but to manage your complexity it is responsible. Let's say your page has the following: - Custom form validations - Custom styled <Select> tags - Forms that should show full lifecycle on submit without page refresh (form accepted, form error, sometimes API's return a 200 that is actually a failure :-/ ) - Inline editing of some user data. - Badges based on your users activity. - Notifications of new items. - Navigation styling that is JS powered in some way, or un-achievable or kind of a schlep with CSS (maybe the links are API powered :-/ ). - A table with sorting/filtering - Drag and drop reordering - Some type of chat window Now let's increase complexity and say all those things respond in some way to changes in the other things. I've built that page. That page is no longer a website. That page is an app and apps need structure. The developer alone didn't decide the page needed all that. Chances are the business thought doing everything on one page made a strong business case. The UX team backed it up. The developer maybe agreed because they want a challenge. There's no way this trend abates until complicated UI's fall out of fashion.
- dashundchen 7y ago
  Exactly. There is a place for these tools, the key is having the knowledge to know when it makes sense to take the next step, and when it's just overkill. If you have a site delivering mostly static content, obviously use the bare minimum JS. However if you have a lot of reactive forms, interactivity etc, while it can be done with plain Javascript and HTML, I've seen way more buggy DOM manipulation/jQuery soup than not, even from experienced devs. Add in a large team working on separate features and code quality and UI consistency goes in the toilet. The frontend libraries at least can bring some structure and common patterns that can slow down this debt, at a library size similar to jQuery. It's also important to remember you don't have to go all in. If your site is mostly static with a few highly interactive components, you don't need a SPA Webpack setup with a 50MB node_modules directory. Tools like VueJS can be dropped incrementally on a server rendered application, and you can "step up" in terms of libraries, common components and build process only as needed.
draw_down 7y ago
I think the distinction between web app and we site is an important one, and using that distinction to decide what we ship to the frontend is appropriate.
revskill 7y ago
As i realized, the difference between a website and a web app is that, a web app is also a state machine. A website is stateless. So, if your state machine is complicated, the web app is also complicated. As it's so hard to modify even a small portion of a mess.
mmis1000 7y ago
At first glance, I thought it was yet another 'do not use JavaScript at all because it is too bloated while ignoring all real world use and claiming everything can be done by css' click bait article. But this article actually considering real world use, making the point valid instead some silly useless statement. And it also does provide some useful suggests and making its points strong. Probably the best article of this kind I saw recently
phponpcp 7y ago
Benchmarking on low-end devices to prove your point is situational at best in my opinion. For example if you work at a luxury ecommerce brand, you can assume that most users who actually are going to buy something are going to be using a flagship model device.
- Sohcahtoa82 7y ago
  > if you work at a luxury ecommerce brand That's a big IF right there. You're dismissing the author's point simply based on one hypothetical. In general, the author is right. JavaScript frameworks are being abused and developers don't care about the download size of their web pages, and it's terrible. If you're on a desktop with a wired internet connection, then yeah, it's not really going to matter. But if you're on a 3 year old low-end mobile device on a spotty 3G connection, it's significant.

132 points by wheresvic1 7y ago

Funny that the usability of this post goes to shit with ad and script blockers. Guess they care more about Luddites than privacy conscious users. Talk about poor judgement..

perttir 7y ago

Anybody else has issue with the side banners being on top of the text in the Firefox?

userbinator 7y ago

We need to know the purpose we’re trying to serve, and only then can we build something that admirably serves that purpose—even if it isn’t exciting to build. I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. There seems to be a very strong "if it's not new it's bad" sentiment[1], and as a result, the amount of churn is also extremely high. What's so "exciting" about doing more with less? As an aside, it is good to see that this article is completely readable without JS. [1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" --- despite it working in more browsers and being over an order of magnitude less code than their proposed "proper web development" solutions. They are correct, I am not a "real web developer", but when I write JS it's usually because I have a problem to solve and don't have any other choice.

nullandvoid 7y ago
Did you mean to write `What's so "exciting" about doing more with less?` I think the answer is obvious... More on topic I think more context is needed on your anecdote. Was you developing a small tool that's likely to balloon into a suite of tools etc? There may have been a variety of other factors to consider whether it may be worthwhile investing into a framework in the long term I'm not saying that your sentiment isn't at least a little true - but creating complex modern web applications is hard and frameworks CAN be the right decision depending on requirements.
hliyan 7y ago
RE: "not modern enough" I often hear the following versions: "that's not the current paradigm" or, "that's not recommended"
- TheRealPomax 7y ago
  Those should not be ignored, but they should be immediately followed up with by "why?" because understanding why the old paradigm didn't work, or why something isn't recommended, is important knowledge to have. If you tune out when someone tells you no, without asking why, you haven't started learning yet. There might be great reasons for why the current paradigm is actually preferred, or why that code you wrote is actually really bad because a single edge case that just happens to be severe enough. Until you ask why, you won't know, and your decisions will not be informed decisions.
  - hliyan 7y ago
    The sad part is, those are the answers to my question "why"...
- JustSomeNobody 7y ago
  > "that's not the current paradigm" or, "that's not recommended" When I see these words, I think these are followers. They don't truly understand why they are doing what they're doing, but "everyone else" is doing it, so it must be good.
olavgg 7y ago
I am also a classic web developer, still using vanilla javascript and trying to do as much as possible with just html and css. I feel I can solve any problem fast, quick and with minimal amount of code and bugs. For the recent years I have hired a few javascript developers and a common pattern I see is that the reason why they want to use overcomplicated toolset, is because this helps improving their CV so they are easier to sell. CV building is a thing, and developers also want to stay relevant in the future. For example I went through software developer job listings in my area. Of 100 listings, 40 of them are React specific, 2-3 Angular while maybe 5 mention any kind of frontend development like html/css/jquery. The rest is classical back end positions. There is a HUGE demand for frontend expertise these days. If you as a consultant want to sell yourself as a kickass rockstar frontend developer, you want as much React experience as possible on your CV. Some will even turn you down because of the fear of damaging their CV by just doing vanilla javascript work.
- JohnFen 7y ago
  > still using vanilla javascript and trying to do as much as possible with just html and css. Thank you. As someone who only allows JS to run very, very sparingly (and even then only on sites that are, for one reason or another, actually indispensable to me), I appreciate this very much. If a site requires JS to work, and if that site is something that is optional for me, then I won't use that site.
- bernawil 7y ago
  Myself and most full stack devs in my circle using React used to do html/css/jquery before. Nobody misses the jquery days. As soon as you start fetching data from api and refreshing your UI you get into a mess. Let's not forget that most MVC frameworks from the era imply mixing server side rendering with some partial client-side rendering on UI updates. Re-rendering your html from templates client-side, re-binding your elements to its events... it's objectively worse both in runtime performance and development wise.
  - mosdl 7y ago
    React just does the rerendering and re-binding for you - and does it way less efficient than if you hand coded it. What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance
geowwy 7y ago
> I wonder if there is a common > mindset that the majority of > web developers have which > causes them to love > overcomplexity so much We don’t love complexity, we love ease. The complexity is a side affect of us trying to make our job easy by `npm install`ing various tools/libraries/frameworks :) Another problem is the web is inherently complicated, and people expect more and more from the web. We’re still working out how to best manage the complexity and increased demands.
- hobs 7y ago
  Taking on a huge amount of dependencies only (potentially) makes your life easier up front. You now get to experience all bugs and side effects for all projects you now took on "due to ease." You now effectively maintain all those projects, instead of your own. You cannot go to your customers and say "well this library isnt working so neither is our website, and we can upgrade without it."
  - jamescostian 7y ago
    You also cannot go to your customers and say "well instead of using a popular library, we used our own and it broke and so did your site" And more importantly, NIH leads to on-boarding issues. Many, many people are React/Angular/Vue developers, but how many are $INTERNAL_RECREATION_OF_REACT developers? By creating a new framework, you waste money (not just on reinventing the wheel and fixing bugs in your new wheel, but also on having every new-hire take even longer to get productive)
    - userbinator 7y ago
      Code that you've written also tends to be code you have an understanding of, and thus much easier to debug than a maze of third-party dependencies. The extreme aversion to "reinventing the wheel" leads to things like left-pad.
ConfusedDog 7y ago
It goes into why we need design systems, software architectures, libraries at all? Because of communication and managing complexity. You give 5 developers one single set of requirements, their approach to the problem likely to be drastically different. Could their solutions be effective? Very likely to be. But that's not large projects are about, they are about continuity of the projects without locking into developers. For developers want to solve a problem quickly, you are correct - and more power to you because no one else (mostly) can understand your code. Job security FTW there. I think most of companies starting to realizing they can't keep people like you very long. You are both capable and stubborn (most likely). That's why job market is shifting towards mediumly skilled team and process oriented developers. Hope that makes sense.
qudat 7y ago
> I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; This is, in turn, is a weird mindset. Are you suggesting that web developers are somehow unique in the software development space? Here's a hint: they aren't. The problems that web developers have to solve are relatively unique to the platform. When is 1MB of code a lot? This is not amount of code written, this is amount of code used. In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because it doesn't have to be downloaded over HTTP like javascript. That is a unique feature of web development. What do you think would happen if developers around the world started complaining about using `numpy`? It's the same thing with libraries like `react`: they have no credibility because `react` is useful. It has nothing to do with web developer mindset, everyone wants to bring in libraries that make their lives easier.
- gambler 7y ago
  >In python, it is not uncommon to import a library like `numpy` which will easily clock in 20+ MB for one library. Why don't people care about python dependency bloat? Because some random Joe Schmoe can't replace numpy with a few lines of vanilla Pyton. Because numpy has a governing organization and isn't just an arbitrary library some unknown developer dumped on NPM. Because numpy is over a decade old and isn't any in danger of being superseded on the basis of not being fashionable.
  - phponpcp 7y ago
    Literally none of those things apply to React though.
jakelazaroff 7y ago
> I wonder if there is a common mindset that the majority of web developers have which causes them to love overcomplexity so much; certainly it's there in other areas of programming, but it is not quite as prevalent. Is this really unique to (frontend) web developers? I've heard plenty of stories of people building tangled webs of microservices when a monolith would be fine, using Kubernetes to run their weblog, using Hadoop with small datasets, etc.
jsight 7y ago
> [1] I've received comments from "real web developers" that some of the JS I've written is "not modern enough" I've said this in code reviews a few times. In ever case, it was because someone was using some construct that would have been needed in older Javascript versions, but was no longer necessary in whatever deployment we were supporting as a minimum. Sometimes it was from taking old Javascript conventions into Typescript. In ever case, the original code was a workaround for old bugs. Can you cite an example?
Zelphyr 7y ago
I once worked with a guy who, after looking at a solution provided by our team that not only worked but was fast and efficient, said, “This can’t be any good. You don’t have enough code.” He was in a leadership position. This way of thinking isn’t restricted to our industry. I see it in other areas as well. People naturally equate complexity with quality and actually have a hard time appreciating the beauty of a well-designed, well-thought out, efficient system. Why that is is beyond me.
- JohnFen 7y ago
  > People naturally equate complexity with quality Which is weird because, generally speaking, higher code complexity is a signal of lower quality.

azangru 7y ago

> Most layout issues JavaScript packages attempt to solve, like box placement, alignment, and sizing, managing text overflow, and even entire layout systems, are solvable with CSS today. This paragraph has surprising links. "Managing text overflow" links to Shave, a library for truncating multiline text[0]. Last time I checked, CSS was capable of truncating single-line text, but could not truncate multiline text (the line-clamp rule is still not universally supported). The first link in that paragraph is to a flexbox polyfill, and obviously, there's a reason why people use polyfills. [0] - https://www.npmjs.com/package/shave https://www.npmjs.com/package/shave

comis 7y ago
Yea there's plenty of benefits using a truncation library (we're currently using react-lines-ellipsis) over just css truncation. More control over how the truncation happens, callback so you can do more stuff on the condition that truncation has occurred, multi-line truncation as you mentioned, etc etc. I get the feeling that most of the time when people are complaining about unnecessary libraries they simply haven't personally run into the problem that the library solves yet.
- draw_down 7y ago
  > I get the feeling that most of the time when people are complaining about unnecessary libraries they simply haven't personally run into the problem that the library solves yet. Ding ding ding. "CSS does that!" is such an easy meme to replicate. Let's all try to consider that web developers are not just insane freaks who love to put JavaScript where it doesn't belong, and instead just regular people trying to solve problems like anyone else.

ChicagoBoy11 7y ago

TL;DR: Use the platform

rmrfrmrf 7y ago

Such are the contradictions of the web that we shun constant code churn while at the same time giving full-throated endorsements of Service Workers.

ascotan 7y ago

This all started with angular imho. There was a time when structure, layout and logic were more cleanly separated. Angular blew this up with <ng-xxx> tags (which was a step backwards towards PHP imho) and this has been driven forward by other frameworks since. It surprising to me how so many people can talk about shadow dom but can't name any of the HTML5 apis or even more than a few tags and what they do (much less anything about CSS3).

pault 7y ago
One of my interview questions is "how do you organize logic and state in a react app?" and about 19/20 candidates put their business logic in their view components. I believe the root of the problem is the ecosystem of terrible react tutorials that are targeted at beginners so can't introduce complex architecture. If you spend some time reading react blogs you'll see that almost all of them put their API requests and business logic inside component lifecycle methods. The flood of bootcamp grads has made hiring competent front end devs nearly impossible (not to slander bootcamp grads; I've met a few that are brilliant).
- ep103 7y ago
  >you'll see that almost all of them put their API requests and business logic inside component lifecycle methods Edit: (I rephrased this post) I understand that logic often makes sense to break out between presentational and container components, and I understand that sometimes api / service calls should be broken out into their own files, but everything I've read states that api logic should be called from ComponentDidMount.... you are saying that you shouldn't make api calls, from component lifecycle methods whatsoever? I'm not sure what the alternative is?
  - c0wboyc0ding 7y ago
    I would also love to see resources that detail how to separate business logic from view components. As a junior dev, I know it's the right thing to do but I'm not sure how. Is it as simple as passing props into a utils file? Any links would be greatly appreciated.

Tade0 7y ago

These are valid concerns and fortunately there are already examples of potential solutions being developed: https://svelte.technology https://svelte.technology Not saying this specific framework is going to be a success, but so far it both: - Is mostly "batteries included". - Indeed does create pretty small bundles.

moosingin3space 7y ago
The really nice thing about Svelte is that it treeshakes really well. I wrote a Firefox extension with Svelte (v1), and when Svelte v3 becomes stable I will be very excited to upgrade.

briantakita 7y ago

Here is a "Real World" comparison of Front End Frameworks, which includes payload size. https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075 https://medium.freecodecamp.org/a-realworld-comparison-of-fr...

gorpomon 7y ago

Complexity in JavaScript is not a code issue, it's a UI issue. Complicated UI's necessitate frameworks, not developers. When a website hits a certain level of UI interactions, I arbitrarily say around 10 per page, then HTML/CSS/"A sprinkle of JS" becomes unsustainable. Shipping 400kb of React isn't ideal, but to manage your complexity it is responsible. Let's say your page has the following: - Custom form validations - Custom styled <Select> tags - Forms that should show full lifecycle on submit without page refresh (form accepted, form error, sometimes API's return a 200 that is actually a failure :-/ ) - Inline editing of some user data. - Badges based on your users activity. - Notifications of new items. - Navigation styling that is JS powered in some way, or un-achievable or kind of a schlep with CSS (maybe the links are API powered :-/ ). - A table with sorting/filtering - Drag and drop reordering - Some type of chat window Now let's increase complexity and say all those things respond in some way to changes in the other things. I've built that page. That page is no longer a website. That page is an app and apps need structure. The developer alone didn't decide the page needed all that. Chances are the business thought doing everything on one page made a strong business case. The UX team backed it up. The developer maybe agreed because they want a challenge. There's no way this trend abates until complicated UI's fall out of fashion.

dashundchen 7y ago
Exactly. There is a place for these tools, the key is having the knowledge to know when it makes sense to take the next step, and when it's just overkill. If you have a site delivering mostly static content, obviously use the bare minimum JS. However if you have a lot of reactive forms, interactivity etc, while it can be done with plain Javascript and HTML, I've seen way more buggy DOM manipulation/jQuery soup than not, even from experienced devs. Add in a large team working on separate features and code quality and UI consistency goes in the toilet. The frontend libraries at least can bring some structure and common patterns that can slow down this debt, at a library size similar to jQuery. It's also important to remember you don't have to go all in. If your site is mostly static with a few highly interactive components, you don't need a SPA Webpack setup with a 50MB node_modules directory. Tools like VueJS can be dropped incrementally on a server rendered application, and you can "step up" in terms of libraries, common components and build process only as needed.

draw_down 7y ago

I think the distinction between web app and we site is an important one, and using that distinction to decide what we ship to the frontend is appropriate.

revskill 7y ago

As i realized, the difference between a website and a web app is that, a web app is also a state machine. A website is stateless. So, if your state machine is complicated, the web app is also complicated. As it's so hard to modify even a small portion of a mess.

mmis1000 7y ago

At first glance, I thought it was yet another 'do not use JavaScript at all because it is too bloated while ignoring all real world use and claiming everything can be done by css' click bait article. But this article actually considering real world use, making the point valid instead some silly useless statement. And it also does provide some useful suggests and making its points strong. Probably the best article of this kind I saw recently

phponpcp 7y ago

Benchmarking on low-end devices to prove your point is situational at best in my opinion. For example if you work at a luxury ecommerce brand, you can assume that most users who actually are going to buy something are going to be using a flagship model device.

Sohcahtoa82 7y ago
> if you work at a luxury ecommerce brand That's a big IF right there. You're dismissing the author's point simply based on one hypothetical. In general, the author is right. JavaScript frameworks are being abused and developers don't care about the download size of their web pages, and it's terrible. If you're on a desktop with a wired internet connection, then yeah, it's not really going to matter. But if you're on a 3 year old low-end mobile device on a spotty 3G connection, it's significant.