The other kind of JavaScript fatigue • Hacker News Board

Re: The other kind of JavaScript fatigue

#81

Post by extrapickles » Sat, Jul 16, 2016, 4:53 PM UTC

thesmart wrote: post #12

I think the convenience of GitHub and NPM are good features, and it's easy to blame ease-of-use as a culprit. I have often pondered about how remarkably poor these tools are at representing repo quality. I think there are some basic questions to ask before accepting any unknown source in as a module. What is the core problem and requirements the source addresses? Does it verify the solution and how? What is the reput…

I would like this idea extended to versioning, where you get a simple release number and a risk number. Even for projects following simver, they all have a differing idea of how big a change is and simver doesn't cover bugfixes that make breaking API changes.

If a new version simply incremented the release number, and estimated the risk of issues from the previous version, it would be easier to tell if you wanted to update. Also after a project has a few releases under its belt, you can normalize the risk to other projects risk level (eg: project x always underestimates).

For open source projects, it enables tooling to look at the functions touched and the functions used by your code, and add risk to the update.

An example:

You are 3 versions behind, updates are versions 15/42 (minor bugfix), 16/500 (new minor feature) and 17/32000(major api change). Risk of updating is 42+500+32000. If you peg the amount of risk for a automatic update to 1000, then you would only get the first two.

The same thing in simver: 1.0.1 1.1.0 2.0.0

While its somewhat easy to gate simver, it doesnt lend itself to automated risk assesment as it would be much harder for a tool to tell the difference between a bug fix and new feature (too many bug trackers out there).

Re: The other kind of JavaScript fatigue

#82

Post by fauigerzigerk » Sat, Jul 16, 2016, 4:56 PM UTC

zbjornson wrote: post #66

cm2187 wrote: post #62

Earlier quoted context omitted.

I am not familiar enough with java which I assumed was a match for .net. But one line of code in .net. IO.File.ReadAllText(FilePath)

Yeah, .net is way nicer than java and your argument holds pretty well in that case.

What's wrong with

  new String(Files.readAllBytes(path));

or

  new String(Files.readAllBytes(path), StandardCharsets.UTF_8);

?

Re: The other kind of JavaScript fatigue

#83

Post by carsongross » Sat, Jul 16, 2016, 5:52 PM UTC

cm2187 wrote: post #60

douche wrote: post #56

Earlier quoted context omitted.

Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimp…

And not just in javascript. HTML is largely the culprit too. A lot is done in javascript that HTML should really handle. For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. It is such a common scenario there shouldn't be a need for a javascript framework to provide that. Same thing with responsive design. But these technologies are stuck in the 90s and barely evolve…

I have a library that attempts to improve the power of HTML:

http://intercoolerjs.org

Re: The other kind of JavaScript fatigue

#84

Post by keeringplastik » Sat, Jul 16, 2016, 7:58 PM UTC

My java script fatigue led me to disable it on my phone.

Seriously. I's been about nine months.

I use the exceptions feature to add in common sites where it is required.

I have been surprised over the course of this experiment by how little it is really needed for casual browsing.

And it has led to a decline in my consumption of garbage Internet by forcing me to take the time to add the exception which leads me to question whether this content is really worth the effort.

I think about building a feature that can do quick, single instance, javascript exceptions.

However, I fear it would undo the good done by the natural filter on my surfing.

And as a bonus, my data usage decreased considerably.

Re: The other kind of JavaScript fatigue

#85

Post by dwaltrip » Sat, Jul 16, 2016, 9:41 PM UTC

douche wrote: post #56

cm2187 wrote: post #32

Earlier quoted context omitted.

I think it's rather that the java and .net framework are pretty good out of the box. So there is only a need for additional framework for certain corner cases. And then some get bought by Microsoft and integrated out of the box, like the datavisualization libraries or xamarin. JavaScript on the other side is a language that only its conceptor could love. All these frameworks are sort of required to be barely producti…

Javascript has a terrible embarrassment of a standard library. Things that should just be baked into the language are not, which has lead to attempts to rectify that shortcoming, like jQuery, Underscore and LoDash. Because this standard library isn't implemented in the browser itself, where it belongs, people have gotten upset about downloading a few hundred kbs of a general purpose utility library, and instead reimp…

Javascript library size matters a lot on mobile. If I'm recalling correctly, a huge app can take seconds just to be fully parsed on many phones. There are dozens of millions of people who are using budget android phones that do everything thing they need, but don't handle heavyweight pages super gracefully.

Re: The other kind of JavaScript fatigue

#86

Post by oever » Sat, Jul 16, 2016, 10:24 PM UTC

Instead of nurturing narcissistic language ambassadors that drop their projects like they change fedora hats every time they get a new idea, let’s create more tools to improve code quality and foster a sense of community. Human progress is not going to happen by default. That was not the case with clean energy, or with quality education, and it will not be different with open source fragmentation. These problems require active monitoring and organized effort.

This is why I'm part of KDE. It's a large, diverse and productive community of people that want to bring Free Software forward. KDE exists 20 years this year and it's still growing and evolving. New developments come in, but they reviewed and nurtured in the community before being released under the KDE flag.

JavaScript could use a community like that where there is a common set of tools and values. The JavaScript that I see out there usually has very little quality control. It's easy to make something that looks nice and does not crash. But scaling up to an application that is complex and stable is hard. I learned this when developing the (now resting) library WebODF. Javascript comes with great tools like JSLint and Closure Compiler, and Jasmine but these are rarely used strictly.

Very few JavaScript developers have read 'JavaScript, the good parts' which is essential reading when writing non-trivial JS.

Node.JS promises the ability to reuse code on the server and the browser, but does not provide a module solution that makes that possible and works with the tools mentioned above.

Competition between KDE, GNOME and others on the Linux desktop exists because there is only one desktop on your computer. Javascript lacks such a focal point and JS framework developers can start new projects because it's easy to have a different half-baked framework in each browser tab.

You cannot build a cathedral out of market stalls. (KDE is the Sagrada Familia in this simile)

Re: The other kind of JavaScript fatigue

#87

Post by telotortium » Sat, Jul 16, 2016, 11:39 PM UTC

cm2187 wrote: post #74

krapp wrote: post #71

Earlier quoted context omitted.

>For instance why can't we just add a URL attribute to an input to provide autocomplete and validation. You can. is part of HTML5[0]. Of course, support may not be universal[1], which is why you will probably always have to use javascript if cross-compatibility matters. [0] https://www.w3.org/TR/html-markup/input.url.html [1] http://caniuse.com/#feat=input-email-tel-url

No by URL I meant the URL of the service that would provide the autocomplete or the validation. Like:

I'm not sure how either of these would help:

- validation: Fundamentally, to be able to trust the input, the server needs to validate it in its final state. The only reason validation should be done on the client is to reduce the latency from the time the user inputs the data to the time the validation result is reported, so the user can fix their input faster if it fails validation. Sending it to a URL before form submit doesn't make sense when the input will have to be validated after form submit anyway.

- autocomplete: It's unlikely that implementing this in native code will be faster than in Javascript. It's not significantly faster to make an HTTP request in native code -- native code is more advantageous for heavy computation, graphics, and multithreading. And yet, it's easy enough to make HTTP requests from Javascript that an autocomplete attribute wouldn't add much value.

Re: The other kind of JavaScript fatigue

#88

Post by Cozumel » Sun, Jul 17, 2016, 1:11 AM UTC

Not knocking the guy at all but..

'Recently I needed a library to build query strings, just a small one so that I wouldn’t have to include jQuery just for that. After a couple of hours of research, I had found several candidates'

That right there is the problem, learn your language. You don't need to spend 2 hours looking through other peoples code to solve your (string!) problem. Learn the language and write it yourself, it's not 'rolling your own' when it's something so basic.

Re: The other kind of JavaScript fatigue

#89

Post by renaudpawlak » Sun, Jul 17, 2016, 5:16 AM UTC

mooreds wrote: post #64

ourmandave wrote: post #9

Earlier quoted context omitted.

That's why there's JSweet, the Java to Javascript transpiler. http://www.jsweet.org/

Transpilers have their own issues. Source: I spent years developing with GWT

GWT is not a transpiler only. It is a framework. In GWT, the transpiler part is so little that it would be totally wrong to assume that transpilers are wrong because GWT is wrong. JSweet is like TypeScript. It just adds typing. No runtime, no lib, no framework, just a transpiler: I don't see any issues except if you consider that typing is an issue.

Re: The other kind of JavaScript fatigue

#90

Post by renaudpawlak » Sun, Jul 17, 2016, 5:25 AM UTC

pdimitar wrote: post #79

mooreds wrote: post #64

Earlier quoted context omitted.

Transpilers have their own issues. Source: I spent years developing with GWT

Agreed. Transpilers are saving you nerves initially at the expense of making you want to commit suicide later. Like when you need to debug in real time, or check underlying "native" objects, or when a library the transpiler is relying on has a bug. IMO transpilers are a Faustian deal. That's what my experience has taught me, your mileage may vary of course.

I disagree. I have been developing an IONIC application with JSweet. My experience is that when I want to refactor the code (for example, just renaming the data objects because the customer changes its mind about how to name something), then you are happy to have JSweet and you can make the code up-to-date in no time. The more the application gets complex, the better it is to have a transpiler to help you update your code safely. Your Faustian deal applies more to JavaScript IMO. It is very cool at the beginning, but at some point you start wondering what happens in your code and you need to write it again from scratch because it is not maintainable any more. JSweet is not GWT. It you don't like Java, try at least TypeScript and I am pretty sure you will change your mind.