JavaScript Fatigue Fatigue | Hacker News Reader

JavaScript Fatigue Fatigue

medium.freecodecamp.com

85 pointsfagnerbrack78 comments

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

[2] - http://intercoolerjs.org/2016/05/19/back-to-the-future.html

> 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.

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.

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.

I'm not sure what you are getting at. One of the core ideas with intercooler is to use HTML, not JSON, as your data transport, to get back to the original model of the web as described by Roy Fielding (REST/HATEOAS), rather than move more towards a JSON/RPC model.

There are some good practical and theoretical reasons for doing this:

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

Ah, thanks, that makes much more sense. I hadn't noticed that was mock server-side code, I thought it was advocating "vanilla JS" as a client side framework, using string-bashing as a template language.

A lot of open source JavaScript libraries are MIT licensed, including intercoolerjs, and the concept of "under no obligation" is directly encoded in that license:

"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

[0] - https://opensource.org/licenses/MIT

I think the option that was insinuated here was to take one's time and talent and apply it to working under a different language's ecosystem. One that has presumably better tooling.

There's complexity of tooling, and complexity of code. I'll take simple code over simple tools any day. The package.json in my SPA is bloated but the majority of the code is pretty simple and the bits that aren't are well-encapsulated.

Back when I was using just jQuery and maybe Backbone or KO the tooling was simple but an incredible amount of rigor was required to keep the code maintainable. A big part of my job right now is providing a dev environment where people don't get fatigued -- most of the tech decisions I make are geared towards ease-of-use by backend devs. Sure, the toolchain is relatively complex, but it's a fundamental part of why I'm able to do that.

If complexity of tools guaranteed simplicity of code, great. But if no one bothers to really understand the tools (since they change so often anyway), you end up with complex everything.

I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think?

Not saying you're wrong. I'm not even saying what you're doing doesn't matter. In theory it should work as you described. But I'm saying in reality you may be too into what you're doing that you don't realize what others think.

I've had a few people who were in your position in my past job, and they seemed to believe what they are doing is indeed better for the team (and so did the managers, that's why they were working on it in the first place!), but from an actual "user" point of view, they didn't help at all but made me a very dissatisfied developer. The thing is most people don't officially complain about it because they don't want to be seen as a loser who "can't move fast enough".

But here's what REALLY happens while you're thinking everyone's benefitting from your work:

As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever. That's one of the biggest criticisms on rails. But that's a different story since rails actually provides huge benefit as a result (and people know that it isn't going anywhere so it's worth learning)

When we come to JS land, there's no clear "10X" benefit to adopting these technologies. Sure there are incremental benefits but they don't justify learning every new packaging tool / framework every couple of months. I shit you not, a lot of companies have gone from grunt to gulp to webpack (and who knows what's next) just because they're the cool new tool that's "better" than the other. Some may say I'm lying just to exaggerate, but I am not. They do this because they want to "attract new developers who are looking to work with latest technology".

But in my opinion that's the stupidest thing a product building company should do. You're better off attracting great developers by building a product that's so compelling that developers want to contribute no matter what the stack is. I'm sure Snapchat had no problem attracting top talent in LA when all they had was a shitty mobile app that they didn't even bother making pretty.

Lastly in most cases, only a few people on the team are responsible for taking on these framework migrations. Which means the rest of the developers just become "users" and are left feeling like some passive idiots who just follow the "early adopters". As a result the developers fall into two categories: 1. People who don't want to feel left out and pretend they like the tool and keep following (and this feeling of "following" feels really shitty if you are not a "follower" kind of person); 2. People who complain how these "upgrades" are totally unnecessary and as a result treated like "old school" by the people of group 1.

Step back and think about how much efficient web development has become for 90% of developers (Not for you, who already are on board and an expert in adopting one new edge tool every month). To be clear, I know how to use all these tools (grunt, gulp, webpack, etc.) but whenever I need to build a quick prototype I just use plain old html/css/jquery. You could say you could use things like Yeoman to set up things quickly, but that's not the point.

> I think there's a conflict of interest when a guy whose job is to adopt these frameworks says they're good, don't you think?

Not at all. The reason I accepted that gig was because the team previously had a complex SPA written with what the above poster would consider simple tools -- and they were extremely unhappy with it. It took too long to add features, to modify things, to grok the control flow, to hunt down bugs. And that's not to say the app was poor quality: for the tools used everything was fairly idiomatic and organized. They hired me because they thought things could be better, and I thought they could too.

> As a developer, less code WITHOUT knowing what's going on underneath is the worst feeling ever.

Do you write all your code in assembly? The whole reason we use tools is because we don't want to think about what's going on underneath. React/Redux are simple by design and both incredibly easy to reason about. Webpack is a little more complicated by nature (most build tools are) but even then the core API is very simple -- just define a chain of compilation tools to process files of a given type.

> in adopting one new edge tool every month

I'm not sure where you get this impression from. The last major change to my standard stack was Flux -> Redux, and that was almost a year ago (and a relatively simple migration). Apparently you enjoy being crumdugeonly, but please have some faith that some of the web development community know what they're doing and care very deeply about the same things you do -- namely, crafting maintainable software.

> I need to build a quick prototype I just use plain old html/css/jquery

Sure! Pick the right tools for the job. Those are the right tools for a demo, the wrong tools for a long-lived SPA which needs to be maintained/extended by a team of engineers.

It's actually a lot easier to maintain and extend something over a long lifespan if it doesn't have tons of dependencies from many different sources evolving in different directions at different velocities.

In a long-lived application, early team members will need to learn the new tech and later team members will need training in the old ways to work on your now-archaic tech stack (that you couldn't upgrade because of version incompatibilities). They'll also need custom-built dev systems that come with the project (because some of the tools are no longer available in those versions or at all). You won't be able to use new tools without first backporting them. You may have to deal with potential security issues in code that is no longer supported even though you don't even need that code, because it's there in the dependencies.

In fact, in some cases the use of lots of dependencies might actually be better for quick prototyping (because they let you do so much with so little development) that you don't have to maintain and extend than for long-term projects. It's a tradeoff. Either way has benefits and drawbacks.

FWIW FreeCodeCamp eventually teaches fullstack JavaScript SPA application development. It'd be weird for its creator to suddenly say you don't need any of that.

But whatever tools you used to use for the "vast majority" of web applications probably still exist. You are under no obligation to use the newer tools. Other people are developing new tools for their different needs and different applications, but this doesn't place a demand on you to follow suit.

For example, there's tons of libraries provided via CDN so you can link them in script tags. That's as far back as I can think in terms of JS tooling. Bower still exists. So do grunt and gulp. jQuery is still releasing new versions, so is angular 1. I assume backbone and knockout still exist.

If javascript fatigue was an epidemic, then there would be a huge swath of developers who just want to use the current, existing tools. That would surely provide a solid maintenance base for these existing tools so you can continue to use them for a very long time. Javascript fatigue seems like a self-correcting problem.

What do you mean without any JS necessary? You are introducing a JS library that does that for you, which defeats the point. Even bootstrap does that. It doesn't mean it's necessary.

I can find a lot of "no code necessary" apps that do the same in angular/react/whatever.js

What I mean is that you, the developer, don't need to write any JavaScript to implement your general web application.

I think this is obvious if you read the docs, which I encourage you to do:

http://intercoolerjs.org/docs.html

> Lots of smart people are simply abandoning front end development altogether. The Javascript community needs to face up to this fact

First, I'm not sure who these people are that can afford to just not work because they had a bad experience with a Javascript framework or two. Second, I'm not sure the onus is on the community to take their (or anyone else but their own) feelings into account.

I don't really see how Intercooler is any better than vanilla jQuery; you've just offloaded explicit promises and event assignment into custom HTML attributes that don't translate to any other framework. After doing some reading, it looks like you were frustrated with Angular's AJAX calls...did you try one with jQuery?

HTML-as-data-transport is the key to HATEOAS[1], which is what most distinguishes the web from other network application architectures[2]. Intercooler enables a fundamentally different network architecture than RPC-via-JSON, that of the original web network architecture as described and advocated for by Roy Fielding.

I know it is easy to dismiss intercooler, especially for those with a big commitment to the currently fashionable javascript technologies, but there is some good theory behind it. It is worth spending some time reading the blog and docs to understand the deeper aspects of the library.

[1] - http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

[2] - https://en.wikipedia.org/wiki/HATEOAS

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?

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.ht...

These are the crazy years.

> 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.

The advantage of CSRF/CORS/etc being taken care of by third party libraries is that it will be actually handled (even if its very basic) in sites created by beginners, which is better than not having it at all.

Thanks combatentropy. Maybe the OP hasn't been around as long as we have and doesn't have the background to understand.

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.

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/

>"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.

> can be replicated with simple DB calls, string concatenation [...]

You must not have seen the flame fest about PHP on the rest of HackerNews!

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.

> 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?

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.

> and "web applications" which are non-trivial interfaces to complex data

I'm yet to see these non-trivial interfaces to data that justify megabytes of JavaScript in actual production use. There are several cases when it makes sense (e-mail client (but not that much, and can be just fine without any JS whatsoever), text processor or spreadsheet, chat), but those are rare.

I write business applications for a living, and those tend to have lots of asynchronously loading data, dynamic UIs, and fancy little widgets like charts or graphs. Just because you never use them doesn't mean they don't exist.

You do realize that those "fancy little widgets like charts or graphs" don't need JavaScript? We had them for dozen years before the "everything needs JavaScript" fad.

OK, let's put charts and graphs aside. What do these business applications of yours do that need JavaScript and can't be equally well done traditionally, on the server side?

I'd love to know how you'd build an interactive chart that live-updates with new data and has pan/zoom functionality without Javascript. Or how you'd asynchronously provide updates to a stream of events (e.g. Facebook) from the server-side.

> Some developers simply choose complexity

Or have it chosen for them. I've been on dozens of "tool evaluation committees" in my life time and the only option that's never on the table is "no tool at all". It seems to me to be almost a no-brainer that if you can develop a functioning application using Javascript without using jQuery, or Angular, or React, or ext-js, or Dojo, or GWT, or whatever the hell else flash-in-the-pan "technology" we're going to be kicking off a never-ending migrating away from next week, you should. I find myself in a very tiny minority.

My thoughts about JavaScript and the libraries/frameworks/tools depreciation: 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).

"almost 7 years ago"

I'm working on software that was started in 1999, this isn't unusual.

We're in 2016.

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.

"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.

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.

And npm could learn a _lot_ from maven.

npm could be faster. What else could npm learn from maven?

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).

"The problem is the language [JavaScript] wasn't designed."

FTFY

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?!?!

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.

>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.

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.

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.

Could you provide the full title or a link to that particular talk of Jonathan Blow?

https://www.youtube.com/watch?v=k56wra39lwA Probably this one.

Sorry I forgot to paste it in my comment. It's the one that sgift has linked to.

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.

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.

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.

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.

Hello World is much easier.

Cross-platform compat is infinitely easier on the web.

Cross-form-factor compat is infinitely easier in HTML. If you think HTML is bad, try getting the same Qt app to run on a 4k desktop screen and a smartphone.

And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE? If it were just about document delivery, GET would be enough.

Mutli-user systems are significantly easier on the web. What you mention as a boon for the desktop is only a boon if you're only interested in supporting one user at a time.

You rightly mention deployment is easier. That's no small thing. I've seen entire departments grind to a halt for entire days, once a month, because they sucked at deployment.

What you are talking about being easy belies your values in what an application should be. If you valued different things in your applications, then you'd find the desktop system to be more difficult than the web. And that's why I say they are not fundamentally more or less difficult than each other.

> And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements?

For questionnaires and guest books. It was only later discovered that this allows to have an application that runs server-side, but is displayed on client's side.

> HTML was indeed originally designed for applications. [...] Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE?

What on earth do HTTP verbs have to do with what HTML was designed for?

> And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements? Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE? If it were just about document delivery, GET would be enough.

Indeed, the original draft for HTML did not include forms or input elements[0]. While HTTP had POST, PUT, and DELETE, those were supposed to be used for uploading new content or replying to newsgroups. In particular, the semantics for POST were quite different[1]: “Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted.”

While these features were added quite early in the development of HTML and HTTP, respectively, they certainly were not part of the original design.

[0] https://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt

[1] https://www.w3.org/Protocols/HTTP/Methods.html

Useless pedantry

In my experience with desktop apps beyond toy examples in VB6, asynchronicity is something you have to pay way more attention to in the desktop world than on the web. Sure, the web is sort of fundamentally asynchronous, but the interactions you're making with the server tend to be more coarse-grained and easy to reason about than a desktop app with a UI thread and processing threads that need to communicate often and at a fine-grained level of detail.

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)

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/1E2w0UQ4RhId5cMYsDcdcNwsg...

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.

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.

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.

> 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.

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

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.

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.

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.

No, this is stupid.

Show me the "business value" proposition for NOT using Elm (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.

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

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

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

Reply on news.ycombinator.com