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

JavaScript: The Modern Parts

amontalenti.com

Post reply on HN
Print view View original

91–100 of 122 posts

Re: JavaScript: The Modern Parts

#91

Post by giancarlostoro »

WilliamEdward wrote: post #46
lol768 wrote: post #33

>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..). >What this means, however, is that to do JavaScript development “The Modern Way”, while a…

Thanks for bringing attention to WebAssembly, far from perfect but with time it could rise to become the default for front ends. Javascript's popularity was purely accidental and doesn't have to be the only option for in-built browser applications.

I tell people WASM is great but still not quite ready just yet. I think we will start to see amazing things. Even Microsofts Blazor is impresive. I cant wait to see what Python and other projects come up with in regards to WASM.

Re: JavaScript: The Modern Parts

#93

Post by dreamcompiler »

richardwhiuk wrote: post #68
lol768 wrote: post #33

>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..). >What this means, however, is that to do JavaScript development “The Modern Way”, while a…

There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.

Javascript is a frustrating language. On the one hand it's more "serious" than [legacy] C, C++, Java, and Python because it had first-class functions and real lexical closures from day one.

On the other, it had imprecise typing, no multiprocessing, and no access to the file system. Some of that has been fixed, but Javascript was designed by one person in a week to script web browsers and that's still painfully obvious.

Re: JavaScript: The Modern Parts

#94

Post by ksherlock »

blondin wrote: post #86
EdwardDiego wrote: post #84

> Yes, it has taken 20 years, but JavaScript is now just as viable a choice for your backend and CLI tooling projects as Python was in the past. Considering how often Node projects break our build, I respectfully beg to differ.

i agree with the sentiment. i was just thinking about it yesterday. what if there was a pure javascript based system programming language? with none of the event loop thingies? i mean can we have a normal javascript that compiles to a x64 binary and calls the OS?

JScript.Net compiles to .NET bytecode and has for the past 20 years or so.

Re: JavaScript: The Modern Parts

#95

Post by Zelphyr »

mariopal wrote: post #83
siempreb wrote: post #56

Earlier quoted context omitted.

> Typescript solves the biggest issue I have with using JS which is a lack of a static type system. Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly. But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong…

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__. They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve ty…

Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t.

But so many TypeScript fans act as if having types is the be-all and end-all.

And, unless I’m mistaken and something has changed recently, I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking since the compiler strips away the types after TypeScript gets compiled down to Javascript.

Don’t get me wrong; TypeScript is great. But I don’t see it as the savior that others make it out to be.

Re: JavaScript: The Modern Parts

#96

Post by ggregoire »

Figs wrote: post #24
tus88 wrote: post #2

What's the view that TypeScript is the modern Javascript?

Given how fashion-driven the web industry seems to be, my guess is that some new hotness will steal the stage from it in the next few years. I seem to recall seeing tons of posts about CoffeeScript maybe around 6~7 years ago, but it doesn't seem to be very popular any more... Maybe TypeScript will turn out to have more staying power, but my current guess is that something will happen that makes another technology --…

CoffeeScript never solved any issues tho. It was just syntactic sugar.

Re: JavaScript: The Modern Parts

#97

Post by rgoulter »

siempreb wrote: post #56
quickthrower2 wrote: post #41

Earlier quoted context omitted.

Typescript solves the biggest issue I have with using JS which is a lack of a static type system. It however does it in a very pragmatic way, giving the closest experience to Vanilla JS you could hope for. You are not learning a new language like you would be with Elm or Reason etc. It has a powerful type inference system that puts C# to shame in places, and in some places I prefer TS to C#. I don't feel like Typescr…

> Typescript solves the biggest issue I have with using JS which is a lack of a static type system. Hmm, the biggest problem with JS is types? Are you sure? I rarely had issues with types in JS. With JS I just used my trusty dynamic type checker at specific places in the codebase, and testing coverage of course even more importantly. But with TS, the codebases I see on a daily base are mostly a terrible mess of wrong…

While it's fair to say that a static type system adds friction which isn't suitable for some development mindsets, I think it's worth expanding on problems people run into with types.

Bad types at runtime: with a static type system you make the effort to be sure the code does what it says. With plain ol' JS you can get that confidence from tests. -- different trade-offs made each way.

But another benefit to static types is knowing the structure of the data you're dealing with and how to manipulate it, while you're developing/maintaining the code. -- sure: naming, unit tests, documentation etc. can help, but I find not having the static types handy makes things tricky when there's enough indirection/complexity.

As with the stuff about runtime errors, tastes vary, of course.

Re: JavaScript: The Modern Parts

#98

Post by rgoulter »

Zelphyr wrote: post #95
mariopal wrote: post #83

Earlier quoted context omitted.

The biggest problem the parent comment have with JS is not types, as you say, but __a lack of a static type system__. They are things as different as that you can actually have type problems only in a really typed system (as a static type system). Javascript has a very weak type system, and that's the problem. I think you do not understand that static typing serves to solve other problems in the code, not to solve ty…

Having a static type system is great but it’s just another tool in the toolbox. I’ve been writing Javascript for 23 years without types and didn’t miss them. They’re great when I have them in other languages but not a deal killer in languages that I don’t. But so many TypeScript fans act as if having types is the be-all and end-all. And, unless I’m mistaken and something has changed recently, I often wonder how many…

"I often wonder how many of the TypeScript proponents don’t realize that they’re mostly only getting compile time type checking"

Surely the biggest benefit from static typing is for static-analysis tooling. (e.g. strong compile-time checks).

Re: JavaScript: The Modern Parts

#99

Post by stefan_ »

richardwhiuk wrote: post #68
lol768 wrote: post #33

>Whereas Java and C users may still have debates about where, exactly, open source projects should publish their releases, that issue is settled in the JavaScript community I thought Maven Central was pretty much the canonical answer in Java land. Nobody cares what tool you actually use to pull these down (SBT, Gradle, Maven..). >What this means, however, is that to do JavaScript development “The Modern Way”, while a…

There's a bizarre, naive belief that all programming is web programming. It's patronising and inaccurate, but it's common among people who think Javascript is a serious language.

It's the same kind of people that describe themselves as "full stack" because they made JavaScript in the browser talk to JavaScript on the server, the latter running in some kind of heroku auto-container magic.

Re: JavaScript: The Modern Parts

#100

Post by vfc1 »

ericmcer wrote: post #87
vfc1 wrote: post #75

Earlier quoted context omitted.

> At a certain maturity you will need to dig into your projects build tool The command "ng build" takes in typescript and produces optimized lazy-loaded bundles, and there won't be the need to customize that, there aren't a thousand ways to produce bundles after all, there is one optimal way for a given ecosystem, and it does not make sense for each project to reinvent a build system that all it does is transpile, co…

Code splitting, live reload, things that come up like: we have some components that are using react native web, they will be imported into both web and native mobile applications, how do we prevent native sub dependencies of that component from being imported? What if you have multiple bundles but only want angular in one?

The Angular CLI has support for both code splitting and live reload out of the box. ng build creates the main bundle plus the lazy-loaded bundles, and ng serve spins up a development server with live reload ready to go.

The Angular CLI also supports multiple applications with shared components. You can build a web application that uses shared components, and a separate mobile application that uses the same shared components and has its own separate build.

The React and Vue ecosystems are going in the same direction with their CLIs, but I don't think the Vue CLI or create-react-app are quite as powerful yet.

Once they are, it will be the end of tooling fatigue, and no one will have to create their own custom build anymore (other than a shell script or so).

Post reply on HN