|
In order to play a video file you need to know things like "how many pixels are in each frame", "what encoder is being used" etc., which is stored in header fields at the start of the file. You can't just jump into the middle of the file and start playing unless you already know what those values are. Also, if you're just naively splitting this file every X megabytes, you're likely in a situation where neither segment has all the bytes needed to render the video frames crossing the split. If you want to split a video file into independently-playable segments, you need to use an encoder that understands video files to do the splitting for you.
|
#
?
Dec 21, 2023 02:27
|
|
|
|
| # ? Jun 7, 2024 04:21 |
|
|
maybe generate MPEG-DASH files
|
|
#
?
Dec 21, 2023 03:15
|
|
|
kedo posted:To me HTMX feels a lot like someone said, "I'm a construction worker but I only know how to use hammers. I use hammers to hit things, and I don't want to have to learn how to saw things, or drill things, or glue things, so I made this hammer that can saw and drill and glue. It doesn't do any of them well, and it was a convoluted process to make it and actually required that I shoehorn a saw and drill and glue bottle onto my hammer, but at least now I can (poorly!) saw and drill and glue things by simply whacking them with my hammer!" it looks like a immediate upgrade of HTML at first, but one that does not deal well with higuer levels of complexity, I got in their manual to the section "syncronization", and seems the approach is already creating problems for itself that require un-intuitive solutions. https://htmx.org/docs/#ajax Is too bad HTML was not designed or upgraded at some point to be more like HTMX, is true that would have solved most problems 20 years ago. For today you want full on frameworks, I believe.
|
|
#
?
Dec 25, 2023 05:18
|
|
|
HTMX doesn't look like something I'd ever use. It looks like a mess to maintain for anything more complex than a comment form. For really simple use-cases, you can just use plain JS. If you're doing more complex stuff, there's a reason why component frameworks exist. It's not like you have to spend a lot of time loving around with webpack either, just slap some react/vue/svelte and some vite on it and you're good to go. Plus, it looks like there are some weird security issues just waiting to jump at you. Demographics wise, I've noticed it's mostly popular with self-professed back-end developers who derisively snort whenever they hear anything about JS.
|
|
#
?
Dec 25, 2023 09:30
|
|
|
hey mom its 420 posted:HTMX doesn't look like something I'd ever use. It looks like a mess to maintain for anything more complex than a comment form. For really simple use-cases, you can just use plain JS. If you're doing more complex stuff, there's a reason why component frameworks exist. It's not like you have to spend a lot of time loving around with webpack either, just slap some react/vue/svelte and some vite on it and you're good to go. Plus, it looks like there are some weird security issues just waiting to jump at you. I have done experiments to revitalize some legacy code. This legacy code has a lot of javascript modules written like this: code:https://betterprogramming.pub/what-are-cjs-amd-umd-esm-system-and-iife-3633a112db62 I trough I could wrap this "IIFE" modules into AMD modules. The idea died quite soon when some standard library unrelated to anything, but a requirement (maybe jquery?) broke once I included requirejs.min.js quote:Demographics wise, I've noticed it's mostly popular with self-professed back-end developers who derisively snort whenever they hear anything about JS. I like to learn things that I can sill use 30 years from now. For Javascript, it seems frameworks run in fads. Even getting in something like React is getting hard because when I google tutorials, is like each tutorial is for a different language, they are written in a different style. Maybe is because different versions of React, or whatever. The front-end world seems to move so fast, that is like taking a train that is not slowing down when it pass the station.
|
|
#
?
Dec 25, 2023 11:03
|
|
|
Oh yeah, those were the times. Just doing everything in Django if you could get away with it was way better than that hell. I get where the notion that JS development is fad driven came from, but I think it doesn't really hold water nowadays. React has been the top dog forever and you can still write pretty much the same React code as you could 8 years ago. Function components were introduced in the interim (and with them hooks), which required a bit of a mental shift, but the core concepts (components, state, and props) remained largely the same. I don't want to rag on Python here, but the 2 to 3 transition was unlike anything in the JS world (in the bad sense). And instead of remaining a simple language, it's received a bunch of stuff that makes reading Python now very different from reading Python 8 years ago (the := operator, type hints, async, not to mention package management and what they're gonna do to the GIL). Still, it's OK imo, since the only things you'll really be able to use 30 years from now I think are core concepts of development that aren't tied to any one language or framework.
|
|
#
?
Dec 25, 2023 11:41
|
|
|
hey mom its 420 posted:HTMX doesn't look like something I'd ever use. It looks like a mess to maintain for anything more complex than a comment form. For really simple use-cases, you can just use plain JS. If you're doing more complex stuff, there's a reason why component frameworks exist. It's not like you have to spend a lot of time loving around with webpack either, just slap some react/vue/svelte and some vite on it and you're good to go. Plus, it looks like there are some weird security issues just waiting to jump at you. What are the weird security issues?
|
|
#
?
Dec 25, 2023 12:58
|
|
|
My bad, I read somewhere that there were some security issues, but didn't look it up too much. It just turns out that if your server is compromized it will be able to inject stuff into your client code, which isn't really a big deal since if your server is already hacked you're hosed anyway.
|
|
#
?
Dec 25, 2023 13:14
|
|
|
I’m a backend dev with about 10 years experience but have barely touched frontend at all, and tbh I’d like to be able to build a full stack personal project. What framework would you recommend for learning front end stuff in tyool 2023/4? Googling I see recommendations for React, Remix, Next, Vue, Vite, Svelte (and SvelteKit which is different?), Angular (lol), and probably more I’ve forgotten. I’m not sure how much of that is spurred by trends or is pushed by a hosting provider offering easy hosting for that stack. It also seems to be hard to find actual up to date guides on how to use most of these things because things have changed a lot over time. Is it worth using TS instead of JS? It seems like a good idea because type safety is the best, but I think the last time I used it for anything in a backend nodejs app a bunch of stuff was just “any”, anyway. It also seems like it’s possible (at least in Next) to have your frontend site also contain api endpoint routes now… so do I even need to bother hosting a separate API anymore?
|
|
#
?
Dec 31, 2023 07:55
|
|
|
Big caveat: All of this advice is assuming you want to learn just enough front-end to make your project, then basically discard that knowledge. That's perfectly fine, but if you have further goals beyond that, the advice would change. For better or worse, the answer has been React for years and will continue to be React for years to come. Regardless of the Goodness™ of the framework itself, anyone starting out should be using it because the support network for it is so good. Realistically speaking, any problem you can possibly have with react has an entire blog post dedicated to it by experienced engineers who either also ran into the problem, or mentored a more junior engineer on that exact problem. It's not trivial to start with, but you will absolutely have your hand held the entire time. TypeScript is good, but if your goal is just a full-stack personal project, probably don't bother. It's a lot of extra work, and that extra work is what makes it good, but for just "What do I do to make one project?" it's probably pointless. And unlikely you'd use it well enough to benefit from it. Getting started with React is kind of up in the air, because what you should be doing is looking up how to build exactly what you want to build and following that guide as far as it takes you, then branching off once the guide is done and googling specific problems from there. A full "How to do react???" course is probably way too much work for the scope of your goal. Without knowing your exact project, and probably even if I did, I can't really point you to a direct source to learn it.
|
|
#
?
Dec 31, 2023 08:55
|
|
|
Probably a bad choice of wording in my part - it’s not for a specific current project, the goal really is to learn enough frontend to be at least mildly comfortable building something user facing.
|
|
#
?
Dec 31, 2023 08:59
|
|
|
I'd recommend Next with Supabase. Like the man said, React is pretty much your best choice, and server components is the direction it's heading. It's a really nice experience to be able to have components that run on the server and can just look up stuff in the DB without mucking about with REST and endpoints and whatnot. That way most of your components can be self-contained and don't need to depend on anything but your data source. This video showcases it well, ignore the marketing tone. Supabase is nice because you get auth, a good db, file storage and even websockets set up for you, and you can still self-host it down the line if you decide to do so. Either that or vercel, but I like supabase more. I'd say definitely use TS, especially if you're doing this as a learning experience. It's some work upfront to learn and get into, but it helps a lot by handling a whole class of bugs for you, and also helps you go faster since you can always inspect some variable in your IDE and see what shape it's supposed to be. It's cool if you use a DB layer like Drizzle, since it also makes your DB queries and data type-safe.
|
|
#
?
Dec 31, 2023 09:48
|
|
|
Surprise T Rex posted:I’m a backend dev with about 10 years experience but have barely touched frontend at all, and tbh I’d like to be able to build a full stack personal project. If you specifically want to just write a front-end app and don't want to deal with the fullstack options I would do React/Vite/TypeScript. Use react-router for client-side routing, use @tanstack/react-query for data fetching, use Tailwind for styling, and use shadcn/ui for your component library. This is the bog standard setup for building front-end apps in 2023. Doing this you'd write your backend in whatever stack you're comfortable with and then serve an API from it that your React app connects to. If you want to write a fullstack app it depends on what you want. If you're going for pure resume building I'd go with Next and either Supabase or another "edge" DB provider like PlanetScale. If you want to stick with React but want something that's a bit less popular but more stable I'd go with Remix. If you want something that's probably going to be a lot easier to learn and without React's footguns I'd go with SvelteKit. Personally I'm starting all my projects in either Remix or React/Vite these days depending on whether I need server-side rendering.
|
|
#
?
Dec 31, 2023 16:32
|
|
|
hey mom its 420 posted:Supabase Don't know if I'm finally old but the idea of using something like that as opposed to building everything from scratch is starting to appeal to me.
|
|
#
?
Jan 1, 2024 15:31
|
|
|
Thanks for the recs all - I've had a look at NextJS to get started. Since it's based on React hopefully a decent bit of the knowledge I pick up will transfer to React as well, and I guess worst case scenario is that I never use any of the SSR or backend functionality and it's just a client-side framework but with stuff like routing built-in. Honestly, I like the look of Svelte a lot more based entirely on their respective "hey check us out" pages, but I'm more likely to have less help with problems going that route. It's a lot less scary than I expected it to be tbh, my last real exposure to frontend stuff was AngularJS 1.0 at an old job, and even then only minor changes to existing stuff, and any time I looked at React it always seemed so complex. I will say though, I'm not loving the fact that both Next and Svelte seem to force you to name every single page "page.tsx". I think I understand why (the builtin serverless backend stuff it seems?) but ugh.
|
|
#
?
Jan 1, 2024 21:20
|
|
|
.js becomes .jsx because you are using JSX which isn’t valid JavaScript so the extension helps out the IDE and such. Then .jsx becomes .tsx because its typescript. Oh, I think I misunderstood, it’s literally page.tsx? That’s annoying.
|
|
#
?
Jan 1, 2024 22:09
|
|
|
smackfu posted:Oh, I think I misunderstood, it’s literally page.tsx? That’s annoying. Yeah this. And naming folders for routes. Not sure how much stuff in Next is just convention and how much is actually magic filenames for sure yet though. Feels a bit Rails-y.
|
|
#
?
Jan 2, 2024 01:00
|
|
|
hey mom its 420 posted:HTMX doesn't look like something I'd ever use. It looks like a mess to maintain for anything more complex than a comment form. For really simple use-cases, you can just use plain JS. If you're doing more complex stuff, there's a reason why component frameworks exist. It's not like you have to spend a lot of time loving around with webpack either, just slap some react/vue/svelte and some vite on it and you're good to go. Plus, it looks like there are some weird security issues just waiting to jump at you. Honestly, I just really appreciate how simple and logical the whole HTML doing AJAX calls and HATEOAS. As both an idiot and someone new to front end, it's the first framework I've read that just made sense. Most folks here understandably are coming to it with a lot of experience and maybe forget how utterly insane all modern front-end architecture is, so it's refreshing to look at a stupid simple way to build a website that isn't some low-code trash. Obviously no one should be building a full bells and whistles web app with this, but how many sites really need that? Lots of sites using the common stacks are over engineered nightmares. I know this is like going into a carpentry shop and saying how you hate CNC machines and love using a handsaw, so I get the disdain since it's such a departure from existing stacks. I'm just an idiot who wants to make some dumb internal UIs off some existing APIs without having to dedicate time and effort to a whole new language and framework when I already know HTML/CSS, and I know Python. Oysters Autobio fucked around with this message at 03:00 on Jan 2, 2024 |
|
#
?
Jan 2, 2024 02:42
|
|
|
Yeah, picking what suits you based on your skills and needs will never be the wrong way to go. It's worth pointing out though that (especially for simple projects), modern stacks have gotten really easy. They're far from the over-engineered mess that they used to be imo. There's pretty much no configuration and the developer experience is really simple and easy. When you start doing more complicated things it's a bit of a different story, but the same is true for everything else.
|
|
#
?
Jan 2, 2024 13:29
|
|
|
Surprise T Rex posted:Honestly, I like the look of Svelte a lot more based entirely on their respective "hey check us out" pages, but I'm more likely to have less help with problems going that route. I'm a huge Svelte fan and I say if you prefer it to React, just use it. I've used SvelteKit in production for a couple of sites now. Learning React is probably the smarter move if you're trying to transition to having front end work be a more formal part of your job responsibilities, but then learning HTML and CSS really well is likely more important than the particulars of the JavaScript framework you choose.
|
|
#
?
Jan 2, 2024 15:24
|
|
|
Yeah OP if you're purely trying to build cool stuff and have a fun time try Svelte. Go with React if this is a resume builder. Not that React is bad but Svelte is super elegant.
|
|
#
?
Jan 2, 2024 18:57
|
|
|
Oysters Autobio posted:Honestly, I just really appreciate how simple and logical the whole HTML doing AJAX calls and HATEOAS. As both an idiot and someone new to front end, it's the first framework I've read that just made sense. The big fear I would have of using HTMX would be that while the declarative style abstraction is elegant, there is going to naturally be a bunch of code underlying the abstraction - e.g. in order to make these HTMX attributes work, someone had to write a bunch of opinionated, imperative style javascript making it work. Trying to troubleshoot issues in that area - e.g. you use one of their attributes, something doesn't work for some dumb loving reason, and you don't know javascript so you don't know why - could be a rough experience. This is the faustian bargain you make when using declarative style programming - declarative style programming/frameworks can be great and a huge time saver if you are extremely knowledgeable all the way up and down about the tools you are using and the abstractions, and can also help a beginner with little knowledge of the underlying stuff get started real easy, but man can you get burned when you don't know what you don't know when you use declarative style programming.
|
|
#
?
Jan 2, 2024 19:50
|
|
|
The assumption is that the people writing the imperative code underlying it all probably know more than you do about writing good code. And for probably 99% of application developers, that's a fair assumption. Not because application developers are dumb or anything, but because they are inherently focused on the imperative work of what the application should be doing, not how it should be doing it. The people writing application frameworks are implementation nerds. That's their thing. The other big reasoning is if most of your code is declarative, then the framework developers can improve it by releasing an update, so the time they spend optimizing a function makes a small improvement to thousands of applications instead of just one. That matters in an enterprise environment where you have to decide where to spend your time. They can literally afford to take the time to write better code.
|
|
#
?
Jan 2, 2024 20:02
|
|
|
I've been trying a few different frameworks for a small personal app. Svelte is the weirdest and most interesting to me, having worked with React for years. It has a bunch of magic and neat bindings etc that I'm still getting used to. The transition directives are very handy. Solid was very similar to React. Maybe too similar to be interesting to learn. I found it a little awkward in some ways, what with not being able to destructure props and some typescript weirdness that I couldn't be bothered figuring out. I haven't seen a single job ad here in the UK for Svelte, so I'm not counting on it being useful on the CV.
|
|
#
?
Jan 2, 2024 20:05
|
|
|
Bruegels Fuckbooks posted:The big fear I would have of using HTMX would be that while the declarative style abstraction is elegant, there is going to naturally be a bunch of code underlying the abstraction - e.g. in order to make these HTMX attributes work, someone had to write a bunch of opinionated, imperative style javascript making it work. Trying to troubleshoot issues in that area - e.g. you use one of their attributes, something doesn't work for some dumb loving reason, and you don't know javascript so you don't know why - could be a rough experience. This is the faustian bargain you make when using declarative style programming - declarative style programming/frameworks can be great and a huge time saver if you are extremely knowledgeable all the way up and down about the tools you are using and the abstractions, and can also help a beginner with little knowledge of the underlying stuff get started real easy, but man can you get burned when you don't know what you don't know when you use declarative style programming. The big problem I have with HTMX is that it's "declarative" in that you put stuff in HTML attributes but it's still imperative in that you have you manually say "when this happens, make sure this, this, and this happens." For example, say you have a list of comments and at the top you have the count of comments. When you delete a comment you have to remove it from the list AND update the count. When you add a comment you have to add it to the list AND update the count. With something like React or Svelte you just update the underlying comment data and don't have to manually update the DOM in each place that you change the data. When you're in charge of making your own updates like that it becomes really easy to render out impossible states. The example with a list of things and count of things is relatively simple compared to some UIs.
|
|
#
?
Jan 2, 2024 20:22
|
|
|
So I followed NextJS "Getting Started" demo project thing all the way through to the end, and as a bit of a stretch goal decided to add Google as an auth provider in addition to the Credentials auth it walked me through (and then told me in no uncertain terms to not use because it's worse)... but I can't figure out how to make it work. Holy hell Auth.js has loving garbage documentation. There's about 8 different pages that each show slightly different snippets of code that tell me how to do the thing I want to do, most of which are for the older "pages" router instead of the "app" router Next uses now... and any guides that do tell me how to do it with the app router use a totally different convention for where things go. The NextJS tutorial project had me make "auth.js", "auth.config.js" and "middleware.js", the first two of which seem almost identical, auth.js just spreads the properties of auth.config.js and then adds more stuff to it, pretty much? All the other guides I can find seem to want me to put this stuff inside a [nextauth].js file or something similar instead or to define a specific API handler route. I don't fully understand why Next's website would tell me to do it in a way that very much seems to not be standard practice, and I can't figure out which bits of the info I find are relevant because there's two semi-current versions of Next.
|
|
#
?
Jan 2, 2024 22:32
|
|
|
It's been a while since I used Vue and it's going great. They slimmed down all the tooling, vite, pinia, create-vue, etc it's great with typescript I'm loving it. A couple gotchas here or there but not really. Building an app with the help of copilot too it's super fast.
|
|
#
?
Jan 2, 2024 22:42
|
|
|
Bruegels Fuckbooks posted:The big fear I would have of using HTMX would be that while the declarative style abstraction is elegant, there is going to naturally be a bunch of code underlying the abstraction - e.g. in order to make these HTMX attributes work, someone had to write a bunch of opinionated, imperative style javascript making it work. Trying to troubleshoot issues in that area - e.g. you use one of their attributes, something doesn't work for some dumb loving reason, and you don't know javascript so you don't know why - could be a rough experience. When you mean "someone had to..." are you referring to the HTMX devs? I'm sorta confused here if you mean A) it would be hard to debug HTMX because of how opinionated it is or B) are you talking about something regarding working with API data? Because I don't understand how I'd be any more able to debug through the alternative status quo with multiple library webpack-build-shadow-DOM-hooks-hydration abstraction shenanigans that happens with a lot of JS frameworks. I'd much rather have to debug with one opinionated codebase rather than multiplying that. edit: for the record I am fully talking out of my rear end here off my impression, so absolutely upfront that maybe I'm being unnecessarily dissuaded with the multiplicity of frameworks and parts. Oysters Autobio fucked around with this message at 02:54 on Jan 3, 2024 |
|
#
?
Jan 3, 2024 02:48
|
|
|
Surprise T Rex posted:So I followed NextJS "Getting Started" demo project thing all the way through to the end, and as a bit of a stretch goal decided to add Google as an auth provider in addition to the Credentials auth it walked me through (and then told me in no uncertain terms to not use because it's worse)... but I can't figure out how to make it work. Bail on Next imo. I know I threw it out as an option before but that's only because it's popular. It's kind of a mess.
|
|
#
?
Jan 3, 2024 04:24
|
|
|
prom candy posted:Bail on Next imo. I know I threw it out as an option before but that's only because it's popular. It's kind of a mess. Definitely seems decent enough for rapid prototype stuff tbh, and I suspect a lot of it is just my unfamiliarity with React in general, but I think it's a bad time to have picked Next up given that Next 14 seems pretty new and makes some experimental stuff (like app routing) the norm - leaving other libs like Auth.js to rush to update docs and so on. I'll take a look at SvelteKit, maybe Vue as well, and plain React/Vite and see how I get on with those. I'm more than comfortable writing my own backend stuff but the "batteries included" vibe of Next was appealing so I didn't have to figure out individual npm packages for auth, routing, etc.
|
|
#
?
Jan 3, 2024 09:24
|
|
|
Surprise T Rex posted:So I followed NextJS "Getting Started" demo project thing all the way through to the end, and as a bit of a stretch goal decided to add Google as an auth provider in addition to the Credentials auth it walked me through (and then told me in no uncertain terms to not use because it's worse)... but I can't figure out how to make it work. While I have run into some tricky situations with next-auth, I found getting it initially set up for a basic OAuth provider to be pretty straightforward. However, my project hasn't moved to the app router yet. The [...nextauth].ts stuff is defining multiple API routes which the library uses for things like sign in, sign out and getting session data. That's also where I defined my providers (e.g Google). Also I believe the pages directory is still the pattern used for api routes (where [...nextauth].ts needs to go), see: https://arc.net/l/quote/yynadaqb. If you want to continue with Next, I'd start with this to implement OAuth: https://authjs.dev/getting-started/providers/oauth-tutorial. From there you can also add a Credentials provider if you need it (see https://authjs.dev/getting-started/providers/credentials-tutorial). That will have you define your config completely in [...nextauth].ts, and then show you how to protect pages or API routes. That tutorial doesn't use the app router, but it shouldn't be much work to make the changes necessary to use it if that's what you desire. The pages/_app.tsx bit now goes in app/layout.js (see https://nextjs.org/docs/pages/building-your-application/upgrading/app-router-migration#migrating-_documentjs-and-_appjs and you can check https://nextjs.org/docs/pages/building-your-application/upgrading/app-router-migration#step-4-migrating-pages for how to migrate the pages/overview.tsx bit to an app router page. In that example, overview.tsx contains both the code that auth protects that page, as well as the page itself. A more reusable approach would be to put the auth check and no-auth redirect in a wrapper component (say something like <AuthenticatedPage>) that contains the useSession, status is loading, status is authenticated bits, and then pass the child components into the status is authenticated return. Probably didn't explain that well, but essentially you end up with each page that needs to be auth protected's render method looking like <AuthenticatedPage><rendering for your actual page component></AuthenticatedPage>. You can use middleware in place of this approach, but it's not required. Also IIRC you can automatically redirect to the sign-in page rather than having to show a button or link that calls signIn() by adding an onUnauthenticated callback that calls signIn() to the useSession call (check the Client API docs). Do note that this tutorial has you "npm install next-auth", which will install next-auth version 4. I think where the confusion is coming from is that next-auth v5, which is in beta (installed via "npm install next-auth@beta"), is a major rewrite of the library that contains a lot of changes (e.g. using auth.ts). It looks like Auth.js has updated some of their tutorials to use v5, but not all of them, and I don't think they make the difference clear at first glance. Also keep in mind most of the 3rd party tutorials you find will also be written for version 4. You can see the v5 changes here: https://authjs.dev/guides/upgrade-to-v5. I think you should stick with version 4 for now since 5 is still in beta (which may have some broken OAuth providers) and since most of the tutorials you'll find will be written for 4. I don't think Next 13 vs 14 is the issue, as I don't think there were many breaking changes added in 14. All the app router stuff was added in 13, so it's been out for over a year now. If you are having issues with 14, there's almost no breaking changes going from 13 > 14, so it should be easy to drop down to 13 for now and upgrade to 14 when it's more mature.
|
|
#
?
Jan 3, 2024 11:25
|
|
|
Which version of Next allows me to ignore all the React Server Components stuff?
|
|
#
?
Jan 3, 2024 14:05
|
|
|
smackfu posted:Which version of Next allows me to ignore all the React Server Components stuff? In Next 14 you can just serve a client component from the root server component and never have to deal with it. Or use the pages router instead of the app router, though with that your paths can only be yoursite.com/two/levels deep. Cheston fucked around with this message at 15:02 on Jan 3, 2024 |
|
#
?
Jan 3, 2024 15:00
|
|
|
smackfu posted:Which version of Next allows me to ignore all the React Server Components stuff? Remix
|
|
#
?
Jan 3, 2024 17:15
|
|
|
Splinter posted:[Lots of next-auth words] Thanks for this, I followed the process here and sort of roughly translated it to AuthJS 5 as I went, and managed to get it working! I guess it’s still up in the air whether nextJS is particularly worth using given that it seems designed to work perfectly on Vercel hosting and that’s about it, but is it theoretically possible to just whack “use client” on basically everything and host it basically anywhere any other react app would run?
|
|
#
?
Jan 4, 2024 13:30
|
|
|
Cheston posted:In Next 14 you can just serve a client component from the root server component and never have to deal with it. Or use the pages router instead of the app router, though with that your paths can only be yoursite.com/two/levels deep. Thanks will check that out. And remix I guess.
|
|
#
?
Jan 4, 2024 13:45
|
|
|
Fair warning, Remix is going to be adding RSC as well but they're slow playing it to make sure they get the implementation just right. I've been really happy with the stewardship of that project so far. The fact that they're owned by Spotify and not a PaaS company is also nice too because it doesn't feel like a big ad for "deploy your app with us! for money!"
|
|
#
?
Jan 4, 2024 15:17
|
|
|
prom candy posted:If anyone does want a React SSR option Remix is very good and being owned by Spotify means they're not trying to sell you hosting. prom candy posted:The fact that they're owned by Spotify and not a PaaS company listen man we get you love spotify but it's just not gonna happen no matter how much you preach it
|
|
#
?
Jan 4, 2024 18:54
|
|
|
Remix is owned by Shopify, which kind of is a platform as a service... if you're building an e-commerce app, that is. They offer hosting for custom storefronts built using their Remix-based framework called Hydrogen bundled into their subscription plans.
|
|
#
?
Jan 4, 2024 19:07
|
|
|
|
| # ? Jun 7, 2024 04:21 |
|
|
To be fair shopify and spotify are basically exactly the same thing, their names are almost identical.
|
|
#
?
Jan 5, 2024 02:06
|
|