5 ms·

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 U

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.
- olavgg 7y ago
  Me and an earlier colleague had the same fight, that he could rewrite my 10000 lines of vanilla JavaScript code for interactive UI with less code and less bugs if it was written in React. The React infrastructure ended up with more than 10000 lines of code, more bugs, and he spent at least twice the amount of time to deliver. The main reason he failed, was that he over-engineered his solution.
  - mmis1000 7y ago
    As long as you are not experiential as the developer of react, it is likely your 10000 lines of code would create way more bugs than the 10000 lines of code react team wrote, it just not explode yet, while your colleague only need to debug the extra 1000 lines of code he wrote.
Touche 7y ago
This is the common excuse given for bloated JavaScript usage but it ignores the realities of what is happening on the web. People are building simple blogs with JavaScript frameworks. People are building their 2 form field login page with JavaScript frameworks. It's just inaccurate to take the most complex thing you can create and act as though that's the norm; it's not. Websites still exist, and people are using the most complex tech to create those too.
- steve76 7y ago
  What I would like is a way to build static websites programmatically. Javascript builds the page, and I throw in a npm which does all this for me.
- PretzelFisch 7y ago
  This is just the problem our industry has. Hammer is popular, everyone learns hammer. Now all problems are solved with a hammer.
  - jaredklewis 7y ago
    I think there is always going to be a certain tension between two conflicting desires: A) The desire to use the right tool for the right job B) The desire to have fewer, more versatile tools It's understandable that people don't want to learn dozens of different languages, frameworks, and libraries. There is a real cost to gaining knowledge and experience with all those tools, and a real benefit to knowing a single tool really well. On the other hand I often find more tailored tools can be much more powerful for their suited tasks. But then again it's also true that the scope of projects is always shifting, so sometimes you can outgrow the specific use case of a tool. Anyway, I would say it isn't clear (to me at least) that our industry has a "problem."
- gorpomon 7y ago
  I ask in the spirit of friendliness, is this really an issue, or is this something that feels like one? I'm hard pressed to imagine WordPress having login forms done in a JS Framework, and that's a big chunk of the web. If they are doing that, then you're right, it's totally unnecessary. But I'm guessing the folks at Automattic are optimizing this stuff for their clients (but I concede that I could be wrong here). As far as blogs in these tech stacks, if they're developer blogs then that makes total sense. A dev blogging about React would probably choose React for their blog since that's a live production laboratory for any React code. I had a website in Ruby on Rails for years because I was a Rails dev and it was easy to try stuff out. Are there any concrete stats on actual mismatch? Do we know how many recipe blogs are using Angular or React? My guess is their bloat is from tons of scripts and not from a developer using a tool that is wrong for the job. That bloat is at its heart a UI/business problem. Analytics, pop-ups, sharing links, referrals and that entire class of web objects IMO opinion are UI/business concerns, and they'll continue as long as folks find those things valuable.

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.

olavgg 7y ago
Me and an earlier colleague had the same fight, that he could rewrite my 10000 lines of vanilla JavaScript code for interactive UI with less code and less bugs if it was written in React. The React infrastructure ended up with more than 10000 lines of code, more bugs, and he spent at least twice the amount of time to deliver. The main reason he failed, was that he over-engineered his solution.
- mmis1000 7y ago
  As long as you are not experiential as the developer of react, it is likely your 10000 lines of code would create way more bugs than the 10000 lines of code react team wrote, it just not explode yet, while your colleague only need to debug the extra 1000 lines of code he wrote.

Touche 7y ago

This is the common excuse given for bloated JavaScript usage but it ignores the realities of what is happening on the web. People are building simple blogs with JavaScript frameworks. People are building their 2 form field login page with JavaScript frameworks. It's just inaccurate to take the most complex thing you can create and act as though that's the norm; it's not. Websites still exist, and people are using the most complex tech to create those too.

steve76 7y ago
What I would like is a way to build static websites programmatically. Javascript builds the page, and I throw in a npm which does all this for me.
PretzelFisch 7y ago
This is just the problem our industry has. Hammer is popular, everyone learns hammer. Now all problems are solved with a hammer.
- jaredklewis 7y ago
  I think there is always going to be a certain tension between two conflicting desires: A) The desire to use the right tool for the right job B) The desire to have fewer, more versatile tools It's understandable that people don't want to learn dozens of different languages, frameworks, and libraries. There is a real cost to gaining knowledge and experience with all those tools, and a real benefit to knowing a single tool really well. On the other hand I often find more tailored tools can be much more powerful for their suited tasks. But then again it's also true that the scope of projects is always shifting, so sometimes you can outgrow the specific use case of a tool. Anyway, I would say it isn't clear (to me at least) that our industry has a "problem."
gorpomon 7y ago
I ask in the spirit of friendliness, is this really an issue, or is this something that feels like one? I'm hard pressed to imagine WordPress having login forms done in a JS Framework, and that's a big chunk of the web. If they are doing that, then you're right, it's totally unnecessary. But I'm guessing the folks at Automattic are optimizing this stuff for their clients (but I concede that I could be wrong here). As far as blogs in these tech stacks, if they're developer blogs then that makes total sense. A dev blogging about React would probably choose React for their blog since that's a live production laboratory for any React code. I had a website in Ruby on Rails for years because I was a Rails dev and it was easy to try stuff out. Are there any concrete stats on actual mismatch? Do we know how many recipe blogs are using Angular or React? My guess is their bloat is from tons of scripts and not from a developer using a tool that is wrong for the job. That bloat is at its heart a UI/business problem. Analytics, pop-ups, sharing links, referrals and that entire class of web objects IMO opinion are UI/business concerns, and they'll continue as long as folks find those things valuable.