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

Today’s JavaScript, from an outsider’s perspective (2020)

lea.verou.me

Post reply on HN
Print view View original

381–390 of 391 posts

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#381

Post by mbrodersen »

elorant wrote: post #165
alexb_ wrote: post #72

Earlier quoted context omitted.

Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest…

Or you just ignore all the shiny new things and go with older technologies that work like a charm. I for one, still write code in jQuery, and don't plan to switch at least for the next five years.

Yep exactly right. Do as much as you can with plain HTML, CSS and JavaScript. Learn the basics without depending on any packages. And only then maybe add a package if it really absolutely is worth it compared with writing a bit of extra stuff yourself. Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#382

Post by mbrodersen »

Here is what I did when I had to create a fairly complicated web application with no prior experience in web development (but 20+ years of developer experience in other environments): I started by learning the basics: HTML, CSS and JavaScript. Without relying on any build systems or packages. And only then adding a build step or package if it really absolutely was worth it compared with writing a bit of extra code myself. It worked like a charm. I completed the project in a few months with very few dependencies. And the build “system” was simple. Which should be kinda obvious when you think about it: Every build system or package you rely on will become a liability and a major pain point down the road. Guaranteed. So the less you rely on external tools/packages, the more stable your code will be. And the more you understand the basics, the more you are able to fix problems with code you didn’t write yourself. The downside of course is that you have to invest more heavily in the basics (HTML,CSS,JS) but that is a good thing. The time you spend becoming an expert in fashionable build tool X or package Y is a waste of time. Something else will be more fashionable tomorrow so your hard earned expertise is wasted. It is a bad investment compared with deeply understanding the foundation (HTML,CSS,JS).

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#383

Post by MCArth »

an1sotropy wrote: post #222
MCArth wrote: post #49

Earlier quoted context omitted.

I completely disagree with this as someone who's spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export on…

You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here: Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#384

Post by MCArth »

an1sotropy wrote: post #67
MCArth wrote: post #52

I've spent a significant number of hours bashing my head against the same issue and reading tons of GitHub issue threads It seems to come down to the es module spec being half baked so that it's not possible to implement them in a backward compatible way with the rest of the nodejs ecosystem I'm not sure what the solution is, but I no longer use any packages which export only an es module.

Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? Sure the interoperability between things that do and do not (pure ES6) require a build/bundle/whatever, and between JavaScript and TypeScript may remain an engineering challenge, but that's not for the ES6 modules spec to solve, right? [1]…

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. Backwards compatibility is a serious concern.

It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#385

Post by divan »

kaba0 wrote: post #377
divan wrote: post #54

Earlier quoted context omitted.

I recently had to work on a library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18) It just worked. And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off. I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly. That was as…

I don’t think it is that impressive, though I have the most experience with Java, where a fat jar on a random, obsolete website displaying some university material will just work.

To make your comparison with fat jars closer to the point, imagine you got the source code from the owner of that old obsolete website, and need to use it in your newest Java project, with the bleeding version of Java, gradle and all the stuff.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#386

Post by throwaway675309 »

jquery_dev wrote: post #123
alexb_ wrote: post #72

Earlier quoted context omitted.

Was going to edit this in but it quickly turned into a related rant about the state of things: if you don't want that, scroll past. The real problem is that there's no more room for the technological "middle class". We've gotten to the point where you cannot be SLIGHTLY interested in computers, want to make a quick app for yourself, or make something small to share with the world. You either have to have no interest…

I've started programming around 10 year ago without any Visual Basic code. There are so many more resources nowadays to get started programming, back in the day there was no way in hell you'd get something like repl.it where you don't even need to install anything. What stops you from creating the most simple html page and playing with CSS? That counts as programming to me, there's also scratch for people who are com…

Maybe but it depends on what you mean by "back in the day". Because back in the day a lot of computers came preinstalled with some version of a BASIC interpreter, And some machines literally booted into basic by default, so programming became just a natural extension of the users daily computing process.

However, If you're referring to 2012 as back in the day, visual basic was by far and away completely deprecated by that point, if anything people would've been using Visual Studio community edition to do net programming and maybe visualbasic.net

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#387

Post by an1sotropy »

MCArth wrote: post #383
an1sotropy wrote: post #222

Earlier quoted context omitted.

You made a similar comment elsewhere about ES6 being "half-baked", and I'll ask my question again here: Can you explain more what is half-baked about ES6 modules? To me the logic and syntax of how imports [1] and exports [2] are organized seems clean, but maybe I'm missing something? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I agree, if we had all started with it, it is nice. But it completely breaks backwards compatibility with the whole existing node.js ecosystem, costing countless developer hours. It seems very likely to me a solution could have been found that would allow node to support the combination of esm and cjs.

ok, that makes sense (and sorry for making you answer twice). But I think sometimes a clean break is a necessary part of progress.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#388

Post by btbuildem »

hudo wrote: post #81

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tuto…

The best part: all of the utils in the tool chains "evolve" and so your one script has to be regularly modified and kept up to date. A project that "just worked" but has been on ice for several months, will now not even build after you pull updates etc. It's infuriating. I used to work on a front-end team, and a good 20% of our time was spent babying the build chain, I kid you not.

Re: Today’s JavaScript, from an outsider’s perspective (2020)

#389

Post by iamsaitam »

blenderdt wrote: post #186
hudo wrote: post #81

My experience also. As a backend engineer trying to create a front end app, the whole toolchain of JS, bundlers, minifiers, Typescript, React... is basically; works if you have one magical init script that wires up everything, and much more than you really need since its tailored for more complex apps, but if you need just simplest thing, like run Typescript app in browser, well, good luck with that! Hundreds of tuto…

Not only this. Try to change the app two years later. Dependencies gone, wrong NPM version, Webpack config depricated and what not. That's why I like to use vanilla JS as much as possible. It will be maintainable years later.

Yes, if you don't fix your dependencies. But that will happen in any language.
Post reply on HN