|
I'm trying to use JavaScript to scrape a page (specifically, the unread list of articles for a logged-in user on instapaper.com), and I'm having an issue parsing the downloaded page. I used XMLHttpRequest to get it as a string. I've checked by outputting to the JavaScript console, and it does download the whole document. However, when I convert the string into XML, it stops parsing partway through the document. The source for the page is here, and it stops parsing at line 58 (i.e. the last line parsed is 57). Is there a reason that would make it stop I'm missing? edit: nevermind, just had to replace the &'s with "[ampersand]amp;"s (the forum automatically does that so I can't say it as usual but yeah  )
abraham linksys fucked around with this message at 06:34 on Dec 19, 2010 |
#
¿
Dec 19, 2010 06:10
|
|
|
|
| # ¿ May 10, 2024 04:57 |
|
|
I mean, java script: The Good Parts (http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/) is basically the K&R of JavaScript. It's slim, teaches you best practices in a language full of bad ones, and barely even touches on the DOM (i.e. browser scripting). From there, you'll have to find your own book for learning Node (not that there's a ton to learn, once you figure out events and callbacks), but that's what I'd use for learning JS, especially if you're coming from another language.
|
|
#
¿
Oct 6, 2012 00:17
|
|
|
Plorkyeran posted:Are there even any other realistic options? Mocha+Chai+Sinon seems to be what everyone uses.  JQuery and Ember.js both use QUnit to great success! Though you can of course use QUnit with Chai+Sinon too.I've also seen Jasmine used... somewhere? It's definitely used in places that I cannot remember at the moment.
|
|
#
¿
Aug 25, 2013 05:22
|
|
|
NtotheTC posted:I'm not familiar with how validation works in the case of a .js framework. If you're using ember.js say to do validation on the client side in the browser, and the user has control of their browser, what's to stop them bypassing your validation and getting malicious data into the (now completely un-validated) dumb REST backend? You don't use a completely dumb REST backend. You use server-side validations as usual. For example, Firebase has a security rules DSL to do validation/authorization with minimal overhead: https://www.firebase.com/docs/security/security-rules.html
|
|
#
¿
Sep 2, 2013 19:01
|
|
|
Chenghiz posted:What kind of web apps do you guys use MVCs for? http://noted.herokuapp.com/ this is an app I made to learn Ember. It made it easy to architect it like a desktop app - everything is just magically wired together. Sometimes the magic breaks horribly, but it's good until then. Currently, I'm using Ember to work on a big ol' table-based admin panel with sorting/filtering/pagination/etc. Ember's made it easy to structure all of this in general ways, and lessened the amount of explicit wiring up of components. At the same time, it's harder to write abstracted magic than a bunch of manual boilerplate, so I don't know if I'm really doing it any faster. Sure as hell having more fun doing it, though. I use Angular occasionally, too. I made this in it, which is just directives, but I used it more fully at work for a while. If nothing else, directives are awesome. A general personal rule of thumb is that if the project doesn't involve client side routing, Angular is a good choice. Ember's router is incredibly robust, and makes it easy to make real, URL-driven web apps, whereas I've heard nothing but horror stories about Angular's routers (yes, plural - there's a built-in one and ui-router, which is supposed to be better). Still, the lack of a separate data layer (just $.ajax your poo poo into $scope, no model definitions required) and the lack of required build tooling (unlike Ember, which really needs template compilation among other things) make it easy to integrate into existing, primarily server-side projects. And use Backbone if you hate yourself or if you're really against the concept of opinionated libraries. The only happy Backbone users I know have developed their own libraries on top of it. I've been interviewing at a company that uses it with their own, custom-developed view layer, which just seems to me to do the same poo poo Angular directives or Ember views/components do out of the box. Backbone is seriously the worst of both worlds. I've been thinking of making a "bleeding-edge front-end development" thread, covering stuff like JS MVC frameworks, build tools, etc. abraham linksys fucked around with this message at 07:09 on Sep 17, 2013 |
|
#
¿
Sep 17, 2013 07:05
|
|
|
FeloniousDrunk posted:I have this idea festering, but it needs me to write javascript that generates javascript. Is there anything that would facilitate such a thing, or am I looking at a lot of escaping and string concatenation? escodegen is pretty rad.
|
|
#
¿
Sep 17, 2013 07:32
|
|
|
I wrote a thread about modern front-end development! It is here.
|
|
#
¿
Sep 19, 2013 20:47
|
|
|
MrMoo posted:Has anyone been able to mock a simple function with TS-Node and NodeJS v20s Test Runner? I cannot believe this poo poo doesn't work. Classes and objects are fine, but not possible with functions. "esmock" almost works but generally not great. it just kinda looks like node:test doesn't have any functionality for mocking module imports at the moment: https://github.com/orgs/nodejs/discussions/47959
|
|
#
¿
Sep 30, 2023 15:42
|
|
|
i figure module import mocking is probably not something the average node codebase has and i get why they didn't implement it for v0 of this extremely new thing (node:test isn't even in the LTS version without a feature flag, is it?)
|
|
#
¿
Sep 30, 2023 16:01
|
|
|
MrMoo posted:Unit tests are all about units, so defining units and mocking the interfaces is a rather fundamental aspect. sure, but those methods can actually be passed to the functions that use them as arguments, the most basic form of dependency injection. common in javascript and swift and lotta other languages. i always do this with api clients and stuff; no reason to mock import axios 'from 'axios' when you can create a mock apiClient and pass that as the first argument to fetchMyThings(apiClient) and, yknow, plenty of languages don't have the ability to mock imports at all and have done fine with actual dependency injection, java and c# and whatnot. different pattern but does happen in node or browser code, i know nestjs has it and if you squint a lot of frontend frameworks have something that kind of looks like it (i have totally used react contexts for this) I'm kinda ragging on you, and from poking at github issues it looks like module import mocking is something the implementer of this feature is planning on adding (it requires some esm loader stuff that isn't done yet in node), they just figured it wasn't worth blocking shipping on given the api is stable. in the meantime, jest exists!
|
|
#
¿
Oct 2, 2023 00:07
|
|
|
There's like five threads I could ask this in, but I figure this one's at least more appropriate than the frontend thread: what's the deal with TypeScript and HTTP frameworks these days? We have a "BFF" service at work, written in TypeScript. This service just has a bunch of endpoints that make calls to our backend services and return formatted data for the clients to use. The backend services are Java/Kotlin/Python and we use a mixture of gRPC and HTTP calls to them (mostly HTTP right now, eventually more gRPC). The clients are a couple web apps and a mobile app. This service was initially written using plain ol' Express by a bunch of mobile devs who did not actually understand how TypeScript worked*. This lead to a few issues: 1. The request values for a lot of endpoints are not typed or validated. There's a lot of req.query, req.body, and req.params access that is completely untyped. Even when these are typed, they're usually not actually runtime-validated, since apparently no one who worked on this service before me understood that TypeScript types do not exist at runtime. 2. Only some of the response values for endpoints are typed, because you can just res.send(whatever the hell you want) in Express. Some of our endpoints have Swagger-via-JSDoc annotations, but these are usually horrendously inaccurate or at minimum out-of-date and missing things. 3. None of our HTTP calls to backend services have any kind of runtime validation that the responses for those calls match what the BFF (and downstream consumers) theoretically are expecting. A couple years ago, another developer added tsoa to try to solve (1) and (2). We've incrementally adopted this and it mostly works. It's annoying to have an extra compile step, and a dependency on legacy decorators, but we've set it up so that it auto rebuilds in dev and works as expected. This year, I decided I finally wanted to take a crack at (3). We'd solved this in one of our frontends that use TypeScript using zod for validation. This immediately exploded because tsoa can't generate using zod's infer type, meaning that any time one of BFF's endpoints directly return an object from a backend service (which is often!), we'd have to manually define both the zod schema and a TypeScript type that tsoa can handle. I really don't want to do this! I think it's also a tough sell to my coworkers! Honestly it's not that much boilerplate but it's enough I know I'm gonna get pushback. So I'm wondering... what else is out there? Should we be using, for example, NestJS to have typed endpoints without this weird compile step? I know you can use NestJS's Swagger system with zod using zod-nestjs, so it's at the top of my list, but I'm sure there's other options. Anything we can adopt incrementally in an existing Express app is best - we have enough endpoints that doing one wide switch is going to be hard. For now, I've actually still been converting our legacy endpoints to tsoa just so that we have a common base, but also trying to split up some of the endpoints that have a bunch of logic in the route handler so that they have separate business logic modules, and making sure nothing is using the req/res objects directly so that we shouldn't need to adapt that logic for a new HTTP framework. * the issue here is not "mobile devs bad," it's that they assumed that TypeScript worked like Swift or Kotlin types, and trying to explain to them that "no, the as operator does not actually do anything at runtime" got a lot of surprised reactions
|
|
#
¿
Jan 10, 2024 02:34
|
|
|
Harriet Carker posted:I started a new job recently. The most senior frontend guy is vehemently opposed to TypeScript for reasons I don't quite understand (understanding these reasons is obviously step 1). He put up a ton of resistance when I mentioned introducing it, claiming it's too full of quirks. I don't feel like rocking the boat too much since I'm new but curious if anyone had heard any particularly convincing reasons to not use TS in a modern React app. I've been using it for about 5 years and going back to plain JS feels awful so far. i've heard "typescript is quirky" mean two different things: 1. typescript will limit your technology choices to things that integrate well with typescript. sometimes this means adding additional dependencies to your project that can be quirky in their own ways. a good example of this was how vue 2 relied on an extremely janky third-party vscode plugin to get any kind of useful typing, and it was a pretty miserable experience if you didn't get it set up just-right. another common example is how vanilla redux and a lot of libraries and patterns from early react/redux don't play well with typescript because they can't be easily typed (this is why our old react codebase at my employer isn't typed, we don't have bandwidth to make the massive switch to redux-toolkit or whatever). you also might have trouble setting up typescript in your build pipeline, jest configuration, etc etc that said, in the context of a "modern React app," you should be able to adopt typescript relatively easily. the build pipeline stuff is a lot easier now, especially if you're using a framework like next or remix. might be worth asking if he has specific concerns around specific libraries or patterns that don't play nice with typescript 2. typescript requires understanding of type systems in general, which a lot of frontend engineers don't have! you can pick a lot up by cargo-culting, but i've seen feature branches get stuck because an engineer couldn't figure out how to type something well and was too embarrassed to commit something with an `any` type (or scared off by the linter yelling at them about it). it's also a really loving advanced type system, and i've seen engineers (such as myself) fall down rabbit holes of trying to type things "elegantly" without boilerplate, and before you know it you've got 20 open stack overflow tabs about conditional typing and you've written 20 lines of type annotations that don't actually do anything but let you save a bit of copy-pasting. i've also heard typescript described as "quirky" by backend devs because of the lack of type soundness (after all, it is an erased types system), and i have definitely had that problem myself (see my giant post above yours about zod and tsoa and runtime validation ). i think that can really turn people off, because they get this idea in their head that if a type system isn't "perfect" then that makes it useless.
|
|
#
¿
Jan 18, 2024 03:13
|
|
|
tbh that's not even a quirk of typescript as much as native ESM having the most awkward rollout of all time across every single runtime and bundler our one node typescript service is still using "module": "CommonJS", and thankfully our react+typescript project just uses NextJS which configures the bundler part for us
|
|
#
¿
Jan 18, 2024 21:40
|
|
|
|
| # ¿ May 10, 2024 04:57 |
|
|
I just had coffee so I'm going to write too many words here:fuf posted:A lot of the stuff I'm looking at, like https://www.digitalocean.com/products/app-platform, assumes that you want to pull from a github repo and then run the build process on the production server itself, but I'm struggling to see why this is an advantage. DO App Platform is a Heroku-like. It uses "buildpacks," which are a spec for how to build an application's source into an image that can be deployed somewhere (probably an OCI/Docker image under the hood). Heroku's buildpacks became a spec (https://buildpacks.io/) over the past five or six years and now a few different platforms support it. It's... relatively antiquated, I guess. It made more sense in a pre-Docker world. Now, at the end of the day, it's just generating a Docker image, there's no reason a developer couldn't just write their own Dockerfile instead. But for a single-service project that doesn't use Docker in any other parts of its development process, it can be nice to avoid having the overhead of setting up a Dockerfile and testing it out for production. That said, App Platform also just supports Docker images for builds, which I think is true of most hosted services that support buildpacks in 2024. Now in terms of "why your build runs on App Platform:" generally it is best-practice for production applications to not be built on a developer's local computer. None of the reasons for this are really going to matter for your personal project, but collaborative projects usually have some degree of logging and security around builds and deploys. Plus, you don't want your application to build differently between different developer machines and then have problems in production that can't be replicated easily. I do want to note that the builds do not run in the "production server." There is a separate build environment, because it's gonna output that Docker image, and that's your "production server." BTW, other competitors in this space: Heroku (probably not a good choice in 2024), AWS Elastic Beanstalk (ditto), GCP App Engine (extremely ditto), Azure App Service (not sure anyone has ever used this), Render (actually pretty awesome though I don't expect them to stick around long, someone will buy them). quote:If I run "npm run build" locally then what I end up with in the /build folder is just a static site that I can host anywhere, right? It feels easier to just deploy that folder directly to a basic hosting server running nginx, or even a crappy shared hosting package, compared to a server running a node build process. So, the punchline is that everything I just typed above is kind of irrelevant for your use case because you have a static site. You can absolutely put static sites wherever the hell you want. My personal website is the cheapest DigitalOcean VPS, a Caddy server (re: hipster Nginx), and some files in ~/www that I just scp up there whenever I feel like making changes to it. Now, there are some managed static site hosting solutions that are pretty nice. You've already settled on GitHub Pages from the sound of it and, yeah, you should probably just use that, it's super effective. The fancier managed solutions will get you cloud builds for your static assets (again, not really relevant for a personal project) as well as some fancy vendor-specific tools they'll try to lock you in to keep you from realizing that all they're doing is offering S3 and CloudFront at a 1000% markup. Products in this space include Netlify Core and Vercel Frontend Cloud, which I mention really just because they have pretty generous free tiers (for now). fuf posted:It seems good but when I point it at my create-react-app repository, it says: This is because the buildpack system sees that there's a package.json there and just assumes it is a Node server that it should run; it's not built to just serve static assets. You could stick a static server in there and have it host those files, but that would be pretty silly compared to using a static site host.
|
|
#
¿
Jan 27, 2024 19:07
|
|
