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

141–150 of 200 posts

Re: The melting pot of JavaScript (2017)

#141

Post by stickfigure »

tmerse wrote: post #131
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.

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

That's cool, and will keep it in mind for the next time I work on a node project.

Looks like it works by having the typescript compiler generate experimental annotations in the output javascript, and reading it using a polyfill for the proposed ES7 reflection api. On one hand, yeay looks like proper runtime reflection is coming! On the other hand, it doesn't sound fully baked yet...

Re: The melting pot of JavaScript (2017)

#142

Post by pdimitar »

kibwen wrote: post #45
hrabago wrote: post #23

Earlier quoted context omitted.

Ten years ago, JavaScript was my go to when I wanted to expose others to coding. It still is today, but now that comes with the caveat that the most popular libraries and framework require a significant amount of prior knowledge to understand and to start using. I haven't done this exercise in a long while, but the last time I tried to start a project from the "most current and stable releases and recommendations", I…

JavaScript is still what I use to introduce programming to new people, because for people who haven't done their dues learning how to use a command-line, the hardest part of getting started with programming is getting your computer set up to do it at all. And since everyone already has a browser, getting started with coding only requires showing them how to open the developer console.

Installing stacks like Rust, Erlang/Elixir, Go and maybe OCaml is so fast these days that you likely will not have halved your coffee by the time it's done.

I agree getting to the browser dev console is instant gratification but I don't view 5 minutes of installation as a punishment from Hell either.

Re: The melting pot of JavaScript (2017)

#143

Post by pdimitar »

jancsika wrote: post #115
oaiey wrote: post #59

Earlier quoted context omitted.

Fair, but most stacks including the previous infamous ones are two or three lightweight installs away. The VSCode/Atom/Sublime generation of IDE replacements made that possible. I come from an environment (.NET) where setup was a day or two of work but now is a matter of 10 or less minutes).

10 minutes is still two orders of magnitude longer than " ."

And? Is 10 minutes so damning?

Re: The melting pot of JavaScript (2017)

#144

Post by h1d »

_hardwaregeek wrote: post #14

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up…

Rails is so much into its own world I hate it. Glad JS is developing in different ways. Try parcel bundled, it's zero config yet it doesn't invent its own world to freak newcomers.

Re: The melting pot of JavaScript (2017)

#145

Post by pdimitar »

c-smile wrote: post #29
mattmanser wrote: post #20

Earlier quoted context omitted.

I'm still firmly of the opinion that nobody wants a SPA apart from the developers of that app. I'd bet any of us could find a ton of weird and unintuitive things your app does, as well as it probably being slow to load, hard to use and brittle, in that you'll regularly put out an update that inexplicably breaks something for a day or two. Add on top that massive extra expense of doing a pure SPA compared to the ease…

I've architected Web Application that runs as in a) connected as in b) occasionally disconnected mode (LocalStorage + sync when online). For #b SPA is the only option.

Nobody is saying that SPAs using modern web technologies -- like offline mode -- do not have any use.

The problem is that SPAs are shoehorned on many places where they are absolutely not necessary and only complicate things.

Re: The melting pot of JavaScript (2017)

#146

Post by Daishiman »

undersheet wrote: post #111
optimuspaul wrote: post #64

Earlier quoted context omitted.

> Python not as scalable Not scalable in what way? Every aspect of scalable that I can think of is in no way limited by choosing python as your language.

> I can think of Mayne that is your problem. Try new stuff. V8 is still one of the fastest and most optimized VMs.

That has absolutely no relationship to backend scalability whatsoever.

Re: The melting pot of JavaScript (2017)

#147

Post by Daishiman »

undersheet wrote: post #114
_hardwaregeek wrote: post #48

Earlier quoted context omitted.

First, Webpack and Babel are totally used for backend. If you look at a lot of Node libraries, they use ES6 modules in their [docs]( https://github.com/graphql/graphql-js ). While you could use mjs for this, it's still experimental. I do think create-react-app is a good innovation in the JS world. However, I've never found a good equivalent on the back end. Setting up even the most basic CRUD REST API requires a whol…

JS is so good for APIS because of its dynamic JS objects. If you then take also a document storage you don't need any ORM anymore and write your entire API in 5 mins. Rails was a nightmare compared. JS lets you do stuff yourself. You don't any framework holding your hand. Maybe that's your problem.

In what world you think the usability of a language is determined by being able to get a Restful API up in 5 minutes?

Yeah, document storage for business-critical data. I'll pass. There's a reason important data gets stored in Postgres.

Re: The melting pot of JavaScript (2017)

#148

Post by pdimitar »

int_19h wrote: post #135
c-smile wrote: post #84

Earlier quoted context omitted.

> 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 possibilitie…

Are you not forgetting something? Java is to this day several times faster than JS and sources for that abound on the net (including [0]).

No, we wouldn't fight for how to compile C in it. We would very likely fight to make the payloads and bootstrap times smaller.

[0]https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: The melting pot of JavaScript (2017)

#149

Post by adrianN »

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.

On the other hand, most developers speak at least enough bash to read bash scripts, and bash's backwards compatibility is pretty good.

Re: The melting pot of JavaScript (2017)

#150

Post by TeMPOraL »

adrianN wrote: post #133
spricket wrote: post #125

Earlier quoted context omitted.

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.

That's true. Regression tests are also useful.

But TDD is about neither, it's about test-first approach at the unit test level, which is arguably less useful and leads to design by random walk.

Post reply on HN