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

111–120 of 200 posts

Re: The melting pot of JavaScript (2017)

#111

Post by undersheet »

optimuspaul wrote: post #64
undersheet wrote: post #33

Earlier quoted context omitted.

> Java, C#, Rails, and to some extent Python are much saner choices. Python not as scalable, Rails is stagnating, the ecosystem doesn't evolve anymore/dying, doesn't play well with SPAs, C# weak to none ecosystem outside of Windows and devs earn a fraction, Java verbose and dev productivity subpar (there was a reason people came up with Scala), Java devs also suffer lower salaries

> 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.

Re: The melting pot of JavaScript (2017)

#112

Post by lopatin »

pitaj wrote: post #68
orf wrote: post #47

Earlier quoted context omitted.

> Can you explain what Java offers with regard to reflection that JS doesn't? Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation. Oh, and typeof checking that isn't disgustingly broken.

> getting the return type of a method and getting the input parameter names (+ types) Type information literally doesn't exist at runtime, though. Isn't it kind of ridiculous to compare languages like that?

> Type information literally doesn't exist at runtime, though.

Correct if I'm wrong, not all types get erased in Java. Doesn't type erasure only happen for generics? Say I have a non generic, plain Java class and want to inspect one of it's method's return types at runtime to see if it returns class A or class B. I can do that, right?

Re: The melting pot of JavaScript (2017)

#113

Post by _hardwaregeek »

vmware505 wrote: post #107
_hardwaregeek wrote: post #78

Earlier quoted context omitted.

I've wanted to use Ember, but I've never bothered to sit down and learn it. What ever happened to Glimmer? I remember it being hyped up as a crazy fast virtual DOM, but I haven't heard anything recently.

It is super easy to pick up, you can understand the whole concept quite quickly. Follow one the tutorial and you will be ready to deploy new apps in days. One of my fav free tutorial: https://www.yoember.com

Thank you for the link! For some reason it gives a "Your connection is not secure" error on Firefox, but I managed to find the tutorial via Google. I'll give it a shot sometime

Re: The melting pot of JavaScript (2017)

#114

Post by undersheet »

_hardwaregeek wrote: post #48
undersheet wrote: post #32

Earlier quoted context omitted.

In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even i…

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.

Re: The melting pot of JavaScript (2017)

#115

Post by jancsika »

oaiey wrote: post #59
kibwen wrote: post #45

Earlier quoted context omitted.

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.

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 "."

Re: The melting pot of JavaScript (2017)

#116

Post by _hardwaregeek »

com2kid wrote: post #100
_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…

> 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 whole lot of typing for very little reward. This is where services like Google Firebase Functions become useful. I went from having never written a REST API in my life, to up and running in under 20 minutes. First time I went to create…

Firebase is a dream. It's almost a shame they got bought by Google because it's such a fantastic idea. All of the things I used to dread setting up (auth, deployment, serverless) are automated and dead easy. The documentation is clear and caters to the common usecases. I managed to set up a Sendgrid email that sends on database writes within an hour or two.

Re: The melting pot of JavaScript (2017)

#117

Post by est »

orangeeater wrote: post #35
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…

> Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated Can you explain what Java offers with regard to reflection that JS doesn't? My feeling is that reflection is almost moot in JS since you can inspect/mutate objects at runtime however you like. But maybe I'm missing the point of reflection. There is a Reflect object with a bunch of static methods on i…

> Can you explain what Java offers with regard to reflection that JS doesn't?

One thing comes to mind, how to twinkle stuff inside closures?

Re: The melting pot of JavaScript (2017)

#119

Post by BigJono »

2trill2spill wrote: post #102
BigJono wrote: post #101

Earlier quoted context omitted.

I know a couple that would tell me to go jump if I suggested they aim for 90% code coverage on a CRUD app. They also write very clean, maintainable code and do it very, very quickly. There's always a trade off.

I'm not writing a CRUD app, I'm writing a program that my company expects to put into production. Writing tests is very much a part of writing production code.

?

CRUD apps generally go into production, unless something goes horribly wrong.

Re: The melting pot of JavaScript (2017)

#120

Post by stickfigure »

untog wrote: post #103
orf wrote: post #86

Earlier quoted context omitted.

When you're comparing the relative power of reflection within the language, absolutely not.

But what would you use that information for, given that the language has no types? A JS function has no guarantees of what type a function returns anyway. It's like taking issue with the fact that a car doesn't come equipped with skis.

It's like taking issue with the fact that a car doesn't come equipped with skis.

To draw out that analogy... we live in Greenland. Cars with skis are surprisingly useful.

Post reply on HN