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

101–110 of 200 posts

Re: The melting pot of JavaScript (2017)

#101

Post by BigJono »

2trill2spill wrote: post #98
BigJono wrote: post #97

Earlier quoted context omitted.

> Besides were using Typescript, have automated tests, code reviews and Manual QA, I'm not worried about the code not being solid or robust. Oh god... Yeah, no. None of this stuff is a substitute for actual code quality. Give me a good engineer that refuses to write tests over a mediocre one that does TDD any day.

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

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.

Re: The melting pot of JavaScript (2017)

#102

Post by 2trill2spill »

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

Earlier quoted context omitted.

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

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.

Re: The melting pot of JavaScript (2017)

#103

Post by untog »

orf wrote: post #86
pitaj wrote: post #68

Earlier quoted context omitted.

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

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.

Re: The melting pot of JavaScript (2017)

#104

Post by DLA »

undersheet wrote: post #36
DLA wrote: post #3

Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at th…

> cognitive load of tool options First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use. Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick. Why are people criticizing something they have never used?

My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enough posts and people who tell you what you should use." -- sure but what if opinions very widely? There's the cognitive load or put another way friction-to-first-use.

Re: The melting pot of JavaScript (2017)

#105

Post by untog »

TeMPOraL wrote: post #58
gedy wrote: post #25

Earlier quoted context omitted.

Maintenance. Because seems they are usually written/owned/optimized by some build brainiac that becomes a bottleneck or leaves at some point.

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.

Re: The melting pot of JavaScript (2017)

#106

Post by spricket »

kangoo1707 wrote: post #71
spricket wrote: post #46

Earlier quoted context omitted.

Java uses reflection and annotations to support all kinds of language extensions. Js has a lot of nasty issues with the "prototype chain" and annotation support is still experimental. For example, in java, scanning your classes and their annotations to generate code for them at compile time is a standardized feature. Maybe I'm just complaining that JS is too dynamic, but being able to generate code at compile time wi…

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?

Java only works in classes :) . They're actually the compilation unit as well so no way around it. (Files are compiled a .class file at a time from single source files)

Adding another example, JPA MetaModel generator that allows you to make strongly typed calls in ORM.

Basically, it let's you generate code at compile time that's seamlessly integrated into the existing code. So it's generated code that still gives you IDE autocomplete support etc.

Re: The melting pot of JavaScript (2017)

#107

Post by vmware505 »

_hardwaregeek wrote: post #78
soneca wrote: post #70

Earlier quoted context omitted.

Ember is exactly that. I love it and use it on my day job and on my side-project. But overall it doesn't have much adoption and no perspective to grow anymore.

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

Re: The melting pot of JavaScript (2017)

#108

Post by undersheet »

hrabago wrote: post #23
zach43 wrote: post #11

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further

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…

I disagree. Assume you are an average coder, you should have a clue of basic JS:

1 week to learn JS latest language features

1 week to grok node, npm and the power of the JS object

1 week for React, basic stuff not redux

1 more week to dabble around

4 weeks and you should be able to be productive JS with its most important flavors. Tell me any other ecosystem where you are that fast.

Re: The melting pot of JavaScript (2017)

#109

Post by undersheet »

DLA wrote: post #104
undersheet wrote: post #36

Earlier quoted context omitted.

> cognitive load of tool options First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use. Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick. Why are people criticizing something they have never used?

My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enou…

who said that JS is for beginners?

Re: The melting pot of JavaScript (2017)

#110

Post by undersheet »

spricket wrote: post #51
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

I agree about critiques for most of those languages but not java. If you reach out to the Java ecosystem you can find libraries, frameworks, and language extensions that make it relatively easy to code in. For example, with Lombok you don't have to write any getters and setters, or catch checked exceptions. Java 11 also makes good improvements to lamdas making method chaining a lot nicer. The Java I write at work is…

Python maybe but JS not. React devs are paud higher than any Java coder.
Post reply on HN