8 ms·

JavaScript Fatigue Fatigue

85 points by fagnerbrack 10y ago

Hates_ 10y ago
As someone who has only ever done web development how true is the statement "web development itself is inherently complicated" when compared to other fields of programming? After seeing the Jonathan Blow talk on software quality I really questioned how much I over-estimated the complexity of what I do every day.
- gadrev 10y ago
  Could you provide the full title or a link to that particular talk of Jonathan Blow?
  - sgift 10y ago
    https://www.youtube.com/watch?v=k56wra39lwA https://www.youtube.com/watch?v=k56wra39lwA Probably this one.
  - deleted 10y ago
    [deleted]
  - Hates_ 10y ago
    Sorry I forgot to paste it in my comment. It's the one that sgift has linked to.
- dmbass 10y ago
  I think a lot of the "complexity" of web development comes from the fact that most of us are just YOLOing to get something that "mostly works" out the door. For the most part, lives don't depend on our systems and the standard for performance is much lower than something like a video game or operating system thanks to the legacy of dialup and ads.
  - moron4hire 10y ago
    To be frank, you have no idea what "most" people are doing, you only know your small sphere of experience. For example, I've worked on several numerical simulation systems where the results were used for safety ratings of different industrial processes. This was all on the Web, and it honestly did fit for the Web. The market for all types software is huge and we only ever hear from a very small section of it. It's why I don't take the concept of programming-language-oriented "communities" too seriously. There is a huge body of dark-matter programmers out there--probably 90% in any particular language--who do not participate in the meetups and conferences and discussion forums. They just work and then go home at the end of the day to do something completely unrelated to programming.
- moron4hire 10y ago
  There isn't anything inherently hard about web development. There are some things that are a little harder than desktop. There are some things that are a little easier. Overall, I wouldn't say there is anything core to the fabric of either that makes one more or less difficult. What matters is the scale at which you plan to build your project. If the project is only ever meant for one person to use, then it's practically trivial. But being on the Web, you expose yourself to a much larger potential market, so I think it's easier for estimates to get blown out of the water. Desktop applications scale horizontally be default. Web applications scale vertically by default [0]. So if there is some "difficulty", then it is in that most Computer Science degreed people [1] first train in single-user, runs-on-a-desktop programming, so that is what they are initially familiar with. But it's a difference of starting point, not a difference in overall difficulty. There is a cultural issue that a lot of companies continue to treat the Web as a sub-standard platform, a lot of engineering teams continue to treat "The Front End" as an after thought, and they continue to hire only junior developers who have only ever written programs for themselves. This is not to knock Jr. Devs. We all start somewhere. But there are a lot of companies that expect way too much out of someone with 0 to 5 years of experience because they don't expect enough out of the Web as a platform. Other than that, concerns like accessibility, internationalization, cross-platform compatibility, they're all easier across the board on all platforms today than they've ever been on any of the platforms. I don't think there is any argument to be made there. [0] Hence the desire to make SPAs. A good SPA scales horizontally as well as any desktop application. [1] Myself included in this group.
  - mattmanser 10y ago
    I fundamentally can't agree with this because desktops apps are generally synchronous with one computer involved and web apps are asynchronous with at least 2 computers involved. I can't see how that's not a MASSIVE difference. That's adds a whole extra layer of complexity. There is virtually nothing in web apps that is easier, almost by very definition. What web apps made easy was deployment. Please name one other thing that's easier than in a desktop app. HTML wasn't even designed for apps. I just cannot comprehend how you can believe what you wrote. I really haven't written many desktop apps, but generally speaking when I did in say VB6 or Silverlight, they have been trivial to make compared to a web app of identical complexity.
- rubber_duck 10y ago
  Frontend development is trivial compared to stuff I've done in gamedev or in building distributed backends. There's stuff to learn but the problems are nowhere near as complicated and it's much simpler to debug (although cross browser complicates that somewhat, it's not even close to debugging distributed systems, or games on different hardware and drivers)
carsongross 10y ago
I very much like Quincy, but I can't agree with this article. “The Universe is under no obligation to make sense to you.” The universe may be under no obligation to make sense to us, but our tools are. The fact is that the vast majority of the complexity currently be introduced into web development is unnecessary for the vast majority of web applications. I built a tool to make it possible to implement most modern web UX patterns[1] with almost no javascript code whatsoever, and to be adopted as much or as little as necessary for a given project. It is possible to make modern web development simple (or at least as simple as it was in 2004[2]) if you make that a goal. Javascript fatigue is real. Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact with an open mind and not dismiss what a significant number of people are experiencing. [1] - http://intercoolerjs.org/examples/index.html http://intercoolerjs.org/examples/index.html [2] - http://intercoolerjs.org/2016/05/19/back-to-the-future.html http://intercoolerjs.org/2016/05/19/back-to-the-future.html
- DougBTX 10y ago
  > unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.
  - carsongross 10y ago
    That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.
    - DougBTX 10y ago
      I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.
brianvan5155 10y ago
So, in essence, just suck it up. The funny thing is that JavaScript development isn't a goal. It's never the goal. Complex toolsets sometimes assist in the achievement of goals... but you can't say "JavaScript overload is totally the right thing" when you aren't talking about the goals that need to be met. Simply having a philosophy that developers should learn new things all the time to stay current... that's not a good argument to support the current tooling. I'm glad there's a lot of people working on open source projects. I wish they'd publish more documentation about use cases and UNIFIED (not piecemeal) deployment configurations, though. After all, your toolset has valid and relevant use cases... right?!?!
xwowsersx 10y ago
tl;dr "JS is getting more complicated. Other things are really complicated too. Take it from me: this is a good thing."
nihonium 10y ago
I've really liked this post. I've totally agree with it. We should feel lucky to have such tools. I'm tired of hearing how awful is javascript ecosystem. How about comparing Front End vs Back End technologies? You have Javascript, and it's supersets for Front End, you have 100s of different languages for Back End development. One might say Back End sucks because it is very different across different languages and companies.
- BoorishBears 10y ago
  If you want to consider every facet of backend instead of the few main ones that show up when you want to solve a problem X in language Y then why claim frontend is just Js? By your reasoning for backend, frontend sucks because I could probably find Open GL wrappers for every language used on the backend and make a front end. Backend really is relatively simple because usually language X has a few really good libraries/frameworks you can pick up. Js is Node.Js. Python is Django or Flask depending on what you want to do, Elixir is usually Phoenix, etc.
sickbeard 10y ago
I think the author is mixing up complicated tasks and confusing tools
tashoecraft 10y ago
Why don't people understand that this is our way of unionizing. If you buy into the rapid change landscape, convincing your company to change every few years, then you've locked your job in.
aikah 10y ago
Javascript and its ecosystem are now more complicated than java's ... without type safety. The problem is the language wasn't designed with all this in mind. Not even talking about the bare bone nodejs std lib which makes any task a chore since most third party modules are not maintained past their first year of existence. What a mess.
- gerbilly 10y ago
  And npm could learn a _lot_ from maven.
  - jessaustin 10y ago
    npm could be faster. What else could npm learn from maven?
    - ryanbrunner 10y ago
      I'm not familiar with Maven, but comparing to other package managers (primarily bundler) - A sane approach to locking that's built in and impossible to forget. - Deterministic installs. - Basically enough stability that "delete your node_modules and npm install" is never a necessary solution to anything (I've had tons of instances where I've had to do this with npm).
- specialist 10y ago
  "The problem is the language [JavaScript] wasn't designed." FTFY
iandanforth 10y ago
"web development itself is inherently complicated." The best teachers I've ever had took things that many people label as "inherently complicated" and made them clear and simple. More often than not complexity arises from insufficient depth of understanding not from something intrinsic to the subject matter. "these new tools are very much a good thing. ... They will make you a happier ... developer." I object strongly to being told what will make me happy. The current tool set does not (other than React). I am glad they make someone happy.
ggregoire 10y ago
My thoughts about JavaScript and the libraries/frameworks/tools depreciation: https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33 https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19... TL;DR: We have mostly used the same tools for years. People feel that React or Webpack are the new hype tools for cool kids, but React is there since 2013 and Webpack since 2012. A lot of companies still use Angular 1 (released in 2010, almost 7 years ago).
- tonyedgecombe 10y ago
  "almost 7 years ago" I'm working on software that was started in 1999, this isn't unusual.
- gkya 10y ago
  We're in 2016.
- threatofrain 10y ago
  It's also worth noting that the iPhone was released around the same timeline that you're talking about, which led to some shifts in industry focus.
scotty79 10y ago
I don't mind JS and all of the ecosystem. I like the openness unseen anywhere else and dynamic growth and dropping stuff when better stuff gets created. But as I'm trying to control page transitions in SPA using react-rotuer v4 I have a feeling that I basically re-implement subset of a browser ... poorly.
romaniv 10y ago
>"web development itself is inherently complicated" The functionality of 99% of all websites I see these days can be replicated with simple DB calls, string concatenation and a handful of straightforward progressive enhancement libraries on the client side. Some developers simply choose complexity. The fundamentally complex aspects of web development aren't solved by the stuff people are fatigued by anyway.
- herge 10y ago
  > can be replicated with simple DB calls, string concatenation [...] You must not have seen the flame fest about PHP on the rest of HackerNews!
- ng12 10y ago
  I think there's a divide here -- "websites" you and I and the rest of HN visit, and "web applications" which are non-trivial interfaces to complex data. If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong.
  - sotojuan 10y ago
    > If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong. Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content. Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me. Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?
    - ng12 10y ago
      I think "javascript fatigue" is just a bad term. It's like sayings I have "hammer fatigue" because I've been whacking at screws all day.
moron4hire 10y ago
Here are some things to keep in mind: HTML5 is responsive and semantic by default. If you work with it rather than against it, you'll have incredibly rich documents that support users very well on a wide variety of different devices at no additional effort on your behalf. If you stick to only enough CSS3 as to actually style HTML5, not redefine it, then CSS is extremely easy to maintain, too. ES5 is implemented in all major browsers and its simple parts are very simple to learn. OOP and FP vie for the hearts and minds of developers with terrifying sparks and flames, but we've built entire empires off of procedural programming. Your choice of programming paradigm will likely have zero impact on your project's success. All of the difficulty we have is when we try to buck these strengths. You don't need a task runner if you aren't running tasks to translate Haml and SCSS and CoffeeScript to HTML5 and CSS3 and ES5. I'm not saying there isn't value in doing those things. I have my own convoluted process that I am constantly tweaking. But they are by far not the default. If you want to say that Web development is inherently complicated, you must talk about what is at its core. And the core of HTML5/CSS3/ES5 is not complicated. You can write it with a plain text editor. You can load it in any browser. You can serve it from any web server in their default settings. We fundamentally choose to complicate these things.
- combatentropy 10y ago
  Kind of reminds me of Jujutsu. I was about to recommend we all start a new framework, jujutsu.js, whose total file size is 0 bytes, but then I remembered that, of course, it has been done before: http://vanilla-js.com/ http://vanilla-js.com/
combatentropy 10y ago
From the article: > the reason why JavaScript development is so complicated: > web development itself is inherently complicated. It's really sad to me that the writer cites necessity as the reason for complexity. > We are trying to build applications that run right in a dozen browsers I remember cross-browser CSS and JavaScript from 2005 as infinitessimally shorter, and that was when we had to contend with IE 6. All of the other browsers back then behaved fairly uniformly. Now, IE 11 is almost indistinguishable from the rest. > look good on thousands of different devices There are really just two devices: big screen, little screen. To think you're targeting "thousands of different devices," you must be counting every make and model as a "different device" (and even then, it's more like dozens). Tell me, how does targeting the Samsung Galaxy S3 and the iPhone 6 require a bunch of JavaScript dependencies? > load fast enough for impatient commuters in the subway This is an art we have lost. The web used to ride on 28.8 kbps. > and are still accessible enough that blind people can use them. That also has been a solved problem for well over a decade. > The Cambrian explosion of tools you see around you > is what rapid progress looks like when it’s not > controlled by an Apple or a Microsoft. The web was never controlled by Apple. At one time it was dominated by Microsoft, but even then I could write cross-browser JavaScript without really thinking about it, with jQuery (2006). > At the same time, web developers are closing security > vulnerabilities all over the place. What other security hole is there for web devs to handle besides cross-site scripting, and how does any security hardening lead to magnitudinous JavaScript dependencies? > If this evolutionary process frustrates you [...] Is this evolution or entropy?
- carsongross 10y ago
  What other security hole is there for web devs to handle Ironically, as we introduce more expressive power in the browser (an untrusted execution environment) to support SPAs, we are actually introducing more security issues: http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht... These are the crazy years.
- ben_jones 10y ago
  > what other security vulnerabilities for Web devs to handle besides csrf Not defending the article but the more intertwined the client and server code becomes, as well as server side development in nodejs etc , the more security vulns javascript developers will be exposed to. In addition nodejs has become arguably THE introductory web development language and as such offloads many complex but necessary tasks to its third party libraries in order for beginners to develop efficiently. This means security features ranging from CSRF to ORMS to CORS etc are taken out of the domain of developers and into that of typically un vetted third party libraries, becoming a vulnerability in and of itself.
SadWebDeveloper 10y ago
The problem is not the tooling, the browsers or JS itself, the problem is that JS developers are trying to put themselves EVERYWHERE THEY CAN in attempt to pursue the now infamous "full-stack engineer" motto.
tangue 10y ago
The problem is not javascript or people complaining about javascript, the problem is fetichism of an inefficient toolchain. When I read that "“Over 400ms is being spent simply walking the Browserify tree.” on a site like Tumblr... [0]https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsgL0gP_S6SDv27yi1mCEY/edit https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsg...
rbanffy 10y ago
> We are trying to build applications that run right in a dozen browsers, look good on thousands of different devices, load fast enough for impatient commuters in the subway, and are still accessible enough that blind people can use them. Wow! That sounds cool! When do we start doing that? Now, seriously, the complexity of the problem is enough you don't need to pile up more complicated tools on top of them that become, too, problems to be solved. We have tools to manage micro-dependencies we create because we have the tools to manage them. Then we invented tools to bundle micro-dependencies because we didn't want the browser to request 300 separate functions in 300 separate http requests and soon we'll unbundle them and let the browser request them because the individual request itself becomes cheap enough... I get we are talking about "web applications" that have routes, don't re-render pages and don't hit the server for full pages. If this reminds you of what we were doing with Visual Basic in the early 90's minus using HTTP to get JSON data from a server, it's because this is a solved problem. What it feels like is that we are trying to re-do it with the wrong abstractions.
clifanatic 10y ago
The first comic I think is supposed to make me feel sorry for the poor saps who have to test against a dozen different Android phones but I couldn't help but think what a luxury it would be to work for an employer who actually provided physical hardware to test against. I've been developing software for 25 years and have yet to encounter this.
Grue3 10y ago
>We are trying to build applications that run right in a dozen browsers, look good on thousands of different devices, load fast enough for impatient commuters in the subway, and are still accessible enough that blind people can use them. Then why do they not do that? Every "modern" web application loads slow as hell, works decently only in Google Chrome, ruins the functionality of the back button, and eats 100% of your CPU. I've seen blogs, blogs, that do this sort of stuff.
- dwaltrip 10y ago
  Every web application does all of those terrible things? Your hyperbole is a bit extreme. Even if it is a very high percentage, say 90%, we are still left with millions of high quality applications. You may have to do some work to find them, but it's no apocalypse. Whenever participation in some dynamic becomes immensely widespread (in this case, building web apps) the average quality of each instance always drops. This is a well understood phenomenon that is not unique to web applications.
carapace 10y ago
No, this is stupid. Show me the "business value" proposition for NOT using Elm (http://elm-lang.org/ http://elm-lang.org/) over the expletive-deleted soup of modern JS web "app" development or shut up. We have become complexity junkies and this article is a junkie rationalizing the habit.
seangrogg 10y ago
While I agree with parts of this article, the fact of the matter is that in the majority of cases "JavaScript fatigue" is self-inflicted. Chances are most of your users don't care about you using ES6 or TypeScript. They're not checking to see if your code is minified, uglified, bundled, code-split, or whatever. What matters to most users is their experience, not yours. So if you're using Webpack and Babel and TypeScript and Gulp... you opted in to that complexity. If you feel like you need 18 tools to develop your apps that's on you, not JavaScript.
z3t4 10y ago
The user dont care what tools u use. Dont forget who you are designing for!
z3t4 10y ago
Meanwhile we argue that switch statements are too complexed and should be avoided.

85 points by fagnerbrack 10y ago

As someone who has only ever done web development how true is the statement "web development itself is inherently complicated" when compared to other fields of programming? After seeing the Jonathan Blow talk on software quality I really questioned how much I over-estimated the complexity of what I do every day.

gadrev 10y ago
Could you provide the full title or a link to that particular talk of Jonathan Blow?
- sgift 10y ago
  https://www.youtube.com/watch?v=k56wra39lwA https://www.youtube.com/watch?v=k56wra39lwA Probably this one.
- deleted 10y ago
  [deleted]
- Hates_ 10y ago
  Sorry I forgot to paste it in my comment. It's the one that sgift has linked to.
dmbass 10y ago
I think a lot of the "complexity" of web development comes from the fact that most of us are just YOLOing to get something that "mostly works" out the door. For the most part, lives don't depend on our systems and the standard for performance is much lower than something like a video game or operating system thanks to the legacy of dialup and ads.
- moron4hire 10y ago
  To be frank, you have no idea what "most" people are doing, you only know your small sphere of experience. For example, I've worked on several numerical simulation systems where the results were used for safety ratings of different industrial processes. This was all on the Web, and it honestly did fit for the Web. The market for all types software is huge and we only ever hear from a very small section of it. It's why I don't take the concept of programming-language-oriented "communities" too seriously. There is a huge body of dark-matter programmers out there--probably 90% in any particular language--who do not participate in the meetups and conferences and discussion forums. They just work and then go home at the end of the day to do something completely unrelated to programming.
moron4hire 10y ago
There isn't anything inherently hard about web development. There are some things that are a little harder than desktop. There are some things that are a little easier. Overall, I wouldn't say there is anything core to the fabric of either that makes one more or less difficult. What matters is the scale at which you plan to build your project. If the project is only ever meant for one person to use, then it's practically trivial. But being on the Web, you expose yourself to a much larger potential market, so I think it's easier for estimates to get blown out of the water. Desktop applications scale horizontally be default. Web applications scale vertically by default [0]. So if there is some "difficulty", then it is in that most Computer Science degreed people [1] first train in single-user, runs-on-a-desktop programming, so that is what they are initially familiar with. But it's a difference of starting point, not a difference in overall difficulty. There is a cultural issue that a lot of companies continue to treat the Web as a sub-standard platform, a lot of engineering teams continue to treat "The Front End" as an after thought, and they continue to hire only junior developers who have only ever written programs for themselves. This is not to knock Jr. Devs. We all start somewhere. But there are a lot of companies that expect way too much out of someone with 0 to 5 years of experience because they don't expect enough out of the Web as a platform. Other than that, concerns like accessibility, internationalization, cross-platform compatibility, they're all easier across the board on all platforms today than they've ever been on any of the platforms. I don't think there is any argument to be made there. [0] Hence the desire to make SPAs. A good SPA scales horizontally as well as any desktop application. [1] Myself included in this group.
- mattmanser 10y ago
  I fundamentally can't agree with this because desktops apps are generally synchronous with one computer involved and web apps are asynchronous with at least 2 computers involved. I can't see how that's not a MASSIVE difference. That's adds a whole extra layer of complexity. There is virtually nothing in web apps that is easier, almost by very definition. What web apps made easy was deployment. Please name one other thing that's easier than in a desktop app. HTML wasn't even designed for apps. I just cannot comprehend how you can believe what you wrote. I really haven't written many desktop apps, but generally speaking when I did in say VB6 or Silverlight, they have been trivial to make compared to a web app of identical complexity.
rubber_duck 10y ago
Frontend development is trivial compared to stuff I've done in gamedev or in building distributed backends. There's stuff to learn but the problems are nowhere near as complicated and it's much simpler to debug (although cross browser complicates that somewhat, it's not even close to debugging distributed systems, or games on different hardware and drivers)

carsongross 10y ago

I very much like Quincy, but I can't agree with this article. “The Universe is under no obligation to make sense to you.” The universe may be under no obligation to make sense to us, but our tools are. The fact is that the vast majority of the complexity currently be introduced into web development is unnecessary for the vast majority of web applications. I built a tool to make it possible to implement most modern web UX patterns[1] with almost no javascript code whatsoever, and to be adopted as much or as little as necessary for a given project. It is possible to make modern web development simple (or at least as simple as it was in 2004[2]) if you make that a goal. Javascript fatigue is real. Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact with an open mind and not dismiss what a significant number of people are experiencing. [1] - http://intercoolerjs.org/examples/index.html http://intercoolerjs.org/examples/index.html [2] - http://intercoolerjs.org/2016/05/19/back-to-the-future.html http://intercoolerjs.org/2016/05/19/back-to-the-future.html

DougBTX 10y ago
> unnecessary for the vast majority of web applications There's a sliding scale of what counts as "necessary" to different developers. For example, the first entry in the intercooler.js examples is a "Click To Edit UI" that doesn't escape HTML in user input. For many websites, that probably doesn't matter all that much, but for developers that care about script injection, they might go for a different solution that makes that sort of problem harder to introduce. That exposes the underlying complexity though, since using string concatenation to generate HTML is no longer a safe option.
- carsongross 10y ago
  That's because I'm using a library, mockjax, to mock out AJAX requests for the examples, to keep them as simple as possible. Any sane server side web framework is going to escape HTML for you.
  - DougBTX 10y ago
    I agree that it is good to keep the examples simple, I liked how easy it was to toggle between the live example and the source code. If the rendering was still done on the client using `userDisplayTemplate`, I'd guess that the response to the save web service call would be a JSON object. The server would then need to know that the user object it returns should have HTML strings as its properties, rather than just a plain text. Possible, but the complexity doesn't go away.

brianvan5155 10y ago

So, in essence, just suck it up. The funny thing is that JavaScript development isn't a goal. It's never the goal. Complex toolsets sometimes assist in the achievement of goals... but you can't say "JavaScript overload is totally the right thing" when you aren't talking about the goals that need to be met. Simply having a philosophy that developers should learn new things all the time to stay current... that's not a good argument to support the current tooling. I'm glad there's a lot of people working on open source projects. I wish they'd publish more documentation about use cases and UNIFIED (not piecemeal) deployment configurations, though. After all, your toolset has valid and relevant use cases... right?!?!

xwowsersx 10y ago

tl;dr "JS is getting more complicated. Other things are really complicated too. Take it from me: this is a good thing."

nihonium 10y ago

I've really liked this post. I've totally agree with it. We should feel lucky to have such tools. I'm tired of hearing how awful is javascript ecosystem. How about comparing Front End vs Back End technologies? You have Javascript, and it's supersets for Front End, you have 100s of different languages for Back End development. One might say Back End sucks because it is very different across different languages and companies.

BoorishBears 10y ago
If you want to consider every facet of backend instead of the few main ones that show up when you want to solve a problem X in language Y then why claim frontend is just Js? By your reasoning for backend, frontend sucks because I could probably find Open GL wrappers for every language used on the backend and make a front end. Backend really is relatively simple because usually language X has a few really good libraries/frameworks you can pick up. Js is Node.Js. Python is Django or Flask depending on what you want to do, Elixir is usually Phoenix, etc.

sickbeard 10y ago

I think the author is mixing up complicated tasks and confusing tools

tashoecraft 10y ago

Why don't people understand that this is our way of unionizing. If you buy into the rapid change landscape, convincing your company to change every few years, then you've locked your job in.

aikah 10y ago

Javascript and its ecosystem are now more complicated than java's ... without type safety. The problem is the language wasn't designed with all this in mind. Not even talking about the bare bone nodejs std lib which makes any task a chore since most third party modules are not maintained past their first year of existence. What a mess.

gerbilly 10y ago
And npm could learn a _lot_ from maven.
- jessaustin 10y ago
  npm could be faster. What else could npm learn from maven?
  - ryanbrunner 10y ago
    I'm not familiar with Maven, but comparing to other package managers (primarily bundler) - A sane approach to locking that's built in and impossible to forget. - Deterministic installs. - Basically enough stability that "delete your node_modules and npm install" is never a necessary solution to anything (I've had tons of instances where I've had to do this with npm).
specialist 10y ago
"The problem is the language [JavaScript] wasn't designed." FTFY

iandanforth 10y ago

"web development itself is inherently complicated." The best teachers I've ever had took things that many people label as "inherently complicated" and made them clear and simple. More often than not complexity arises from insufficient depth of understanding not from something intrinsic to the subject matter. "these new tools are very much a good thing. ... They will make you a happier ... developer." I object strongly to being told what will make me happy. The current tool set does not (other than React). I am glad they make someone happy.

ggregoire 10y ago

My thoughts about JavaScript and the libraries/frameworks/tools depreciation: https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19851a33 https://gist.github.com/ggregoire/f41ae88bb8e192ad70be690f19... TL;DR: We have mostly used the same tools for years. People feel that React or Webpack are the new hype tools for cool kids, but React is there since 2013 and Webpack since 2012. A lot of companies still use Angular 1 (released in 2010, almost 7 years ago).

tonyedgecombe 10y ago
"almost 7 years ago" I'm working on software that was started in 1999, this isn't unusual.
gkya 10y ago
We're in 2016.
threatofrain 10y ago
It's also worth noting that the iPhone was released around the same timeline that you're talking about, which led to some shifts in industry focus.

scotty79 10y ago

I don't mind JS and all of the ecosystem. I like the openness unseen anywhere else and dynamic growth and dropping stuff when better stuff gets created. But as I'm trying to control page transitions in SPA using react-rotuer v4 I have a feeling that I basically re-implement subset of a browser ... poorly.

romaniv 10y ago

>"web development itself is inherently complicated" The functionality of 99% of all websites I see these days can be replicated with simple DB calls, string concatenation and a handful of straightforward progressive enhancement libraries on the client side. Some developers simply choose complexity. The fundamentally complex aspects of web development aren't solved by the stuff people are fatigued by anyway.

herge 10y ago
> can be replicated with simple DB calls, string concatenation [...] You must not have seen the flame fest about PHP on the rest of HackerNews!
ng12 10y ago
I think there's a divide here -- "websites" you and I and the rest of HN visit, and "web applications" which are non-trivial interfaces to complex data. If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong.
- sotojuan 10y ago
  > If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong. Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content. Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me. Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?
  - ng12 10y ago
    I think "javascript fatigue" is just a bad term. It's like sayings I have "hammer fatigue" because I've been whacking at screws all day.

moron4hire 10y ago

Here are some things to keep in mind: HTML5 is responsive and semantic by default. If you work with it rather than against it, you'll have incredibly rich documents that support users very well on a wide variety of different devices at no additional effort on your behalf. If you stick to only enough CSS3 as to actually style HTML5, not redefine it, then CSS is extremely easy to maintain, too. ES5 is implemented in all major browsers and its simple parts are very simple to learn. OOP and FP vie for the hearts and minds of developers with terrifying sparks and flames, but we've built entire empires off of procedural programming. Your choice of programming paradigm will likely have zero impact on your project's success. All of the difficulty we have is when we try to buck these strengths. You don't need a task runner if you aren't running tasks to translate Haml and SCSS and CoffeeScript to HTML5 and CSS3 and ES5. I'm not saying there isn't value in doing those things. I have my own convoluted process that I am constantly tweaking. But they are by far not the default. If you want to say that Web development is inherently complicated, you must talk about what is at its core. And the core of HTML5/CSS3/ES5 is not complicated. You can write it with a plain text editor. You can load it in any browser. You can serve it from any web server in their default settings. We fundamentally choose to complicate these things.

combatentropy 10y ago
Kind of reminds me of Jujutsu. I was about to recommend we all start a new framework, jujutsu.js, whose total file size is 0 bytes, but then I remembered that, of course, it has been done before: http://vanilla-js.com/ http://vanilla-js.com/

combatentropy 10y ago

From the article: > the reason why JavaScript development is so complicated: > web development itself is inherently complicated. It's really sad to me that the writer cites necessity as the reason for complexity. > We are trying to build applications that run right in a dozen browsers I remember cross-browser CSS and JavaScript from 2005 as infinitessimally shorter, and that was when we had to contend with IE 6. All of the other browsers back then behaved fairly uniformly. Now, IE 11 is almost indistinguishable from the rest. > look good on thousands of different devices There are really just two devices: big screen, little screen. To think you're targeting "thousands of different devices," you must be counting every make and model as a "different device" (and even then, it's more like dozens). Tell me, how does targeting the Samsung Galaxy S3 and the iPhone 6 require a bunch of JavaScript dependencies? > load fast enough for impatient commuters in the subway This is an art we have lost. The web used to ride on 28.8 kbps. > and are still accessible enough that blind people can use them. That also has been a solved problem for well over a decade. > The Cambrian explosion of tools you see around you > is what rapid progress looks like when it’s not > controlled by an Apple or a Microsoft. The web was never controlled by Apple. At one time it was dominated by Microsoft, but even then I could write cross-browser JavaScript without really thinking about it, with jQuery (2006). > At the same time, web developers are closing security > vulnerabilities all over the place. What other security hole is there for web devs to handle besides cross-site scripting, and how does any security hardening lead to magnitudinous JavaScript dependencies? > If this evolutionary process frustrates you [...] Is this evolution or entropy?

carsongross 10y ago
What other security hole is there for web devs to handle Ironically, as we introduce more expressive power in the browser (an untrusted execution environment) to support SPAs, we are actually introducing more security issues: http://intercoolerjs.org/2016/02/17/api-churn-vs-security.html http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht... These are the crazy years.
ben_jones 10y ago
> what other security vulnerabilities for Web devs to handle besides csrf Not defending the article but the more intertwined the client and server code becomes, as well as server side development in nodejs etc , the more security vulns javascript developers will be exposed to. In addition nodejs has become arguably THE introductory web development language and as such offloads many complex but necessary tasks to its third party libraries in order for beginners to develop efficiently. This means security features ranging from CSRF to ORMS to CORS etc are taken out of the domain of developers and into that of typically un vetted third party libraries, becoming a vulnerability in and of itself.

SadWebDeveloper 10y ago

The problem is not the tooling, the browsers or JS itself, the problem is that JS developers are trying to put themselves EVERYWHERE THEY CAN in attempt to pursue the now infamous "full-stack engineer" motto.

tangue 10y ago

The problem is not javascript or people complaining about javascript, the problem is fetichism of an inefficient toolchain. When I read that "“Over 400ms is being spent simply walking the Browserify tree.” on a site like Tumblr... [0]https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsgL0gP_S6SDv27yi1mCEY/edit https://docs.google.com/document/d/1E2w0UQ4RhId5cMYsDcdcNwsg...

rbanffy 10y ago

> We are trying to build applications that run right in a dozen browsers, look good on thousands of different devices, load fast enough for impatient commuters in the subway, and are still accessible enough that blind people can use them. Wow! That sounds cool! When do we start doing that? Now, seriously, the complexity of the problem is enough you don't need to pile up more complicated tools on top of them that become, too, problems to be solved. We have tools to manage micro-dependencies we create because we have the tools to manage them. Then we invented tools to bundle micro-dependencies because we didn't want the browser to request 300 separate functions in 300 separate http requests and soon we'll unbundle them and let the browser request them because the individual request itself becomes cheap enough... I get we are talking about "web applications" that have routes, don't re-render pages and don't hit the server for full pages. If this reminds you of what we were doing with Visual Basic in the early 90's minus using HTTP to get JSON data from a server, it's because this is a solved problem. What it feels like is that we are trying to re-do it with the wrong abstractions.

clifanatic 10y ago

The first comic I think is supposed to make me feel sorry for the poor saps who have to test against a dozen different Android phones but I couldn't help but think what a luxury it would be to work for an employer who actually provided physical hardware to test against. I've been developing software for 25 years and have yet to encounter this.

Grue3 10y ago

>We are trying to build applications that run right in a dozen browsers, look good on thousands of different devices, load fast enough for impatient commuters in the subway, and are still accessible enough that blind people can use them. Then why do they not do that? Every "modern" web application loads slow as hell, works decently only in Google Chrome, ruins the functionality of the back button, and eats 100% of your CPU. I've seen blogs, blogs, that do this sort of stuff.

dwaltrip 10y ago
Every web application does all of those terrible things? Your hyperbole is a bit extreme. Even if it is a very high percentage, say 90%, we are still left with millions of high quality applications. You may have to do some work to find them, but it's no apocalypse. Whenever participation in some dynamic becomes immensely widespread (in this case, building web apps) the average quality of each instance always drops. This is a well understood phenomenon that is not unique to web applications.

carapace 10y ago

No, this is stupid. Show me the "business value" proposition for NOT using Elm (http://elm-lang.org/ http://elm-lang.org/) over the expletive-deleted soup of modern JS web "app" development or shut up. We have become complexity junkies and this article is a junkie rationalizing the habit.

seangrogg 10y ago

While I agree with parts of this article, the fact of the matter is that in the majority of cases "JavaScript fatigue" is self-inflicted. Chances are most of your users don't care about you using ES6 or TypeScript. They're not checking to see if your code is minified, uglified, bundled, code-split, or whatever. What matters to most users is their experience, not yours. So if you're using Webpack and Babel and TypeScript and Gulp... you opted in to that complexity. If you feel like you need 18 tools to develop your apps that's on you, not JavaScript.

z3t4 10y ago

The user dont care what tools u use. Dont forget who you are designing for!

z3t4 10y ago

Meanwhile we argue that switch statements are too complexed and should be avoided.