Live data from Hacker News

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

lea.verou.me

101–110 of 391 posts

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

#101
post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

>I don't wanna learn how programming building blocks work as I use them to build a lil rando pile, I want to learn how they work as I use them to build the actual house I want.

Well, unfortunately some things are difficult, and knowing fundamentals helps you with those difficult tasks. I also don't complain that I can't learn to fly a plane by starting the engine with zero knowledge and learning while taking off. The author then goes on to say that in four days they learned everything they wanted to do, without any programming background, so I don't understand why these tweets are written in such a dramatic way

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

#102
post #48
post #5

Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.

But Deno is incompatible with npm, no? Deal breaker.

No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.

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

#103
I'm mostly a designer and I've been trough the same experience trying to learn the ropes of modern ES6 javascript development and this matches my experience fully.

On the same note, it took me days to wrap my head around:

- The small differences managing modules ( even simple stuff like inclusion paths using "~" vs "node_modules" vs ../node_modules" vs...) between build environments (Webpack vs Parcel vs ...) or even between different configurations for stuff like webpack and babel.

- The module format used by different libraries. Some use only the es6 module format, some use the CommonJS standard, some use both, plus a few oddball packages that are still released as global JS libraries.

- Specifically on the last one, I've yet to find a way that let you use global packages in webpack that works all the time. Sometimes you have to declare them as globals (jquery), a few other times you have to just include the js file, and in a few cases (p5.js) nothing seems to work properly. Parcel seems to require some extra plugins for this that I've never been able to configure properly.

- I've tried doing some REST requests using fetch and no matter what, It always seems that there's something completely wrong with CORS and the Access-Control-Allow-Origin parameter. I've tried using both a local dev environment and a remote host, with docker and bare metal, using nginx and apache using the required headers, with SSL certs and without. Obviously I'm doing something wrong, but it never feels like there a consistent logic in what should be the right configuration to avoid such issues. For every guide that suggests you to do X there's another that says you should be doing the opposite of X.

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

#104

We just need all this tooling to go in the browser.. which is where it always belonged. That was the purpose of JS. To "just run" in the browser. It's getting there but very slowly. As for my own rant, simply the fact that Microsoft, of all places are the ones who run TypeScript and now the proposal to add TS to native JS.. is part of the issue. MS has zero imagination. JS needs native typing and it shouldn't be done…

Who made you the arbiter of how things ought to be?

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

#105
There are learning Javascript resources targeted at non-technical people and children interested in learning how to code... one of the more promising that make it easy to start coding and experimenting with code is p5js (https://p5js.org/learn/) a Javscript port of the wonderful Processing framework... beautiful and simple APIs to start coding...

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

#106
post #88
post #63

This thread is also a good read: https://twitter.com/Aella_Girl/status/1522633160483385345 Shows that a lot of people, ESPECIALLY programmers, vastly overestimate the competence of the average person when it comes to whatever they are an expert at. You may think that this person is silly - but that is tainted by your past experience of already knowing it warping what you think the baseline average knowledge level is…

> needlessly complicated IMO this is unfair characterization. If using Photoshop is driving, programming is building an internal combustion engine vehicle. You cannot expect to just randomly google for car-making tutorials and get an SUV done in a weekend. Heck, you can't even expect to be able to build a very simple combustion engine from basic principles without a lot of study. I'm not saying this is Aella's fault…

[deleted]

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

#107
post #89

This is exactly my issue with all this modern JavaScript / Node-stuff. The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow. Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.

If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools. Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to d…

I usually do use Vue and Quasar via UMD (?) directly in the browser together with http-vue-loader, which makes it bearable and is pretty powerful as well, but then there's a lot of handpicking with libraries like dayjs (when used with plugins) or TipTap which then just doesn't scale, so you need to start to use some tooling. So you fall back to the recommended tooling and then it begins.

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

#109
post #89

This is exactly my issue with all this modern JavaScript / Node-stuff. The boilerplate just to get the simplest thing started is brutal. Now I'm dealing with some Vue3/Quasar/TipTap stuff, and I still don't know what exactly I have there, but just that it is working somehow. Python is such a pleasure to work with that I wish that all this modern web stuff were more like it.

If you try simple vanilla javascript, then you may be surprised at how pythonic it is in cerain ways - e.g. just open a browser (any browser!) and you have a javascript REPL read to go in the developer tools. Node severely complicates and confuses things, but node alone is not javascript. Vanilla JS is IMHO a very nice and expressive language, and you do not need any of the Node/Webpack/React/Vue/jquery/whatever to d…

Oh, there is another way to code with JS on the server side? Something else besides node?

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

#110

And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag. It still does today, making prototypes easy to write, training very simple, and yet, it plays well with the more complex ecosystem. Now of course, VueJS has Vite, which makes all the complexity of Webpack goes away, removes the slowness of compilation and has sane defaults. Still, npm remains. I'm now used t…

> And this is why I gave a try to VueJS in the first place. It can be deployed with npm, or a simple script tag.

This is exactly, what I noticed positively about VueJS and advertised as a good feature for integrating this specific "web component" framework into a project. You can add it as simply as one used to add jQuery to any project. However, others thought of including script tag as "not proper" (even though I told them, that in the end it would all be a script tag anyway ...) and it was decided to use another framework, which is way more complicated to integrate in any statically rendered / server side rendered and template based website.

Simply putting VueJS in a script tag is not a problem. One can cache it easily and one can use noscript tags at places in any page templates. All is fine.

Post reply on HN