Earlier quoted context omitted.
Safari is the new IE.
Wish it is but it's crazy fast with M1
Any browser is fast with the last CPU node.
Safari is becoming compatibility nightmare.
SvelteKit 1.0
221–230 of 296 posts
Re: SvelteKit 1.0
#222I'm just completing a job using svelte/kit, tailwind, postgres, typescript. Actually, I was new to the entire stack, but it went smooth as butter. (Though I have plenty of experience with JS, HTML, CSS, other databases, etc.) IMO, svelte and sveltekit are well designed and have a great dev experience. LOL, as I was writing this he was apologizing on the stream for the breaking changes. That was a bit of a pain, but n…
Yes, it's easy to get confused with folders and folders of +page.svelte [slug].svelte would be better [slug]/index.svelte [slug]/[category].svelte Etc There is a vscode extension that helps a little bit, but it's still the one thing I am not fond of.
What bothers me about it is that the routes and layouts have to live in the same hierarchy... Of course this is very usually OK, but layouts have an aspect of visual design while routes follow a logical organization. These are going to change according to different priorities and can be controlled by very different groups/people/authorities. There will be conflicts, and when that happens, you're going to be refactoring code (e.g. to factor out common bits to a component that can suddenly no longer live in the same layout) and moving it around.
The fundamental problem is that folders are now being used for two different concerns, which will inevitably lead to conflicts (and developer pain).
Edit: oops, you're actually talking about the removal of the option to have routes defined by a file, so that a route must be defined by a folder. I'm completely fine with that. I don't know why people complain about that. All the interesting routes end up with more than one file anyway, and who needs a special extra-simple way to organize the uninteresting routes, which are already simple?
Re: SvelteKit 1.0
#223This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…
Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator). https://github.com/OpenAPITools/openapi-generator I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease…
I agree with the sentiment--and with most of your comment--except the assertion that "I don't think it's possible to beat this stack".
I have something similar: Kotlin on the server-side with my SQL DSL generated by jOOQ and Flyway running my schema migrations. I don't have any experience with LINQ--but it looks to be of a similar idea to jOOQ such that you get an autogenerated, injection-safe, type-safe, compile-time-checked SQL DSL.
If you like LINQ, you'd probably really like jOOQ. It's uber-powerful and the only queries that I've not been able to completely write in jOOQ are geo-spatial queries--and even for them, I can use string SQL for just the one where-clause predicate where I need to go off-the-rails--the rest of the query still being standard jOOQ. The thing I like most about it, is that the queries that I write in the DSL are sooo close-to-the-metal of pure SQL--I'm not even context-switching between SQL and jOOQ really. Check it out!
Re: SvelteKit 1.0
#224Earlier quoted context omitted.
What would be an example of large scale for a front-end app or site?
complex dashboards like CircleCI or client portals like maybe your bank or health insurance portal many pages and lots of functionality with lots of data floating around like Reddit, Twitter literally everything/anything like Facebook, GitHub, etc For simple apps, I'd go with a PWA if possible. For single, mostly informational, pages you usually just need a static site. For a company blog, some of these tools could b…
Maybe https://beta.music.apple.com/ qualifies? =)
Re: SvelteKit 1.0
#225Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? From what I know it has more fine grained reactivity than for example React or Vue and should therefore just run more efficient? Or has the approach of Svelte also drawbacks that I am not aware of?
> Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks? I personally would say no. I like Svelte's dev experience but I don't like the output code and while it has smaller invalidation subsections than a full component there's not a 1 to 1 mapping between a piece of data changed and the exact piece of DOM getting updated. > Or has the approach of Svelte also drawbacks tha…
Re: SvelteKit 1.0
#226Fantastic news! Although I loathe writing libraries [1] in Svelte, I love writing apps and kit is great extension to server side. I like similar to Remix push for Web APIs, like forms for mutations etc. I like nested layouts with data endpoints. I like that most of the internal state is visible as reactive store.
[1] Creating complex type definitions for more generic components is hard and require knowledge about internals.
Re: SvelteKit 1.0
#227This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…
Openapi, then codegen on both ends — frontend (orval) with TS and react-query, and backend with golang (openapi codegen) for the server's request and response objects.
Works a treat.
Re: SvelteKit 1.0
#228Is Svelte eating Vue's lunch but not really eating React's?
Re: SvelteKit 1.0
#229This is how I move fast and break nothing. By having fullstack type-safety from database all the way to the frontend with auto-completion. My current stack: + SvelteKit (could be Next, Nuxt, Solid or any other TypeScript framework) + tRPC (typed calls between frontend and backend, https://trpc.io ) + trpc-sveltekit (glues SvelteKit and tRPC, https://github.com/icflorescu/trpc-sveltekit ) + Prisma (ORM, https://www.pr…
I use the same, but with Hasura and Next.js with GraphQL + Next.js + GraphQL Zeus / GraphQL Code Generator (typed calls between frontend/backend) + Hasura (generates GraphQL API for database)
We do something similar. GraphQL type generation is pretty amazing, especially with heavy use of co-located queries on the FE and a typed ORM like prisma on the BE.
Re: SvelteKit 1.0
#230Earlier quoted context omitted.
This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard. Everything you described in terms of easy migrations and…
Exactly. With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models. With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build ti…
That sounds nice for the main user interaction, but what about when you need more heavy lifting of async tasks and side effects?
Like I get a shared model being accessed "directly" for the things that the UI displays and manipulates. But once you click an Order button you have transactions to process, ledgers to update, notifications to dispatch.
That kind of code doesn't float between client and server, it needs to happen once the order has been received regardless of the client state.
You can offload that to other services, lambdas, etc. but that's the sort of thing that you can just do all-inclusive in a standalone backend be it Node, .NET, Go, etc.