esm.ah let's you include "complicated" JS that isn't usually found in CDNs.
it doesn't work for everything and imo is worse for (p)react due to the lack of native JSX, but it does allow for bringing in stuff that usually takes an `npm install && npm build`
Yeah in this case, I needed to pop up a <dialog /> and take some form info, persist it via POST and then show the result of a "used" card/token. So there just wasn't a lot of need for libraries. I'm from the VERY old school so I do recall the fresh hell of including many deps via script tags (pre-Bower!)
This is a job for a charity - you're never getting stock + bonuses + competitive pay in a third sector job. UK pay is not near US but this is probably still median SWE pay outside tech roles and London + FAANG + others will pay closer with what you're suggesting with the mentioned bonuses/stock.
I am comparing average pay in UK/US for a senior solutions architect position.
I dont understand what your comment has to do with my comparison of pay. Mind you, the comment I replied to speculated about this comparison. Hence why I provided more specifics.
I think comparing a job like this purely on salary terms misses a lot. It's a prestige job that will be the highlight of someone's CV for the rest of their career. Not to mention 25-28 days vacation.
As someone that's lived both in the US and outside of it there's no denying US salaries are top of the game. But there are a lot of other factors that go into a person's life than salary alone. Long hours in US jobs are not rare at all. I expect folks at Stonehenge are out the door at 5pm sharp.
> I think comparing a job like this purely on salary terms misses a lot.
OK maybe. But that's how the salary compares.
Please re-read the comment I replied to. He speculated about salary differences and I gave solid numbers. You are arguing against some unspoken claim that I never made (something like "more money is always better").
The point he's making is that a QR-based flow that doesn't require downloading and installing an app, and instead uses the already-installed web browser, is even lower friction and can be used by ordinary folks just as well, if not better, thanks to having fewer friction points. Requiring an installed proprietary app to manage a physical device that would otherwise be manageable via a web interface is not a net improvement to the usability or accessibility of the product. Especially if it's something you set and forget, "normies" are not going to go back to that app for a very long time and likely will forget about it. Hard requiring app setup for a router is a play to sell usage and location data, it is not looking out for those that aren't "computer people".
On one hand: A thing that requires an app for setup does not necessarily require a login to some new party's outside service; it often gets shaped that way, but it does not need to be that way.
On the other hand: A thing that requires a web browser for setup does not necessarily allow strictly-local configuration; it often gets shaped that way, but it does not have to be that way.
There's no rule or law that says that these things have to be one way or another. It's a moot distinction.
> Hard requiring app setup for a router is a play to sell usage and location data,
Speaking of moot points: It's a router. And by "router," I mean: It's a whole-ass black-box computer with some Ethernet ports, a collection of radios, and an Internet connection. If/when companies decide to be in the business of selling usage and location data, they don't need an app to do that. They can just package it up and send it forth. (Location? From wifi? Yeah, that's been a solved problem for a long time now. It was first demonstrated to me in 2008 with the OG iPod Touch, which lacked both GPS and Bluetooth, but did an amazingly-good job of delivering the beholder's location using a combination of observed wifi signals and a central database.)
---
Moving on:
I guess we can talk about things like web browsers, IP addresses, QR codes, and SSIDs, and setting up routers using our pocket supercomputers.
Old way: Fire up router, manually connect to its SSID (it used to be wide-open; these days, there's usually a password printed on a label instead), set it up with a browser, and then at the right points manually connect to the newly-configured SSID instead, and [optionally] manually go to the new address (if chosen) to continue configuration (if necessary). Manually remove the old factory SSID for cleanliness. (I cut my teeth on this method and I like it just fine, but I'm one of those computer people.)
QR+browser way: Fire up router. Connect to its SSID with a QR code. Connect to its web interface by scanning another QR code. Configure the thing. Connect to the new SSID manually (or perhaps invent a workflow to scan and use a QR code using only 1 pocket supercomputer). Optionally continue configuration by remembering the name/IP of the device, or maybe printing a QR code or something. Manually remove the old factory SSID for cleanliness. (Login to third-party server at some stage? Yeah, maybe. See above.)
App way: Fire up router. Download app using familiar processes (perhaps including a QR code). App temporarily connects to router's default SSID. User uses app to configure router. At the right times, the app automatically disconnects from the old SSID, adds the new SSID to the network list, and reconnects using the new address (if selected). Optionally, continue configuring the device using the app. (Login to third party server at some point? Yeah, maybe. Again, see above.)
A real router has no radio. It has no SSID. It routes traffic. It applies a set of ACLs to determine if traffic should be forwarded. That’s it. No switching. No WiFi. Just routing. If routes traffic on the wire.
Yes. In the purest technical sense, a router routes.
A Cisco 2501 is a router.
But words can mean more than one thing. Both in the common vernacular and in the context of these Motorola-branded devices: A router is a thing that routes, and also includes radios, and SSIDs, and switching.
reply