The Deep Roots of JavaScript Fatigue • Hacker News Board

Re: The Deep Roots of JavaScript Fatigue

#131

Post by untog » Wed, Mar 16, 2016, 2:29 PM UTC

cognivore wrote: post #122

samcodes wrote: post #44

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly im…

> With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty?

Well, WebAssembly is on the way, so you won't have to use JavaScript. WebGL means you could, I guess, skip over the DOM entirely if you wanted to. None of this is fantastic, of course, but it's where we are.

Programs that people can download on demand existed, and still exist, yet the web is more popular. It's cross-platform, you don't have to install anything, updates are instant. What cross-platform UI are you going to use to address Windows, Mac, iOS and Android together?

To put it more succinctly, the "truth and beauty" for me is that it works, and it works today. I'm far happier iterating on that than noodling around imagining the perfect code execution environment that, as far as I can see, has no hope of existing any time soon.

Re: The Deep Roots of JavaScript Fatigue

#132

Post by klibertp » Wed, Mar 16, 2016, 2:30 PM UTC

mkozlows wrote: post #114

prewett wrote: post #35

Earlier quoted context omitted.

JavaScript is the only UI environment that has gone through 10 years of solid churn. Pick any other UI environment besides HTML/CSS/Javscript and it is pretty stable. So why is the web so churny? It makes me think there is something rotten underneath.

That's not even true, it's just that nobody pays attention to other things. Look at Windows desktop apps. If you wanted to make a native Windows desktop line of business app in 2000, you would use Win32 APIs. In 2002 or so, you were supposed to use WinForms. And then it was supposed to be WPF. And then Silverlight. And then WinRT.

Don't forget about MFC somewhere between WinAPI and WinForms :)

And it's worth noting that in this case we're talking about a single entity - Microsoft - pushing these changes. In the JS-land, there are many more actors, and every one of them tries to be innovative: this has to result in a lot of changes over relatively short time.

Nothing wrong with it, too. I think that, over time, the ecosystem will converge on a couple of best solutions and that it will be of higher quality exactly because of a "chaos" we're seeing right now.

Re: The Deep Roots of JavaScript Fatigue

#133

Post by mattmanser » Wed, Mar 16, 2016, 2:32 PM UTC

manyxcxi wrote: post #58

mattmanser wrote: post #53

Earlier quoted context omitted.

I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5. It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways. So the JS churn model has begun to infect anot…

Yeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.

That doesn't mean they have to re-architecture their MVC to force you to use DI all over the place whether you want to or not. Or to start running command windows when you used to have a working IDE. Hell, even the new config loading is an utter pain in the ass compared to simply just accessing a static object available from everywhere.

There are great bits, don't get me wrong, but I do wonder how much of their larger audience are actually going to enjoy this. It presently feels like a massive step back for very little gain.

It just feels, looks and smells like the old JavaFactoryHammerWidgetFactoryFactory of the days of old, i.e. over-engineering which means you can't get any actual functionality done as there's more scaffolding than functional code. You end up drowning in utterly useless code that doesn't really do anything.

Re: The Deep Roots of JavaScript Fatigue

#134

Post by evook » Wed, Mar 16, 2016, 2:34 PM UTC

Yaggo wrote: post #111

aedron wrote: post #108

Earlier quoted context omitted.

> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alon…

> [Javascript] simply is too limited a language to be used for large and complex applications. The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser). Electron? Atom? Slack? React Native? Espruino? Also, there are plenty of non-web Node.js applications, e.g. https://github.com/si…

Wrapping a browser instead of using one directly doesn't make your application run in a non-browser runtime environment.

And to be completely honest, probably sacrificing a bit karma. All of your examples enforce my point of view on JS as a 'use it as minimal as necessary' language else avoid it.

Re: The Deep Roots of JavaScript Fatigue

#135

Post by [deleted] » Wed, Mar 16, 2016, 2:41 PM UTC

aedron wrote: post #108

samcodes wrote: post #44

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alon…

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#136

Post by dwaltrip » Wed, Mar 16, 2016, 2:44 PM UTC

vmware505 wrote: post #22

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem…

Ember is nice, but it is a gigantic framework with a steep learning curve, and very heavy on the wire (lots of kb). I used it at my last job.

I'm using mithril.js right now for a side project, with basic ES5 and no build tools. Mithril has a tiny API but still offers surprising amounts of power.

I'm enjoying the simplicity of everything. It's been nice spending way less cognitive energy to understand how all the pieces fit together =) I may have to add some tooling in when I deploy the finished project, but I'm going to keep it as minimal as possible.

Re: The Deep Roots of JavaScript Fatigue

#137

Post by buchanaf » Wed, Mar 16, 2016, 2:45 PM UTC

douche wrote: post #110

Klathmon wrote: post #101

Earlier quoted context omitted.

I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and sta…

It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the…

'It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language.'

I think you are mistaking the language with the browser.

Re: The Deep Roots of JavaScript Fatigue

#138

Post by protonfish » Wed, Mar 16, 2016, 2:53 PM UTC

samcodes wrote: post #44

I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the br…

I don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else.

I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web dev, I can tell you my experience was like turning on the lights after struggling in the dark.

Basically what I found is that web app development was designed to work great in specific ways. If you don't know this and try to get it to work in a way that it was never meant to, you're gonna have a bad time. Sadly, every front end framework and many JavaScript libraries fall into this category. They focus on bending the natural web development paradigm into some other form. Which one will "win"? None - there's no right way to do something wrong. The real question is when we will stop falling for the pitch of the snake oil salesmen.

I assure you, there is no functionality that any of the frameworks bring that does not already exist and can be implemented in much simpler, maintainable and architecturally sound ways. Do not believe what the Framework charlatans claim. I can disprove every claim with real, working code examples.

Another reason we are inundated with poor frameworks is there is no other good entry point for developers new to web application development. Nobody wants to (or should have to) read the HTTP spec when they just want a simple CRUD app.

In summary: the reason these JavaScript frameworks exist is 1) Easy starting point for beginners 2) Make web development more like desktop/OOP/whatever the average developer is used to. There there cannot be a "good" web architecture until one is based on how web development actually works, not how we think it should work.

Re: The Deep Roots of JavaScript Fatigue

#139

Post by cableshaft » Wed, Mar 16, 2016, 2:56 PM UTC

Yaggo wrote: post #55

cm2187 wrote: post #51

Earlier quoted context omitted.

What's rotten is probably raw javascript. The fact that pretty much no one uses raw javascript and have to rely on all these libraries to abstract the uglyness and inconsistencies isn't a vote of confidence. Javascript is popular by necessity not by its own merits. All new and growing platforms (iOS, Android) have been locked down into proprietary languages / libraries, and javascript is the only language neither App…

Oh, language is rotten if developers use libraries and abstractions? When was last time you wrote an application in "raw" Python/C/Swift/Erlang? (Whatever "raw" is supposed to refer to, is standard lib allowed?) No language is perfect, and javascript is actually pretty nice one, also considering that there are multiple independent runtime implementations for almost every platform, I would say javascript as an ecosyst…

I write applications in raw Python all the time. True, they're text-only (or text as graphics) terminal applications, but it's surprisingly versatile and very pleasant to code in, so much so that I've been trying to make more and more of my ideas console friendly.

Re: The Deep Roots of JavaScript Fatigue

#140

Post by cableshaft » Wed, Mar 16, 2016, 3:03 PM UTC

untog wrote: post #129

rimantas wrote: post #104

Earlier quoted context omitted.

> Today there is huge demand for the ability to develop > desktop standard applications inside the browser. Is there? Or just devs wanting to do that, for reasons unknown? I as a user could not care less about "desktop standard applications inside the browser", desktop applications work just fine.

It's a huge boon for administration - auto updates, no install procedure, cross platform...

...and difficult to pirate, a major reason so much software moved to the web.

On the negative side for the consumer, the software and whatever data you committed to it will disappear if the company ever decides to stop supporting it or shuts down.

Also you are pretty much forced to be online in order to use it, so if your device isn't in a wifi friendly area and/or you're trying to limit your internet usage for whatever reason (i.e. more productive with less distractions), the software is useless.