Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The melting pot of JavaScript (2017)

increment.com

Post reply on HN
Print view View original

131–140 of 200 posts

Re: The melting pot of JavaScript (2017)

#131

Post by tmerse »

stickfigure wrote: post #126
kangoo1707 wrote: post #71

Earlier quoted context omitted.

Do you have any concrete example for "For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature"? Tip: in JS, I don't want OOP class. If you really want class, could you show me the intention behind it?

Every popular ORM uses reflection to determine how to map fields to columns. For example, what type of date or money object to use. I automagically map some postgres JSONB columns to a parsed object form. Looks just like a regular typed nested object.

You should have a look at typeorm [1]. Typescript ORM with decorator support.

1: http://typeorm.io/

Re: The melting pot of JavaScript (2017)

#132

Post by adrianN »

sonnyblarney wrote: post #129
spricket wrote: post #26

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of th…

Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a differ…

JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.

Re: The melting pot of JavaScript (2017)

#133

Post by adrianN »

spricket wrote: post #125
2trill2spill wrote: post #98

Earlier quoted context omitted.

What kind of "good engineer" refuses to write tests?

I don't write many tests. I've found with experience and heavy linting you can avoid the vast majority of bugs. Not much point to spending a ton of time on tests if they hardly ever break for nontrivial reasons. My normal setup for java is: Linters: ErrorProne Checkstyle PMD SpotBugs Nullaway All with highly customized settings All warnings enabled on javac Google-java-format to autoformat everything on build. For ru…

I don't see how linting and experience prevents logic errors, missed corner cases, or misunderstandings of the requirements. In my experience integration tests are crucial to robust software.

Re: The melting pot of JavaScript (2017)

#134

Post by int_19h »

mr_toad wrote: post #93
simion314 wrote: post #18

Earlier quoted context omitted.

>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…

> I found a tutorial, the commands did not work That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

JS has a lot more churn than pretty much any other mainstream language or ecosystem.

Re: The melting pot of JavaScript (2017)

#135

Post by int_19h »

c-smile wrote: post #84
pitaj wrote: post #66

Earlier quoted context omitted.

> something close to JavaVM and HTML DOM exposed to it > ugly WebAsm WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.

> but you can essentially use it that way "Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah. W3C DOM was defined initially in terms of Java interfaces. Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning? Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Inst…

> Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning?

We'd be ranting at JVM for not having the features necessary to compile high-perf C code into it, for one.

Which is why Wasm is fundamentally a better approach. It's that one case where it makes sense to go as low level as possible (while retaining cross-platform support), to allow as many future possibilities building on this foundation as possible.

Re: The melting pot of JavaScript (2017)

#136

Post by stickfigure »

hajile wrote: post #128
stickfigure wrote: post #126

Earlier quoted context omitted.

Every popular ORM uses reflection to determine how to map fields to columns. For example, what type of date or money object to use. I automagically map some postgres JSONB columns to a parsed object form. Looks just like a regular typed nested object.

That's a solution looking for a problem in JS. You're thinking in types instead of in terms of a dynamic language. You basically HAVE to do this in Java otherwise your program won't work. In JS, you can look everything over at runtime and dispatch from there (made much easier because first-class functions and closures are a thing).

you can look everything over at runtime

Correct, that's what you have to do in dynamic languages - look at what came in from the database and manually validate+convert it into the format you actually want. Also with pretty much every other form of input (JSON bodies, form posts, queue messages, etc). It's a lot of tedium.

When working with node/python/ruby, I often find myself wishing I could just declare a type and be assured that "the system" will get it right instead of me having to code it out myself. You know, like Java.

Well-written Java programs are generally more concise and less verbose than well-written JS/Python/Ruby programs. Which is to say, when programmers actually validate input instead of (ahem node) crashing the process and dropping all inflight connections when someone submits a json body missing an expected field.

BTW absolutely nothing prevents you from building Java apps by declaring everything as Map. Nobody does that because it's a horrible way to program.

Re: The melting pot of JavaScript (2017)

#137

Post by TeMPOraL »

untog wrote: post #105
TeMPOraL wrote: post #58

Earlier quoted context omitted.

The equivalent "modern" workflow is written, owned and optimized by build brainiacs with turnover on the order of weeks. I'd say that maintenance of "crude shell scripts" is much less difficult and expensive than keeping up with the latest webdev "standard practice".

You'd be wrong. I'm not arguing that Webpack is a deeply confusing system, but there are tens of thousands of people out there figuring it out too. Almost any question has an answer a Google search away. Your bespoke bash script has no such community.

But my bespoke bash script has longer shelf life, which is the entire point here.

Re: The melting pot of JavaScript (2017)

#138

Post by gwillz »

adrianN wrote: post #132
sonnyblarney wrote: post #129

Earlier quoted context omitted.

Sympathies to your valid concerns ... Though Java was 'designed', it was not 'designed' to be an http/web server. JS, particularly Node.js has really adapted itself to that well. And one small but massive difference: JSON is how data is passed and it fits seamlessly into Javascript, and doing JSON in Java is an ugly, ugly thing. As soon as you compare not JS/Java, but Java/Tomcat vs. JS/NodeJS - then you get a differ…

JSON is how some data is passed today. It's certainly not the best way and might go out of style just like XML did a while ago.

I was reading something on HN recently and I ended up on this wiki article.

https://en.wikipedia.org/wiki/Billion_laughs_attack

It got me thinking about it. JSON is annoyingly simple at times, yes. But that also protects it from some pretty gnarly stuff seen in XML and YAML. I suspect it's a considerable contributor as to why it's the choice transport format.

I wouldn't toss it in with XML just yet.

Re: The melting pot of JavaScript (2017)

#139

Post by lostapathy »

EduardoBautista wrote: post #99
mr_toad wrote: post #93

Earlier quoted context omitted.

> I found a tutorial, the commands did not work That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

But it is way more common in JS. It got to the point that I do not trust tutorials that are not “official”.

Honestly, this is even a problem in "official" tutorials. I set out to learn some basic node a while back. The official docs then were out of date enough to not work to install node (nor were they off a trivial amount). I finally figured it out and PR'd a doc fix, but you shouldn't have to do that to try out a platform.

Re: The melting pot of JavaScript (2017)

#140

Post by lostapathy »

mr_toad wrote: post #93
simion314 wrote: post #18

Earlier quoted context omitted.

>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) i…

> I found a tutorial, the commands did not work That’s hardly unique to Javascript. Back before the internet even existed I’d seen out of date make files which did nothing but spit out linker errors due to API changes in libraries.

What's unique to JS is how short the shelf life of documentation is compared to the past. 15 years ago if you found a tutorial and it didn't work, it meant it was either many years old or you could install one java (etc) version prior and it'd work again. It seems like a lot of JS docs go obsolete within months if not weeks.
Post reply on HN