The Controversial State of JavaScript Tooling • Hacker News Board

Re: The Controversial State of JavaScript Tooling

#151

Post by hassy » Wed, Feb 03, 2016, 10:41 AM UTC

iheartmemcache wrote: post #122

hassy wrote: post #109

Earlier quoted context omitted.

> But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies. Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the…

Sort of kind of. I deal as a consultant for large corporations where down-time is a no-no. Think secondary market-makers, institutional investors, healthcare insurers. Not quite rocket control systems or firmware for dialysis machines but five-nines is a given. Bugs happen everywhere. That's an axiom. You can decrease the risk of it with formally verifying the system (see: SPARK for Ada), but they'll occur. The diffe…

I agree with pretty much everything you said - and thanks for sharing your perspective. Node.js is still very young and the enterprise ecosystem has a long way to go, but it's getting there (e.g. IBM's acquisition of StrongLoop, the EnterpriseJS initiative - https://enterprisejs.io) I've done a bit of work with Erlang, which is all about the 9s (though it doesn't have the enterprise ecosystem on par with Java or .NET around it) but for a lot of software, Erlang is an overkill, as would be formal verification for example. A lot of software is just fine being built with Node or other young tech trading stability for productivity and time-to-market.

Re: The Controversial State of JavaScript Tooling

#152

Post by justaaron » Wed, Feb 03, 2016, 11:09 AM UTC

One should consider the possibility that the entire web development industry is a giant busy-work factory making half-baked kluges to a fundamental problem that will never be papered over: http is a stateless protocol for sending hypertext. markup. meta-data and context for resources in a folder somewhere. It's a file-system thing. A web browser is a declarative-markup-tree rendering-engine with scriptable nodes, and the language chosen for scripting is an accident of history. Using http and web browsers in ways they never were intended to be used is possible, albeit painful. Now that we have virtual DOM's and isomorphic platforms like clojure/clojurescript and we compile to JS, now that we have JS on the server, now that we have our head so thoroughly up our ass that we forgot the point, now we can consider the circle of ridiculous nonsense complete...

The world wide web took off, and we have to live with it's technical debt, or...

The solution is simple, bold, and risky: 1) pick a port. (Nowadays that's even a joke. we tunnel everything over port 80.) 2) pick a protocol with some future (hey let's just tack websockets on as an upgrade, gradually get browser support, etc) 3) keep moving...

I am not ultra impressed with the web of 2016... The web of 1996 was way cooler. I want a VRML3 rendering engine for a browser.

Re: The Controversial State of JavaScript Tooling

#153

Post by justaaron » Wed, Feb 03, 2016, 11:12 AM UTC

justaaron wrote: post #152

One should consider the possibility that the entire web development industry is a giant busy-work factory making half-baked kluges to a fundamental problem that will never be papered over: http is a stateless protocol for sending hypertext. markup. meta-data and context for resources in a folder somewhere. It's a file-system thing. A web browser is a declarative-markup-tree rendering-engine with scriptable nodes, and…

Oh, don't even get me started with build tools. Nowadays we have build tools to build build tools.

I'm sorry, but when FRONT-END DEV considers build tools standard we are LOST lost lost...

How many JS libraries and CSS scripts do we really need to embed in a page? How many of those functions or classes are even being used in that page? Why do I have to scroll to view source on a page with mostly text and a few colored boxes?

Hand-coded html and css is not that hard folks...

it's just the habits, the frameworks, etc...

1/4 of the web is powered by Wordpress wtf!?

Re: The Controversial State of JavaScript Tooling

#154

Post by justaaron » Wed, Feb 03, 2016, 12:09 PM UTC

justaaron wrote: post #153

justaaron wrote: post #152

One should consider the possibility that the entire web development industry is a giant busy-work factory making half-baked kluges to a fundamental problem that will never be papered over: http is a stateless protocol for sending hypertext. markup. meta-data and context for resources in a folder somewhere. It's a file-system thing. A web browser is a declarative-markup-tree rendering-engine with scriptable nodes, and…

Oh, don't even get me started with build tools. Nowadays we have build tools to build build tools. I'm sorry, but when FRONT-END DEV considers build tools standard we are LOST lost lost... How many JS libraries and CSS scripts do we really need to embed in a page? How many of those functions or classes are even being used in that page? Why do I have to scroll to view source on a page with mostly text and a few colore…

In a nutshell, I think, with some risk, that some innovators could literally pick a port, pick a protocol, and build a different kind of browser... once there is some content for that platform it's a matter of time before early adopters download one of these new class of browsers and so forth... it's how it happened the first time, and it's how pretty much everything happened... even games (second life) etc.

and meanwhile, the web can go back to being a directory preview/ resource hyperlink web...

Re: The Controversial State of JavaScript Tooling

#155

Post by uptownJimmy » Wed, Feb 03, 2016, 1:02 PM UTC

iheartmemcache wrote: post #122

hassy wrote: post #109

Earlier quoted context omitted.

> But we've reached a point where modern web applications are pulling in dozens of dependencies in both production and development toolchains, and increasingly those dependencies are themselves built on top of other dependencies. Um, take ANY non-trivial application, written in any language, and then follow the chain of its dependencies all the way down to the kernel, and shriek in horror. JS is not unique here, the…

Sort of kind of. I deal as a consultant for large corporations where down-time is a no-no. Think secondary market-makers, institutional investors, healthcare insurers. Not quite rocket control systems or firmware for dialysis machines but five-nines is a given. Bugs happen everywhere. That's an axiom. You can decrease the risk of it with formally verifying the system (see: SPARK for Ada), but they'll occur. The diffe…

I cannot recommend this post highly enough. I get the feeling that a LOT of non-enterprise devs could stand to reflect on it.

Re: The Controversial State of JavaScript Tooling

#156

Post by Grue3 » Wed, Feb 03, 2016, 1:35 PM UTC

SapphireSun wrote: post #47

rapind wrote: post #34

Earlier quoted context omitted.

There are quite a few disadvantages to using a CDN like Google. - Delay for DNS resolution and the new TCP connection could be non-trivial (some tests show 300ms+). - A JS CDN is also likely tracking your traffic and you may not want them to. - No offline dev environment (on the plane). - Server run (phantom etc.) tests might run super slow if they have to pull in a remote js library. - Probably issues when it comes…

I've also encountered problems with China blocking jQuery or fonts from Google.

This is solvable by also hosting a local copy and load it if CDN is not available. Example (from my website):

        
        window.jQuery || document.write('')

Re: The Controversial State of JavaScript Tooling

#157

Post by darkarmani » Wed, Feb 03, 2016, 1:52 PM UTC

lhnz wrote: post #24

The problem with hypermodularization is that it takes time to make a decision on what module to use for every task. If you have to to do this with 100s of modules, you're wasting a lot of valuable time. Does anybody know a quick way of making the right decision? NPM is like a crowded graveyard nowadays (or like .com domain names - where all of the good module names have been taken along time ago and now all the best…

You just have to look at the module named mkdirp to know there is a problem with hypermodularization. Here is all of the modules related to making a directory -- https://www.npmjs.com/search?q=mkdir

Re: The Controversial State of JavaScript Tooling

#158

Post by TimJYoung » Wed, Feb 03, 2016, 3:03 PM UTC

cgh wrote: post #107

TimJYoung wrote: post #55

Speaking of controversial: I think things are going to keep being bad until developers realize that the problem isn't technical, but rather economic. Back before the current "give it all away for free" trend became a thing, commercialization of software was a given and allowed "winners" to emerge from the chaos. The merits of the "winners" isn't important here, it's the stability that comes with it. As long as everyt…

Python and gcc are free software too. Lots of stability in the world of Python and C. Hopefully you don't think free or open source software is somehow limited to the world of Javascript. Here's why there is so much churn in the JS world: everyone is attempting to polish a turd.

I don't think those two are good examples. They both had significant commercial ecosystem support, either in the form of a large company that pushed it (Google with Python) or in the form of other commercial compilers that promoted the ecosystem (lots of commercial C compilers over the years - MS, Borland, Watcom, Metrowerks,....).

Re: The Controversial State of JavaScript Tooling

#159

Post by TimJYoung » Wed, Feb 03, 2016, 5:09 PM UTC

aikah wrote: post #116

TimJYoung wrote: post #91

Earlier quoted context omitted.

I'm not complaining about anything. I'm trying to put forth a reason for why so many other developers are complaining about the constant churn in the JS tools ecosystem, and the immense amount of setup required to do even simple web apps. Judging by the downvotes, I'm guessing my opinions aren't very popular or I strayed too far off-topic. :-)

> and the immense amount of setup required to do even simple web apps. This complexity is sold by people who are selling complex tools. I don't use Babel or Webpack because it is not necessary. I usually try to remain framework free or use a framework that has a minimal complexity cost. You can write a complex application with jQuery , Angular 1.0 or Vue.js or even React in ES5 and it will not require any complex ass…

Exactly which tools are being sold ? All of the examples that you cite are free, which kind of provides evidence for my idea that the complexity is being caused by the proliferation of the tools/libraries due to them being free.

Re: The Controversial State of JavaScript Tooling

#160

Post by wwweston » Wed, Feb 03, 2016, 8:04 PM UTC

davedx wrote: post #138

wwweston wrote: post #115

Earlier quoted context omitted.

> I personally sometimes have to open up 5+ Github repositories to check their last commit, number of contributors, interfaces, code quality, unanswered issues, etc. Only one of these, it seems to me, is likely to be consistently related to the quality of the module.

Don't keep us in suspense. Which one?

Honestly, I think it's better as a question/koan than as explained. Asking yourself how good these each of signals really is and asking yourself how they could fail is probably much better than having a random internet commentator try to talk you into it.

But:

- last commit: I'm not surprised to see this here. Almost the entire industry is deeply invested in the idea that software can never be done, only abandoned, so deeply it's almost invisible. And projects with enough surface area likely are like the proverbial shark: either moving or dead. But for modules with limited, well-defined functionality, reaching a steady state where the project is actually done and updates are rare should actually be a sign of quality.

- number of contributors: again, I suspect that where this coheres with quality, it's probably correlated with size/surface area. Plenty of limited, well-defined projects probably are good with one or a handful of contributors.

- interfaces: are we talking about presentation of the project? Or the UX of an app? Either one could be a sign of overall craftsmanship, or it could be a sign that the author is concerned with appearances/marketing.

- code quality: tautologically true (code quality is related to project quality) but not helpful. One might easily mean "do the authors of this module follow my favorite code style guide," in which case I think this is extra likely to lead you astray.

- unanswered issues: unanswered issues seem like a great signal. If they're present (and real), the author(s) either can't fix them, or the project is abandoned while actually needing improvement. Inversely, if there are answered issues, the project is being used and attended to.