11 ms·

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea wha

by swyx 5y ago

Julia is one of my favorite examples of learning in public as a developer. Her technical chops are unquestioned so when she says things like "I have no idea what import does" it really drives home how much the JS community has to do to bring along the rest of the developer population who just wants to make web stuff occasionally without going to JS Build Tool University. I love this and maybe it would be great for someone who works on the spec/bundlers to write a "Dear Julia" letter explaining things and giving context to specific parts on why things are the way they are, and pointing out clear ways that we as a community should try to improve.

mat0 5y ago
Mmm, this article is all you need to understand the current state of modern js: https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https://peterxjang.com/blog/modern-javascript-explained-for-...
- gkfasdfasdf 5y ago
  Good article for a beginner like myself, however since it was written in 2017 I wonder if it needs a follow up.
rob74 5y ago
My thoughts exactly! I'm mostly a backend developer and also fine with doing occasional frontend stuff as long as the build system works, but when npm croaks with one of its cryptic error messages, I wouldn't know where to begin to fix it, and that's extremely frustrating...
phist_mcgee 5y ago
Can you link which Julia you are speaking about?
- alichapman 5y ago
  The author of the article
- irishsultan 5y ago
  If you click on the link and read the header (not the actual article or it's title) you will see that it's posted on Julia Evans blog. That should answer your question.
- Griffinsauce 5y ago
  You might want to click the article link..
betageek 5y ago
I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program and build it in a way that I could host it somewhere, I'd expect to have to work at it.
- 3np 5y ago
  I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years. I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash). I have a clearer understanding of what import/require really does in most other languages. The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered. (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)
  - cube2222 5y ago
    > (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports.
    - 3np 5y ago
      Straight-forward these days indeed. https://golang.org/doc/modules/managing-dependencies#unpublished https://golang.org/doc/modules/managing-dependencies#unpubli... I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/ https://xkcd.com/1987/)
badthingfactory 5y ago
My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.
- eitland 5y ago
  I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-) Just be glad Gradle hasn't entered the JS scene yet: With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned. With Gradle however I haven't seen two similar setups so far. Edit: I might have seen two similar setups.
  - jpgvm 5y ago
    Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos. I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc. The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff where all this complex stuff just makes sense.
    - js2 5y ago
      > The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff. Android Gradle Plugin: here, hold my beer. https://developer.android.com/studio/releases/gradle-plugin?hl=bg https://developer.android.com/studio/releases/gradle-plugin?... I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a suggestion to re-run the possibly very long build with -info or -debug. At that point, instead of not having enough output, you're usually drowned in megabytes of irrelevant messages. Not a fan of all the magic behavior at all.
swyx 5y ago
fwiw here's my piece on why JS Build Tools are so churny: https://www.swyx.io/jobs-of-js-build-tools https://www.swyx.io/jobs-of-js-build-tools

by swyx 5y ago

mat0 5y ago

Mmm, this article is all you need to understand the current state of modern js: https://peterxjang.com/blog/modern-javascript-explained-for-dinosaurs.html https://peterxjang.com/blog/modern-javascript-explained-for-...

gkfasdfasdf 5y ago
Good article for a beginner like myself, however since it was written in 2017 I wonder if it needs a follow up.

rob74 5y ago

My thoughts exactly! I'm mostly a backend developer and also fine with doing occasional frontend stuff as long as the build system works, but when npm croaks with one of its cryptic error messages, I wouldn't know where to begin to fix it, and that's extremely frustrating...

phist_mcgee 5y ago

Can you link which Julia you are speaking about?

alichapman 5y ago
The author of the article
irishsultan 5y ago
If you click on the link and read the header (not the actual article or it's title) you will see that it's posted on Julia Evans blog. That should answer your question.
Griffinsauce 5y ago
You might want to click the article link..

betageek 5y ago

I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier? Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program and build it in a way that I could host it somewhere, I'd expect to have to work at it.

3np 5y ago
I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years. I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash). I have a clearer understanding of what import/require really does in most other languages. The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered. (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)
- cube2222 5y ago
  > (I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward) If I understand your point correctly, then that's a non-issue since modules are here. In the go.mod file you have the current module name, and all imports of yourself will use the current repository, instead of calling the original. So you fork the repository, but keep the original name in the go.mod file, then you don't have to modify any imports.
  - 3np 5y ago
    Straight-forward these days indeed. https://golang.org/doc/modules/managing-dependencies#unpublished https://golang.org/doc/modules/managing-dependencies#unpubli... I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/ https://xkcd.com/1987/)

badthingfactory 5y ago

My primary frustration with frontend development is that I have gone to JS Build Tool University... Roughly 10 times now. I'm not sure I've ever set up two separate frontends the same way. Even when I avoid the shiny new tools and stick with crusty slow webpack, there's a new version that behaves entirely different than the previous version. I'm enjoying the speed and simplicity of ESBuild.

eitland 5y ago
I've been poking fun at JS for a long time (friendly though, I'm consistently amazed at what those people manage to do with little more than straws and duct tape ;-) Just be glad Gradle hasn't entered the JS scene yet: With JS there is at least some standards now: both Angular and React at least has some systems for getting things running in a standard way and keeping it somewhat aligned. With Gradle however I haven't seen two similar setups so far. Edit: I might have seen two similar setups.
- jpgvm 5y ago
  Gradle is capable of very powerful things so on larger projects there is generally a project specific Gradle dialect in play and I can understand why this frustrates newcomers but it's an important capability for large projects and monorepos. I would say most small projects (especially OSS) tend to stick to a simple subset of Gradle even if it's multiproject build etc. The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff where all this complex stuff just makes sense.
  - js2 5y ago
    > The amount of churn in the JS build tool space easily outstrips any one time learning you need to do to surpass the Gradle knowledge cliff. Android Gradle Plugin: here, hold my beer. https://developer.android.com/studio/releases/gradle-plugin?hl=bg https://developer.android.com/studio/releases/gradle-plugin?... I find working with Gradle infuriating. It's layers upon layers of magic. When something breaks, you get a baroque error message, a usually useless stack trace, and a suggestion to re-run the possibly very long build with -info or -debug. At that point, instead of not having enough output, you're usually drowned in megabytes of irrelevant messages. Not a fan of all the magic behavior at all.

swyx 5y ago

fwiw here's my piece on why JS Build Tools are so churny: https://www.swyx.io/jobs-of-js-build-tools https://www.swyx.io/jobs-of-js-build-tools