I get so much Temu spam that I finally gave up and decided to check them up. I compared 3 random items that the spam in Instagram was about - exact same items were 3x - 10x cheaper on AliExpress than Temu (~0.50 on Ali, ~5.0 on Temu, ~10 on Amazon). I haven't looked further but my impression was that they just ship stuff from AliExpress with a X price multiplier?
Anything where you're actually ok with all the NEUVWY branded junk on Amazon but want it much cheaper in exchange for possibly slightly slower delivery and a horrible browsing experience.
Or free if you're willing to put up with REALLY slower delivery. I ordered a 20kmAH battery with fold out solar panels off wish. 4 months later with it undelivered and tracking no longer active I requested and got a full refund. Two months later it finally arrived having gone the long way around the planet and held by Azerbaijani customs for several months.
did that with a showerhead, $80 on amazon, $30 on aliexpress, and it's actually quite well made (real metal) and seems to be great so far after a year. I'm sure there are a lot of duds though and it's caveat emptor, do at least a little research if you can find anything.
A 16" 4K USB-C OLED display (with a touch sensor even). It works exactly as advertised and looks really nice but is rather useless for me, to be honest.
It's https://aliexpress.com/item/1005004110616192.html
I think a regular IPS display would be way less susceptible to burn-in when used as a dashboard display, though.
As for why I don't use it much: I thought it would be nice to have a second portable screen for my laptop instead of a proper desktop setup, but it's just mildly inconvenient to carry around and set up/pack away every time, and it offers way less usable screen area than a regular-sized display (unsurprisingly).
My experience with keyboard components on Amazon in Canada is that they’re beyond prohibitively expensive. It’s absolutely insane. I could never wrap my head around why… Who’s buying it? I suppose impulse purchases because so many of them are hard to find otherwise, or you have to wait a while for batches?
There's a ton of amazon.com stuff machine-reposted on amazon.ca (plus a $$$ Fedex/UPS fee to get it to you quickly after they receive it themselves in USA).
I fond them to have the same prices and mostly the same items but temu often doesnt have the really nice version of a thing thats basically from a “brand” in china
I find myself thinking this as well. I love the idea of this for a few reasons, but there appear to be some hang ups that would cause me to go back to typescript, jsx, and a node process serving it.
The developer experience is ridiculously nice in that ecosystem if you’re accustomed to it. So many QOL things have been dealt with and polished.
But I do love the idea of something like that dev experience with Go instead of JavaScript powering it.
Maybe this would be totally sufficient if you don’t want any SPA/interactivity features?
Some sort of live pipe to component state like LiveView or similar could make it so a lot of JS would work implicitly, which might give a lot of the dev experience and user experience ease that people want. I’m not sure. But I do think something would often be missing with this library.
Regardless, I love the idea and I’d be stoked to see it grow and improve the developer experience.
With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it.
The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc.
The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start.
You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.
Certainly. I never meant to say "my javascript strategy is X and its the best fit everywhere'. As always "it depends".
Though, the simple idea of server-side rendered HTML that is enhanced with JS goes a very long way.
> or you manually sync your state into and out of the DOM, and other things like the URL etc.
The thing is: with server-side-rendered HTML, the issue of "State" is solved! Hypermedia is a state-machine (REST, HATEOAS etc). What is left, is "state" needed for rendering some variations.
You don't need to store state of routers, or the state of JSON objects being pushed through immutable-redux-saga-whatevers. All you need is some state to determine "the accordeon is closed" or "the dropdown is open".
I've applied my strategy to a client-side search system once. And while it worked, it quickly showed that actual state-management was needed. I used the URL/history-api to store all state - so that links where sharable, but there's only so much you can put into paths, query strings and anchors. I used HTML5 template tags for templates and components and some simple JS to fetch JSON from a search-backend and pull that through the template to insert into the DOM.
What I'm saying is: yes! I agree. You'll need proper and nice design patters or architectures to build a UI of any scale. But I'm also saying: if you move state-management to REST (the backend, server-side-rendered) what you are left with is simple enough that it needs no framework most of the time.
Yeah, I mean stuff you can't or won't put into the client-server communication. At some level of detail it becomes wasteful.
For example a multi-step form, where you can browse for options, have a lot of filters such as logic that displays different options based on previously selected ones and so on.
It's not that you can't do it via HTTP. But it's also wasteful. For this kind of stuff you don't need to pay for the round-trips. The server doesn't need to know anything about the UI state here. The only transactional parts are the entry point and the final result.
Things like these are a great place for "interactive islands". You can architect the skeleton and all the actually transactional parts as a normal HTTP/REST site, that exchanges HTML and so on. But for the parts that are really _just_ UI related state like the above, it's unnecessary work (compute/complexity/networking) to do so. Other examples include: interactive visualizations via SVG/WebGL, rich text editing and so on. All of those things are relatively common things.
What I was getting at above, is that it will get messy if you have JS state like that and but you don't write it in a way where the JS "owns" the DOM, from start to finish, for that component or island. It doesn't have to be react/redux or w/e. There are simpler, more performant solutions that lean on web standards and are much lighter weight like Lit etc.
> The server doesn't need to know anything about the UI state here.
As always: "it depends". I've built many use-cases where the server did really need to know about this. When we needed the intermediate state to be stored so that a user could pick up where she left. Or when we needed the telemetry/events of intermediate states being sent (e.g. "your ticket is now reserved for 45 minutes please proceed to payment") and so on.
What's more, and more important though, is that no:
> But it's also wasteful.
It is hardly wasteful. Hell, your "ga.js" HTTP call is probably heavier than doing a simple call to proceed the state-machine over HTTP. HTTP certainly isn't the problem: most likely the choice of a bulky and sluggish backend language/framework is, though.
I think JS is fine for some UI sugar, but the app should be usable even with JS off. What you are talking about is indeed better accomplished with an SPA.
While "it must be usable with JS off" was true decades ago for accessability and compatibility reasons, this isn't the case anymore.
In my case, the reason for changing and not creating the DOM with JS is pure simplicity. I'll just as gladly make something that won't work, because it cannot be changed this way. Because everyone except for a very few "mormons of the internet" have JS. Modern JS even.
I agree. I use server-side rendering heavily in my projects at work and thus largely avoid custom Javascript (edit: the reason is laziness, not because I outright disliked Javascript). But if I want to enable some very basic user interactivity that does not alter "state" in any way, I will always go for a few lines of JS that e.g. toggles the visibility of some items when a button is clicked etc.
So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework).
For the time being this approach works very well for me.
reply