Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

geeves: Sep 16, 2004

Nolgthorn posted:

I've been hearing rumblings that REST is dead. That the concept in practice doesn't work very well, that no consistency exists between APIs and that it's basically a crap shoot where the only value derived from it are descriptive urls. But those urls could be replaced easily by descriptive names, in fact names could be those urls or something even more suitable.

Also a point of aggression against REST is that no protocol supports it at all except HTTP and then even methods DELETE and so on are inconsistently implemented. If you have a REST api and want a Websockets version it is flat out impossible.

People are saying a single API endpoint which accepts json GET or POST is the future.

REST is not dead and probably won't be dead for the foreseeable future. It's great for 2 completely separate servers to communicate with each other in an expected manner.

The point of an API is that the behavior is simple and expected from the documentation. Most REST APIs really only need GET or POST. PUT, PATCH, DELETE, POST are all synonymous in a way (I am oversimplifying). Because they don't mean anything unless the implementor makes them mean something. (Very few APIs I've worked with are more than GET, POST and PUT - there's a scary API I write to that deletes data with a GET call).

What you're saying is the future sounds a lot like GraphQL, which I really like the idea behind. But it's going to take a big shift to get there. And companies who have APIs probably have 100s or 1000s of clients so making a sudden switch might not always be possible.

GraphQL sounds great internally. Externally, it does as well, but there is corporate buy-in then getting all of your customers to update their knowledge base as well.

# ? Sep 10, 2017 20:19

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 22:22

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Thinking more in the realm of new apis not in upgrading old ones.

Error codes too, it seems like they aren't implemented in any kind of uniform or expected way. You can try and GET a resource that's behind authentication and if you're not authenticated you can expect any of a huge number of possible error codes. I understand there is some agreement about what you should receive but I think it'd be a lot simpler if we all admitted that it is on a per API basis, realistically. Some will return 404 some will return something else.

I'd prefer something like.

code:

{
  "type": "error",
  "error": {
    "name": "restricted",
    "message": "Resource is inaccessible."
  }
}

Where the software I'm interacting with just returns whatever error it has and I as an api developer don't need to translate the error so it matches some kind of server communication holy text. I fully understand that I sound pretty ignorant to a lot of people.

I've been building APIs for a while. I know they're not changing soon. But I also am getting disillusioned.

# ? Sep 10, 2017 22:49

ROFLburger: Jan 12, 2006

Nolgthorn posted:

Error codes too, it seems like they aren't implemented in any kind of uniform or expected way. You can try and GET a resource that's behind authentication and if you're not authenticated you can expect any of a huge number of possible error codes

That's more an implementation issue and not necessarily a shortcoming of REST though, right? I mean there's definitely a standard for what should be returned in that scenario

# ? Sep 10, 2017 23:44

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

How would an alternative to REST solve that issue?

# ? Sep 10, 2017 23:49

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

ROFLburger posted:

That's more an implementation issue and not necessarily a shortcoming of REST though, right? I mean there's definitely a standard for what should be returned in that scenario

It seems to depend who you ask.

https://docs.microsoft.com/en-us/rest/api/storageservices/common-rest-api-error-codes

https://developer.springcm.com/guides/rest-api-response-and-error-codes

https://www.fusioo.com/guide/api-status-error-codes

https://actionstep.atlassian.net/wiki/spaces/API/pages/13140251/Error+Codes

Best resource I found looked like a flow chart. I think only communication errors should return a error code, if the software is communicating correctly then just let me communicate with the software and leave the code book out of it.

# ? Sep 10, 2017 23:49

Odette: Mar 19, 2011

Honestly, I'm glad that REST APIs are around. Working with SOAP/XML endpoints was, and is a huge loving pain in the rear end.

# ? Sep 11, 2017 04:42

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Nolgthorn posted:

But I get it. These transmission frameworks are too complicated, in a perfect world I'd be able to simply run a function on a different server. The closest we can come to something so simple is a single parameter in the shape of an object.

Or, even, an array of parameters.

A single endpoint where I can just send something like
code:
{
  "transportId": 2,
  "type": "post:create",
  "content": "hi from the other server"
}
I sorta agree, there is no reason it shouldn't be about that easy. Where transport ids are sent back when the server finishes doing something.
code:
{
  "transportId": 2,
  "type": "post:created",
  "id": 209
}
An api like this could easily be translated into almost any transport protocol.

Congratulations, you've proposed RPC over HTTP.

# ? Sep 11, 2017 13:29

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Most of what we call REST isn't remotely close to REST anyway, it's just using standard HTTP semantics in developing APIs rather than shoving them into a custom request protocol.

# ? Sep 11, 2017 14:33

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

RESTfulish

# ? Sep 11, 2017 15:25

Vulture Culture: Jul 14, 2003; I was never enjoying it. I only eat it for the nutrients.

Thermopyle posted:

RESTfulish

I see you're a glass half RESTful kind of guy.

# ? Sep 11, 2017 15:44

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

I prefer Resty.

# ? Sep 11, 2017 16:51

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

edit - I may use querySelectorAll with that tag. Seems to work without errors, just hope I can work with it to grab the info.

Using Greasemonkey on YouTube. Possibly really simple problem I'm just not seeing the problem.

code:

(function() {
    'use strict';

    $("ytd-grid-video-renderer").each(function(h, d) {
        console.log('yes');
    });
})();

Says it can't find the variable "$". I even changed ytd-grid-video-renderer to div, but still errors.

LP0 ON FIRE fucked around with this message at 17:58 on Sep 11, 2017

# ? Sep 11, 2017 17:40

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Are you relying on the $ that's present in the debugger console to be present when the console isn't open (it's probably not!) or does YT actually use jQuery?

You can use https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector in place of $.

var $ = $ || document.querySelector; is good boilerplate for Grease/Tampermonkey

# ? Sep 11, 2017 18:03

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

Munkeymon posted:

Are you relying on the $ that's present in the debugger console to be present when the console isn't open (it's probably not!) or does YT actually use jQuery?

You can use https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector in place of $.

var $ = $ || document.querySelector; is good boilerplate for Grease/Tampermonkey

Thank you! Yes YT not using jQuery is probably my problem. I shouldn't just assume stuff like this.

# ? Sep 11, 2017 18:35

There Will Be Penalty: May 18, 2002; Makes a great pet!

lol if you don't always run your jQuery code in some form of var $ = jQuery;

# ? Sep 12, 2017 05:10

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

My greasemonkey boilerplate:

JavaScript code:

[...document.querySelectorAll('.your-posts')]
	.forEach(post => post.style.display = 'none')

...or chain other native Array methods in place of forEach

It's not quite

JavaScript code:

$('.your-posts').hide()

but it's close enough

Wheany fucked around with this message at 12:40 on Sep 12, 2017

# ? Sep 12, 2017 12:38

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

This jQuery talk got me thinking...I bet I haven't used jQuery in over a year!

Modern web development with transpiling and poo poo is doing some good in the world.

# ? Sep 12, 2017 14:38

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Wheany posted:

My greasemonkey boilerplate:
JavaScript code:
[...document.querySelectorAll('.your-posts')]
	.forEach(post => post.style.display = 'none')
...or chain other native Array methods in place of forEach

It's not quite
JavaScript code:
$('.your-posts').hide()
but it's close enough

yeah, querySelectorAll is what $ does in the console.

# ? Sep 12, 2017 16:00

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Thermopyle posted:

This jQuery talk got me thinking...I bet I haven't used jQuery in over a year!

Modern web development with transpiling and poo poo is doing some good in the world.

I still use it every single day at work.

And yesterday I ran into an issue where a third-party app was importing it's own (reeeeeally old) version of JQuery on some client store, so none of my code was working :cripes:

# ? Sep 12, 2017 17:22

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

I was looking taking a look at some tools today, namely Express, Sequelize, and Knex and my brain is exploding a little bit

I'm not really getting the difference between Express and an ORM. What is Express used for and what is an ORM used for? Knex is a SQL Query Builder, but it returns promises, so is it an ORM as well?

Could I build an full stack app with just react and sequelize?

teen phone cutie fucked around with this message at 23:23 on Sep 12, 2017

# ? Sep 12, 2017 23:00

reversefungi: Nov 27, 2003; Master of the high hat!

Grump posted:

I was looking taking a look at some tools today, namely Express, Sequelize, and Knex and my brain is exploding a little bit

I'm not really getting the difference between Express and an ORM. What is Express used for and what is an ORM used for? Knex is a SQL Query Builder, but it returns promises, so is it an ORM as well?

Could I build I back-end app with just React and Sequelize?

Sequelize and Knex are both ORMs. They let you interact with a database like Postgres or MySQL using straightforward JavaScript, instead of SQL.

Express is a minimal web framework. You can use it, for example, to route requests that are made from a client to a server. How do you determine what to serve when a request is sent to "/home" versus "/api/v1/users"? Express doesn't interact with the database. So, you might have an api endpoint like "api/v1/users" that Express understands. Under that registered route, you can write some code in JavaScript that leverages Sequelize/Knex to do something to a database, like create a user or find one or what not. You could also use Hapi, Koa, etc., but Express seems to be most common and is pretty straightforward to use.

React is the view layer that would be interacting with all that stuff. From React, you send HTTP requests. Express helps them easy to pull apart, then Sequelize/Knex lets you do stuff to a database based on what the request is specifying.

If you're just building a back-end API, you don't need React.

# ? Sep 12, 2017 23:20

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

The Dark Wind posted:

Sequelize and Knex are both ORMs. They let you interact with a database like Postgres or MySQL using straightforward JavaScript, instead of SQL.

Express is a minimal web framework. You can use it, for example, to route requests that are made from a client to a server. How do you determine what to serve when a request is sent to "/home" versus "/api/v1/users"? Express doesn't interact with the database. So, you might have an api endpoint like "api/v1/users" that Express understands. Under that registered route, you can write some code in JavaScript that leverages Sequelize/Knex to do something to a database, like create a user or find one or what not. You could also use Hapi, Koa, etc., but Express seems to be most common and is pretty straightforward to use.

React is the view layer that would be interacting with all that stuff. From React, you send HTTP requests. Express helps them easy to pull apart, then Sequelize/Knex lets you do stuff to a database based on what the request is specifying.

If you're just building a back-end API, you don't need React.

Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing

Why can't I run some Sequelize function on a button click and just interact with my database with just a view layer?

Sorry i just have a really bad understanding of how back-end code works

teen phone cutie fucked around with this message at 23:34 on Sep 12, 2017

# ? Sep 12, 2017 23:31

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Because that would expose your database server to the public internet.

# ? Sep 13, 2017 00:20

Kekekela: Oct 28, 2004

Thermopyle posted:

This jQuery talk got me thinking...I bet I haven't used jQuery in over a year!

Modern web development with transpiling and poo poo is doing some good in the world.

Yeah, we have a reference to it in my last big project because someone used a UI widget that required it and it looked like too much :effort:

to get it out at the time. But as far as the day to day, haven't hosed w it in a while.

# ? Sep 13, 2017 11:54

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Grump posted:

Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing

Why can't I run some Sequelize function on a button click and just interact with my database with just a view layer?

Sorry i just have a really bad understanding of how back-end code works

Because then somebody will enter

x'; DROP TABLE users; --

into your login form and you will be sad.

# ? Sep 13, 2017 15:50

ROFLburger: Jan 12, 2006

Grump posted:

Thanks for that. I guess now I'm just confused on what exactly is the point of frameworks like Express, Hapi, etc and what exactly they're doing

Why can't I run some Sequelize function on a button click and just interact with my database with just a view layer?

Sorry i just have a really bad understanding of how back-end code works

Anyone with access to that view layer would be able to run whatever queries they want - delete your blog posts, change the pictures to goatse, whatever. The backend sits between the front end and the database and is the arbiter of business logic that you wouldn't want the frontend to be in control of. Sure, the frontend can enforce whatever behavior you want, but it is ultimately useless against someone with dev tools and a rest client. So two of the biggest reasons, among plenty of others, would be security and application logic.

# ? Sep 13, 2017 20:31

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I stopped making web apps long ago, I just set up a user facing phpmyadmin and it's practically the same thing.

# ? Sep 14, 2017 18:15

Dominoes: Sep 20, 2007

Thermopyle posted:

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

Trip report: None of the things here I've tried work in Typescript. Ie 'Property find does not exist on type 'number[]'. Same with includes etc.

# ? Sep 16, 2017 01:16

Dogcow: Jun 21, 2005

Dominoes posted:

Trip report: None of the things here I've tried work in Typescript. Ie 'Property find does not exist on type 'number[]'. Same with includes etc.

You have to specify that when running (or whatever you're using to run) TypeScript, specifically you want this:

code:

--target "ES6"

option: https://www.typescriptlang.org/docs/handbook/compiler-options.html

As you're likely not running the TS binary directly, post your Webpack config (or whatever you're using to run TypeScript).

# ? Sep 16, 2017 02:13

Dominoes: Sep 20, 2007

IIRC that will make it not work on browsers that don't support ES6. Is that correct?

JavaScript code:

module.exports = {
    entry: {
        schedule: "./pucks/static/src/schedule.tsx",
        week_schedule: "./pucks/static/src/week_schedule.tsx",
        quals: "./pucks/static/src/quals.ts",
        inputs: "./pucks/static/src/inputs.tsx",
        ground_training: "./pucks/static/src/ground_training.ts",
        upgrades: "./pucks/static/src/upgrades.ts",
        rap: "./pucks/static/src/rap.ts",
        me: "./pucks/static/src/me.ts"
    },
    output: {
        filename: "[name].js",
        path: __dirname + "/pucks/static/dist"
    },

    // Enable sourcemaps for debugging webpack's output.
    devtool: "source-map",

    resolve: {
        // Add '.ts' and '.tsx' as resolvable extensions.
        extensions: [".ts", ".tsx", ".js", ".json", ".d.ts"]
    },

    module: {
        rules: [
            // All files with a '.ts' or '.tsx' extension will be handled by 'awesome-typescript-loader'.
            { test: /\.tsx?$/, loader: "awesome-typescript-loader" },

            // All output '.js' files will have any sourcemaps re-processed by 'source-map-loader'.
            { enforce: "pre", test: /\.js$/, loader: "source-map-loader" }
        ]
    },

    // When importing a module whose path matches one of the following, just
    // assume a corresponding global variable exists and use that instead.
    // This is important because it allows us to avoid bundling all of our
    // dependencies, which allows browsers to cache those libraries between builds.
    externals: {
        "react": "React",
        "react-dom": "ReactDOM"
    }
}


// commented out in package.json post run..
// "postinstall": "../../node_modules/webpack/bin/webpack.js"
//    "webpack": "node_modules/webpack/bin/webpack.js --progress --colors --watch"

# ? Sep 16, 2017 02:35

Dogcow: Jun 21, 2005

Yes, you need a "shim" (just a library that implements ES6 features in older JS) like "es6 shim": https://github.com/paulmillr/es6-shim

For configuring TypeScript the awesome-typescript-loader docs say to add a tsconfig.json file. Put it in the same directory as your webpack config, and you shouldn't need any of the options for the loader itself, just add the "target" thing to "compilerOptions": https://github.com/s-panferov/awesome-typescript-loader/blob/master/README.md

# ? Sep 16, 2017 02:47

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I think Typescript is the best thing to happen to Javascript since ES2015 but lately they've been letting me down with the part of it that really mattered to me which was client side compilation. It can compile to ES5 but it cannot compile to a single file.

It used to be able to. That functionality has languished and now you need a second compilation step in order to get the code where it needs to be.

I was using Rollup to do that which was annoying but still manageable. Now that I see support for Vue, or just about anything which isn't Angular falling by the wayside I've had to stop using Typescript. Which is such a shame because it was one of my favourite tools for a long time.

# ? Sep 16, 2017 14:56

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Thermopyle posted:

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

Still no ES6 alternative for `pick`... ?

code:

function pick (obj, ...keys) {
    const result = {};
    for (const key of keys) {
        result[key] = obj[key];
    }
    return result;
}

# ? Sep 16, 2017 15:04

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Nolgthorn posted:

I think Typescript is the best thing to happen to Javascript since ES2015 but lately they've been letting me down with the part of it that really mattered to me which was client side compilation. It can compile to ES5 but it cannot compile to a single file.

It used to be able to. That functionality has languished and now you need a second compilation step in order to get the code where it needs to be.

I was using Rollup to do that which was annoying but still manageable. Now that I see support for Vue, or just about anything which isn't Angular falling by the wayside I've had to stop using Typescript. Which is such a shame because it was one of my favourite tools for a long time.

How is client side compilation a deal breaker? There are a ton of industry standard tools for bundling files, TypeScript shouldn't be trying to do their own.

# ? Sep 17, 2017 04:26

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

All that s TypeScript chat made me wonder: has anyone used Flow? I've never used either, but sometime soon I want to get type checking going on at work.

# ? Sep 17, 2017 05:23

mystes: May 31, 2006

Lumpy posted:

All that s TypeScript chat made me wonder: has anyone used Flow? I've never used either, but sometime soon I want to get type checking going on at work.

Isn't TypeScript pretty clearly winning? Why use Flow now?

# ? Sep 17, 2017 14:30

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Skandranon posted:

How is client side compilation a deal breaker? There are a ton of industry standard tools for bundling files, TypeScript shouldn't be trying to do their own.

Because Typescript is a compiler. You only need another compiler if you wanna do client side compilation, something it used to do and used to do a lot better than Browserify or Webpack. "Industry standard" doesn't generally describe technologies that are only a couple of years old, as well.

# ? Sep 17, 2017 20:58

lunar detritus: May 6, 2009

Nolgthorn posted:

Because Typescript is a compiler. You only need another compiler if you wanna do client side compilation, something it used to do and used to do a lot better than Browserify or Webpack. "Industry standard" doesn't generally describe technologies that are only a couple of years old, as well.

Is there any tool in the frontend side of things that actually qualifies for your definition of "industry standard"?

# ? Sep 18, 2017 00:18

reversefungi: Nov 27, 2003; Master of the high hat!

gmq posted:

Is there any tool in the frontend side of things that actually qualifies for your definition of "industry standard"?

...the browser? :q:

# ? Sep 18, 2017 01:59

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 22:22

the talent deficit: Dec 20, 2003; self-deprecation is a very british trait, and problems can arise when the british attempt to do so with a foreign culture

Nolgthorn posted:

I've been hearing rumblings that REST is dead. That the concept in practice doesn't work very well, that no consistency exists between APIs and that it's basically a crap shoot where the only value derived from it are descriptive urls. But those urls could be replaced easily by descriptive names, in fact names could be those urls or something even more suitable.

Also a point of aggression against REST is that no protocol supports it at all except HTTP and then even methods DELETE and so on are inconsistently implemented. If you have a REST api and want a Websockets version it is flat out impossible.

People are saying a single API endpoint which accepts json GET or POST is the future.

i'm not going to argue that 'REST' apis in the wild aren't generally tremendously bad, but i don't think there's any other superior protocol out there to replace it. REST, done properly, has a ton going for it that is a lot of work to replicated

for one, it's use of http as a protocol means it's instantly cacheable and proxyable. for another, it's human readable so you can poke and prod and experiment with an api with standard tools like curl or a browser. third, it wasn't so much designed as discovered as having evolved in the wild. a REST api is just a webpage, really, altho instead of serving html you serve json or xml or whatever. i think that's the part everyone misses about the roy fielding thesis. he wasn't designing a new way to write apis he was describing what was and still is the most successful protocol in history, the world wide web

can you replace it with something like graphql or soap or json-rpc or gRPC? yeah, you can. should you? maybe. if your api is an internal thing that has limited functionality and you want strict client/server interaction with all your types and message flows designed up front you probably don't need REST and you're better served by json-rpc or gRPC. however, if your API needs to talk to multiple clients not all of which are controlled by you and you have multiple consumers that might have very different needs, REST is probably the most flexible way to deliver just that

# ? Sep 18, 2017 06:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »