[HN Gopher] SvelteKit 1.0
___________________________________________________________________
SvelteKit 1.0
Author : theodorejb
Score : 615 points
Date : 2022-12-14 17:15 UTC (5 hours ago)
(HTM) web link (svelte.dev)
(TXT) w3m dump (svelte.dev)
| FractalHQ wrote:
| Sveltekit has been transformational for me. I can't express
| enough gratitude to the legendary team who made this happen.
| Congrats guys!!!
| adamnemecek wrote:
| Perfect timing!
|
| I literally started working on a project in Svelte after spending
| like two afternoons trying to do it in React.
|
| Svelte is such a God send. So much simpler and powerful than
| React. Not to mention the fact that React only handles the UI
| layer but is too unopinionated w.r.t. the application
| architecture.
| omnibrain wrote:
| All the praise for SvelteKit in this thread peaked my interest.
| But where would I start?
|
| I'm currently looking around to find a modern "toolkit" to write
| a new webbased frontend for our traditional desktop app. It's
| goin to be more or less CRUD with lots of tables/grids.
|
| Currently I favour vue.js with Quasar because of all the tooling
| and ressources it offers. It looks like it's easy to start with a
| traditional "navigation on the left, content on the right"
| layout.
|
| I need nothing fancy, it's going to be business CRUD for a small
| circle of users. Deployed on premises at our customers sites.
| arxpoetica wrote:
| You can start here: https://learn.svelte.dev/tutorial/welcome-
| to-svelte
| cschmidt wrote:
| It is a really wonderful interactive tutorial. So well done.
| encryptluks2 wrote:
| > Yikes! We couldn't start the app. Please ensure third party
| cookies are enabled for this site.
|
| Yikes! No thanks.
| swyx wrote:
| or go incognito mode
| samtp wrote:
| You can also just install the demo package and play around
| with it on your own computer.
| theo-steiner wrote:
| https://learn.svelte.dev/ is a great place to start!
| pier25 wrote:
| Bravo! Congrats!
| domakidis wrote:
| What would be the best route to upgrade a medium sized project
| from say `1.0.0-next.263`?
|
| There's 327 intermediate versions up to this one and a
| considerable amount of breaking changes.
| stephenstuder wrote:
| Its so freaking good, hope large orgs start using it
| efields wrote:
| Congrats to Svelte. More than a couple years ago, I gave my team
| the opportunity to go React, Vue or Svelte after giving them time
| to test them out. React was basically the legacy code that we
| were familiar with. This was right around the first hooks release
| and after using it for a while, and we had a nasty redux state
| manager, and nothing about React felt truly great for DX besides
| JSX, and that was everywhere already.
|
| I'm happy with Vue but every time I look at Svelte code I get a
| bit jealous. Its a very nice environment, one I would pick up for
| personal projects if that time was there, and I wish Svelte
| godspeed and a huge adoption curve.
| samtp wrote:
| While the breaking changes were rough this year, the new
| structure is a huge improvement over before. It is now extremely
| clear the order that items are loaded, and what is loaded on the
| server vs client. Form actions are also amazing.
|
| Congrats to the team and thanks for all the hard work!
| SebastianKra wrote:
| While I like Svelte, I fear it looses some of the flexible API-
| building enabled by React.
|
| Specifically: since it uses a templating system, you can't pass
| around interface definitions easily:
|
| - https://github.com/sveltejs/svelte/issues/3480 (no dynamic
| slots)
|
| - https://github.com/sveltejs/svelte/issues/5381 (can't wrap
| children)
|
| You can always find workarounds for these cases, often using
| `<svelte:component>`, but React's Javascript/Typescript-centric
| design avoids such issues before they even occur. For instance, I
| can trivially define a tabbed interface by mixing strings, JSX,
| and components, without imposing any DOM-structure. The component
| that reads this definition can use it to build a tabbed-view on
| mobile, and a master-detail-view on desktop. It could even build
| a table of contents.
|
| In the definition, I can still work mostly with strings, but fall
| back to JSX in the rare case where I do need some advanced
| formatting: const tabs = [ { name: "Tab
| 1", icon: <img ... />, content: MainTab }, { name: <>Tab
| with <b>bold<b/> text</>, icon: <MyIconComponent ... />, content:
| SecondTab }, ]
|
| Again, I like Svelte, but I'm not yet sure whether the better
| syntax is worth the reduced expressivity.
| sesm wrote:
| Not sure what you mean by `React's Typescript-centric design`,
| React used Flow from the very start and also had PropTypes for
| plain JS. Typescript support came much later.
| SebastianKra wrote:
| I was thinking about the full power of JavaScript while still
| being perfectly typesafe.
|
| I edited the comment to hopefully better reflect that.
| foxbee wrote:
| I've been waiting for this for months! Credit to the team.
| Looking forward to the weekend to play around with it. Also,
| super excited for svelte 4
| Tade0 wrote:
| As someone who wrote his first lines of JS in 2001, working with
| Svelte feels a lot like the good old days of JS when front-end
| was simple.
|
| To me the main selling point is that the stack trace is actually
| useful for a change - you especially can find in there the line
| which caused the re-render and subsequent error.
|
| JS frameworks/libraries by and large lost that feature a decade
| ago.
| jerriclynsjohn wrote:
| Been using Sveltekit and love what the community has done to the
| framework. Makes life of a developer very straightforward and I'm
| sure that Sveltekit will rise to be a dominant frontend framework
| soon.
| jmull wrote:
| I'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 not really
| that bad. My only real gripe is using folders to organize both
| layout hierarchy and route hierarchy is going to turn out to be a
| mistake.
| crucialfelix wrote:
| 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.
| yencabulator wrote:
| The src/routes/posts/[slug]/+page.svelte thing is pretty
| recent, it used to be just src/routes/posts/[slug].svelte.
| I'm not exactly thrilled with the new naming...
| MentallyRetired wrote:
| I left the framework for this reason. When I asked about
| it, I was told "this is what Next will be doing soon". I
| need more reasoning than that, and it was indicative of the
| decision making process. Turned me off. Aside from that,
| Svelte is SUPER fast and easy to use. I may give it another
| go at some point.
| culi wrote:
| > My only real gripe is using folders to organize both layout
| hierarchy and route hierarchy is going to turn out to be a
| mistake.
|
| +1 to this. I think Next.js made this mistake too and is now
| backtracking
| kretaceous wrote:
| SvelteKit 1.0 is the one release I was actually waiting for. I've
| seen a lot of flashy stuff launch in the frontend framework
| recently but this one feels...genuine?
|
| Huge congratulations to Rich and team! Hope I'll be able to
| contribute to Svelte's growth someday.
| moklick wrote:
| Congrats to the launch. This looks so good :)
| dceddia wrote:
| Exciting to see this hit 1.0! The new tutorial site looks great
| and I love that the sidebar is searchable now. Also the Cmd-K
| search on the docs (https://kit.svelte.dev/) is awesome to have
| as well.
|
| I've been really enjoying working with Svelte for the last year
| or so now. My main project is a video editor, running under Tauri
| and using plain client-side Svelte, but I've also used SvelteKit
| to throw together a few little admin dashboard-y things and it's
| been very quick to get started with. Right now those projects are
| pretty lightweight too, just SvelteKit with TypeScript, the pg-
| promise package to connect with Postgres, and a handful of
| handwritten SQL queries.
|
| Congrats to the team! Looking forward to see what the future
| holds for Svelte[Kit].
| qprofyeh wrote:
| While most of the comments here seem positive... A custom
| template language is like another programming language to learn
| (to make mistakes in). I prefer JSX/TSX which is closer to
| reusing HTML.
| dcre wrote:
| Speaking as nearly-exclusively a JSX/TSX user, it is not really
| true that it is closer to HTML than Svelte's templating. People
| who like and use Svelte report the opposite.
| ovao wrote:
| Agree with this. Iterating with Array.map and returning nodes
| to compose, say, unordered lists in JSX is most decidedly un-
| HTML-like.
|
| I can see the drawback to learning yet another templating
| language, and on this point I'd just say "to each their own".
| I feel like either approach is fine. Svelte's templating is
| _pretty_ minimal, so there isn't much to learn.
| kalkr wrote:
| IMO Svelte feels much more like HTML than JSX does.
| hu3 wrote:
| This 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.prisma.io)
| capableweb wrote:
| > This is how I move fast and break nothing
|
| Absolutely impressive how you are one of the first to find a
| approach that leads to a 100% bug-free development methodology.
|
| Or, you still have bugs right, so sometimes things break? Maybe
| you meant something like: _This is how I move fast and don 't
| have a certain section of bugs anymore_?
| throwaway39048 wrote:
| I bet they don't even move "fast" since that's relative and
| we haven't determined any baseline paramters. Very
| misleading. The comment should be "This is how I move
| (metaphorically speaking, not physically e.g. increased
| typing speed) with what I perceive to be faster than
| alternative stacks that I have explored and that doesn't have
| a certain section of bugs anymore".
| gavinray wrote:
| 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)
| gmaster1440 wrote:
| Curious how you handle `request.formData()` in Form Actions and
| ensuring type safety there.
| naasking wrote:
| > Curious how you handle `request.formData()` in Form Actions
| and ensuring type safety there.
|
| Hopefully the same way typed programming languages do it:
| parsing and type checking.
| hu3 wrote:
| We use and recommend Zod for that:
|
| https://github.com/colinhacks/zod#error-handling
| harunurhan wrote:
| Like any user input, you do runtime type-checking and
| validation. TypeScript is especially great for that because
| it has type narrowing [0].
|
| [0] - https://www.typescriptlang.org/docs/handbook/2/narrowin
| g.htm...
| whycombagator wrote:
| How do you typically deploy such a stack?
| JoeyJoJoJr wrote:
| You should also mention Zod, which acts as the type safe glue
| between the different boundaries.
|
| I have been using Google Sheets as a kind of hacky database. By
| defining the schemas in Zod I am able to automatically validate
| my sheets data and coerce the string cell values into their
| proper types.
|
| Zod schemas can be used all over the stack, imported for form
| validation, and avoid heaps of duplication and tests.
| mccorrinall wrote:
| While Zod is hyped by Next.ja developers (I think mostly
| because Theo Brown has such a huge reach), I think Ajv is
| better, because it lets you generate OpenAPI documentation
| and it fully json schema compliant.
|
| I really like nextjs for its opinions on the frontend part,
| but it is lacking these strong, but great opinions on the
| backend. Wish love to see some design decisions from fastify
| adopted here. Matteo did really do some great stuff.
| intelekshual wrote:
| Zod has plugins that let you generate OpenAPI specs (and TS
| types, and JSON Schema, etc.) from your Zod schemas, so if
| that's the only reason you think Ajv is better, then it
| might be time to take another look at Zod? It really is
| great, especially if you buy into the "parse, don't
| validate" principle that it's built around.
| mitch3x3 wrote:
| How are you liking Prisma compared to a pure SQL approach?
| qudat wrote:
| When I used prisma a few years ago I was not impressed and it
| couldn't do a lot of what I needed so I had to dump into raw
| sql queries anyway. It was easier for me to use knex and get
| the types mostly right.
| lf-non wrote:
| You should take a look at ts-sql-query [1] - it is not as
| popular as the older alternatives that have been around for
| a while, but it is a very feature rich query builder that
| takes type safety very seriously and supports most
| mainstream databases.
|
| [1] https://ts-sql-query.readthedocs.io
| Trufa wrote:
| A lot has changed in the past years of Prisma, it's a
| really great tool, to be honest, "raw sql" escape hatches
| to do anything raw when you need it, if you haven't tried
| it in years, I'd recommend you to try again since if you
| tried it years ago, it was a very different maturity level.
| abraxas wrote:
| Do they (Prisma) still rely on a Rust sidecar? This
| caused multiple issues with container deployment and the
| CI/CD pipeline of my employer.
| braden-lk wrote:
| I believe the sidecar is optional now, and I think even
| the one that exists comes in the form of their paid
| service called Prisma Proxy. It doesn't seem necessary
| for most use cases.
| devjab wrote:
| I'm not the person you ask, but we use fullstack Typescript
| in our dev department. We're a weird mix of a green energy
| company and an investment bank, so inhouse development is
| very small-scale, and this means you share resources. Using
| one language for everything helps with this, since the one
| person who is really good at React can take a vacation or a
| sickday without being glued to a laptop since everyone else
| can also work on the front-end even though it's not their
| daily thing (and vice versa). More than that though it lets
| us do things like code reviews, troubleshoot solutions and
| generally work together really well, even though we're
| working on very different projects. It also lets us build
| libraries that can be used for everything. One example is our
| ODATA query and client library, which makes it incredibly
| easy to debug issues related to it, because everyone uses it.
|
| Anyway, the one place where Typescript isn't great in the
| fullstack approach is the Database stuff. We used Prismo for
| the better part of a year, until we eventually moved on to
| Mikro-orm which has been great so far.
|
| I'm personally not a big fan of OOP or "over architecture",
| because I've seen how bad it can go too many times. Instead I
| favour functional programming and keeping things as simple as
| possible, even having "almost duplicate" code once in a
| while. So with this in mind, it may strike you as odd that we
| moved from Prisma to Mirko-orm, but Prisma just clashes with
| the way we want an ORM to work in so many ways.
|
| Maybe this is by design. Prisma doesn't want to be a "real"
| ORM after all, but things like having to put everything in a
| single schema file is bothersome. Yes, you can put it in
| different files and then cat them together, but that leads to
| other issues. Like the VSC Prisma extension highlights not
| working outside the main Prisma.Schema file. More than that
| though. We like to have "ID, UpdatedAt, UpdatedBy, CreatedAt"
| sort of things on basically all our models, and since Prisma
| doesn't have the inheritance I almost never use, that means
| you need to duplicate it soooo many times. It's also hard to
| write generic methods for basic CRUD stuff because of the way
| Prisma uses the Prisma Client Classes it auto-generates to
| operate. On top of that, migrations can't go backwards in
| Prisma.
|
| Some of these issues are on the Prisma road map, others
| aren't, and you're always going to bang heads with an ORM,
| but Prisma just didn't feel as mature as it's extremely
| excellent documentation (and marketing) might lead you to
| believe in my experience.
|
| I can certainly see myself using it again, once their roadmap
| is a little further ahead though.
| ravenstine wrote:
| Duplicate code is one of the biggest near-non-problems
| programmers waste a ton of time trying to address.
|
| Sure, duplication isn't a goal, but DRY shouldn't hold back
| work as long as it has no meaningful consequence on
| performance. In some cases, duplication is a good thing,
| but your average programmer will address duplication by
| making a routing more complicated and further away from
| where it's being used. This is often a mistake.
|
| Worse yet is when programmers DRY up tests. Tests are the
| worst place to be applying DRY. The point of testing isn't
| to write an entirely new application on top of your actual
| application. If you're DRYing up your tests a lot, you're
| probably writing a second application and should probably
| stop doing that.
| lmm wrote:
| > I'm not the person you ask, but we use fullstack
| Typescript in our dev department. We're a weird mix of a
| green energy company and an investment bank, so inhouse
| development is very small-scale, and this means you share
| resources. Using one language for everything helps with
| this, since the one person who is really good at React can
| take a vacation or a sickday without being glued to a
| laptop since everyone else can also work on the front-end
| even though it's not their daily thing (and vice versa).
| More than that though it lets us do things like code
| reviews, troubleshoot solutions and generally work together
| really well, even though we're working on very different
| projects. It also lets us build libraries that can be used
| for everything.
|
| We do this the other way around, by using Scala.js so we
| can use Scala on the frontend as well as the backend. It's
| very nice.
| rapind wrote:
| Postgresql > PostgREST > Elm
| jherdman wrote:
| I'd love to hear about your testing story with Prisma. I
| recently looked into it but was disappointed to see the
| recommended approach was more or less to nuke the contents of
| the DB (https://www.prisma.io/docs/guides/testing/integration-
| testin...) instead of just rolling back a named transaction at
| the end of a test (a la
| https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html, or
| just about every other framework I've used with Ruby or
| Elixir).
| bdougherty wrote:
| What is the benefit of tRPC over built-in SvelteKit data
| loading?
| yamtaddle wrote:
| I prefer static types all the way, but my looser rule I've come
| up with in order to play nicely with others is that you're not
| allowed to interface something with poor type
| definitions/enforcement with _another_ thing that 's also bad
| at that. Including transport/wire formats, so if you're
| presenting JSON you'd better be able to tell me a good story
| about type safety on both the sender and receiver.
|
| That at least keeps the blast radius of type-related bugs very
| limited, and makes it easier to figure out where the problem
| is.
| jmull wrote:
| Personally, I'd remove tRPC on down (and choose a database).
|
| It's nice there's type-safety between layers, but that's a
| bunch of layers that you don't even need. (A layer that doesn't
| exist takes is 100% type-safe and takes 0 hours to develop and
| maintain).
| kekkidy wrote:
| deepsun wrote:
| In Mongo you don't need to manage a schema, because it's
| SCHEMALESS! /s
| shepherdjerred wrote:
| > A layer that doesn't exist takes is 100% type-safe
|
| How are you ensuring your database accesses are type-safe in
| this case?
| jmull wrote:
| That's fair... I do typically have a layer that sits at the
| level of an ORM, whose purpose is to reduce boilerplate and
| handle/verify types.
|
| So I can't really claim I have nothing at the ORM level...
| However...
|
| In my experience, when you pull in an off-the-shelf ORM and
| an off-the-shelf RPC framework _you end up building app-
| level wrappers anyway_ to deal with the complexity and
| impedance mismatch between what you want your app to use
| for data access code and what layer provides.
|
| So I think you might as well put your app-level database
| wrapper as directly around the database as you can manage
| (that probably means using the common, unopinionated client
| for your db... e.g., node-postgres for server-side
| javascript and postgres, or whatever the equivalent is for
| your backend/database).
| 5e92cb50239222b wrote:
| 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 of long-term
| support, at least without going to very niche technologies
| where you'll have other problems.
|
| Database schema is generated from models described in C# (or
| reverse-engineered from an existing schema). You don't have to
| compromise your schema to satisfy the ORM (another claim I
| often read on HN), as it's very adaptable to your needs.
|
| Migrations are generated automatically -- change your models,
| ask it to generate migration code in C# + a SQL migration
| script, review the generated SQL, and apply.
|
| The vast majority of database queries (pretty much everything
| besides reports) is written in type-safe LINQ, which makes it
| easy to refactor code, and also construct & combine queries at
| runtime. Unlike that specification abomination JPA expects you
| to use, LINQ queries look something like this:
| var latestOrders = _db.Orders .Where(ord =>
| ord.CreatedAt >= DateTime.Today) .Where(ord =>
| !ord.Deleted) .OrderByDescending(ord => ord.CreatedAt)
| .Take(25) .Select(ord => new { OrderId =
| ord.Id, Customer = ord.Customer.Name,
| CreatedAt = ord.CreatedAt, Products =
| ord.Products.Select(prod => new { ProductId =
| prod.Id, Title = prod.Title, })
| }) .ToList();
|
| If you change your schema and forget to update one of the
| queries accordingly (although using an IDE makes this pretty
| much impossible), your code won't even compile.
| NDizzle wrote:
| Could you go into a little bit more detail?
| lmm wrote:
| > Database schema is generated from models described in C#
| (or reverse-engineered from an existing schema). You don't
| have to compromise your schema to satisfy the ORM (another
| claim I often read on HN), as it's very adaptable to your
| needs.
|
| Generating the schema from the models is easy mode, the ORM
| naturally won't generate anything it doesn't understand. The
| claim is that the ORM can't handle advanced schema features
| that it wouldn't generate. (Although in my experience most
| people claiming that just never bothered to learn the ORM).
| thdrtnl wrote:
| If your are going to mention .NET in this context, why not
| mention Blazor?
|
| With Blazor you just write both the reactive frontend and
| backend in C#. No need to write Javascript. Super productive,
| type safe all the way.
|
| Today it has even support for hot reloading. Save your C# and
| see the changes in your browser.
|
| https://dotnet.microsoft.com/en-us/apps/aspnet/web-
| apps/blaz...
| Xevi wrote:
| Last time I looked at Blazor it only had two options, which
| were both equally horrible for public websites.
|
| You either had to ship a big and bloated WASM file, which
| was at least 10x the size of competing JS frameworks, and
| in some cases 100X the size. Or you had to render all
| dynamic parts of your website on the server, which made
| latency a huge problem, since your website feels sluggish
| between each interaction.
| FridgeSeal wrote:
| Because last time I looked, the Blazor binaries were huge,
| and had performance issues?
|
| It's also irrevocably attached to that specific dotnet
| framework? Want to evolve parts of your stack? Too bad.
| melony wrote:
| Do you still need to pass around "Data Transfer Objects" to
| do simple parameter binding?
| jeremycarter wrote:
| They form the type safety
| jakub_jo wrote:
| That sounds impressive.
| d0100 wrote:
| > I chuckle every time I read claims about Go (or whatever)
| being amazingly productive
|
| You can get the same'ish with Ent and Atlas
|
| I am very slowly building a big glue between DB and front-end
| and making it pluggable into their underlying libs and native
| libs
| pevey wrote:
| 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
| querying is exactly what Prisma gives you in the stack the OP
| described.
| [deleted]
| stetrain wrote:
| They are describing using .NET as an API providing a typed
| OpenAPI contract (aka swagger).
|
| Nothing about that is "full refresh" and you can use
| whichever frontend framework you like.
| brushfoot wrote:
| 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 time.
|
| As much as I like ASP.NET, Next has leapfrogged it for web
| apps.
| kcartlidge wrote:
| > _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._
|
| The separation of models is indeed inevitable when there
| is JS on the client and not-JS on the server. That's a
| 'problem' common to all non-JS back-ends.
|
| However there are three points I'd make.
|
| 1. That's often a good thing, not a flaw, in that it
| enforces a mapping boundary between what the server and
| the client know and therefore strongly discourages
| leakage of data.
|
| 2. Mapping requirements of this type are much too trivial
| to base a tech stack choice on. It's barely worth
| considering given that mappings only need doing once and
| updating once per change. They are also very good
| protection against accidentally exposing new stuff
| precisely because changes in models don't automatically
| impact the client.
|
| 3. If this model syncing was really an issue (it usually
| isn't) you could try Blazor. By doing C# on the client as
| well as the server you get to share the same code/models.
| As per point 2 I don't think that's a good enough reason
| to switch tech stacks, but Blazor also has its place.
| arcturus17 wrote:
| > As much as I like ASP.NET, Next has leapfrogged it for
| web apps.
|
| Look, I like NextJS as much as the next guy - I'd say
| it's my main working technology right now. And I've never
| built anything on .Net - I know its characteristics from
| watching tutorials and reading docs.
|
| My take however is that "web apps" is a very broad world.
| NextJS gives you a thin API layer. There is no model
| layer to speak of. You're left fending for yourself in
| the wild, wild world of JavaScript.
|
| .Net Core, on the other hand, offers a batteries-
| included, heavy-lifting, opinionated framework, with an
| immense toolbox and many conventions to guide you. There
| has to be a reason why people speak such wonders of it.
| If I had to build something enterprise-y with more than
| handful of devs it would probably be my choice.
| CharlieDigital wrote:
| If you have .NET 6/7 installed, give this a try:
| dotnet new webapi -minimal dotnet run
|
| I know there's been a lot of discussion about whether
| .NET/C# are faster than X or Y or Z based on TechEmpower
| benchmarks, but this will give you a backend that looks
| more or less like Express with an OpenAPI schema built-in
| (generate TS bindings for frontend) and a runtime that is
| going to be higher thoughput than Express or Node.
| dotnet watch
|
| And you get hot reload.
| arcturus17 wrote:
| > .NET apps are old school
|
| Microsoft has invested massively in modernizing .NET and
| C#.
|
| It is also widely praised by devs - .NET is ranked 4th most
| loved framework in the SO 2022 dev survey.
|
| You have built-in scaffolding to get a React + .NET app
| right from the CLI, with hot-reload and all the facilities
| you'd expect.
|
| Hardly old school at all. Personally, if I had to build a
| website with a thin API layer I'd reach for NextJS (or
| equivalent) alone, but anything beyond that I'd go for .NET
| Core any time of day.
| bearjaws wrote:
| Anyone know a good way to solve Prisma memory usage? We use a
| database per customer and each one adds 50-80mb of RAM. Our
| backend currently consumes 2-3GiB of RAM to host less than 100
| customers...
|
| App server has GC pauses of 50-80ms as a result of the memory
| usage.
| meowtimemania wrote:
| how many customers do you have?
| 5Qn8mNbc2FNCiVV wrote:
| If you use a database per customer you should also run a node
| process per customer. I don't know what exactly you're
| selling, but that bit of RAM should be in budget alone for
| the reason that you don't want the requests of customers
| slowing each other down
|
| I recently jumped over that "trying to minimize resources"
| hurdle myself because it's just not economically correct for
| me to spend even an hour of my time when I can host a few
| months worth of servers for that money
| marmada wrote:
| I wonder if with Next.JS server components, we can just get rid
| of tRPC + trpc-sveltekit.
| rahimnathwani wrote:
| I'd love to browse a sample codebase.
|
| Do you know of any non-trivial open source projects using this
| stack?
| mattwoodnyc wrote:
| https://trpc.io/docs/example-apps
| rahimnathwani wrote:
| Thanks. Here's the SvelteKit example linked on that page:
|
| https://github.com/icflorescu/trpc-sveltekit-example
| trillic wrote:
| Might I recommend https://jawj.github.io/zapatos/ to remove the
| last 3 lines of your stack.
| tommica wrote:
| Nice share!
| Ilasky wrote:
| Sveltekit has been an absolute DREAM to learn and use with my
| app! Been tracking their 1.0 progress closely and it's been
| incredible.
|
| Sveltekit + TailwindCSS + FastAPI has made it super easy to whip
| up functionality and have a fine-tuned approach as well.
|
| As someone else said, the "I CAN'T BELIEVE IT WAS THAT EASY" is
| an ongoing sentiment whenever I use it.
|
| Looking forward to seeing it grow and gain more popularity
| delijati wrote:
| Do i get this right, using SvelteKit SSR frontend node server
| and it communicates with backend FastAPI server via json. This
| is nowadays called a normal stack oO. (by the way i like Svelte
| but SvelteKit makes only sense if you stay in JS land, and i'm
| not willing to jump ship from python to js/ts ;))
|
| I tried htmx and so far i really like it and the + is i just
| have "one" backend.
| miohtama wrote:
| SvelteKit SSR is a very good pair to Python backends, like
| FastAPI.
| Labo333 wrote:
| Can you expand? I don't get how you can use SSR with another
| language than Node. I always thought one has to use the
| static adapter.
| bkeating wrote:
| There is so much "let me just see if this works..." _tap tapppy
| tap_ .... "no... NO WAY... OMG IT WORKED!" with Svelte.
|
| Very little surface area. It embraces your knowledge of plain ole
| CSS/JS/HTML and empowers you with reactivity and a means of if
| being able to add motion to your ui.
|
| Newbs and Pros alike can build _fast_ with it. That speed +
| reactivity allows your software to better keep up with your
| converstaions that make it all so. Thats insanely powerful.
|
| It's soooo good. Congratulations to Richard Harris and everyone
| on the Svelte/SvelteKit Team! <3
| fruit2020 wrote:
| Except it forces you to use node js, or do I read it wrong? Can
| we get a streamlined js framework that is just about the
| frontend and let's you use whatever backend language you want?
| I know there is react, vue and angular but they seem so bloated
| pie_flavor wrote:
| Svelte is a frontend framework, which you can use to build
| anything from a full SPA to a single button. SvelteKit is a
| Node backend framework that integrates tightly with Svelte.
| yencabulator wrote:
| SvelteKit is a Javascript backend framework. It only uses
| Node at build time (with hopes of replacing even that with
| e.g. Deno), the deployed serverside component will happily
| run outside of Node.
| miohtama wrote:
| We are using SvelteKit frontend with Python backend (Pyramid
| + SQLAlchemy). When I started the project, I considered doing
| Python backend + templated HTML frontend a la Django, but
| SvelteKit server-side rendering was so good that I decided
| against this. Before I have done JSP, PHP, Django, Next,
| React and everything between, so I have some experience to
| compare. Despite all progress on Node.js backends, they still
| cannot compete with Python for complex SQL + ORM use cases.
|
| The frontend is open source and available here if someone is
| interested what a complex SSR heavy SvelteKit application
| deployment looks like:
|
| http://github.com/tradingstrategy-ai/frontend
|
| The SSR server is a lightweight Node.js web server (Vite),
| but you can have it nicely along your backend API web server
| (Pyramid in our case). Both are reverse proxied behind the
| same domain using Caddy.
| hamdouni wrote:
| Nodejs is only needed in the development phase.
| michaelsbradley wrote:
| That's true if you're developing a SPA or static site with
| SvelteKit. However, there are APIs that involve Node being
| run in production, i.e. the authors of SvelteKit envision
| it being used to build hybrid apps that involve front-end
| JS and Node.js server/s.
| yencabulator wrote:
| Yes, the whole point of SvelteKit is that it's
| SSR+hydrate. But it doesn't need Node for that. It'll run
| on just about any Javascript engine, including Cloudflare
| Workers which is quite close to pure V8 + standard web
| APIs.
| unsupp0rted wrote:
| I had the opposite feeling a month or so ago, especially with
| stores- there's so much "magic" that I kept running into
| confusing walls.
|
| If I `export let` a variable to be reactive over here, why
| isn't it reactive over there?
| samtp wrote:
| You seem to be conflating a few different concepts. Store are
| absolutely reactive across all components and pages. They are
| prefaced with $, and there are a bunch of native stores that
| you can use such as $page.
|
| You can even create variables reactive to one another by
| declaring a variable like so:
|
| $: y = x * 2
|
| Using the export let x = default; option is for passing data
| from the parent component/page to a child. If you want
| variable changes in the child to be reflected in the parent,
| you can use a store ($ notation), or you can use bind like
| so:
|
| <ChildComponent bind:x={someValue}>
|
| In my opinion, all of this is much much easier than in
| competing frameworks.
| unsupp0rted wrote:
| For instance I had a variable in a store.
|
| On my page, I had a script tag pulling from the store. The
| variable was reactive within the script tag.
|
| I export let that into the template via "data" props.
|
| I changed the value of the variable within the script tag.
|
| The template did not reflect the new value.
| samtp wrote:
| I'm really struggling to follow what you're trying to do
| - but why do you not just use the same writable store in
| both your page and template/component?
|
| Also, maybe look into store subscriptions and/or reactive
| declarations for what you're trying to do.
|
| Regardless, it sounds like you really need to just read
| the docs or do a tutorial.
| no_way wrote:
| I had exact same experience with it "it just worked", I started
| playing with few days ago and compared with other frameworks
| where I had to fight my to do what I wanted to do, from
| libraries to non oblivious behaviours. In SvelteKit it just
| works and it's refreshing. Especially love the builtin
| animation stuff.
| pier25 wrote:
| > _It embraces your knowledge of plain ole CSS /JS/HTML_
|
| Yeah that's one of the things I love about Svelte. It tends to
| enhance fundamental web knowledge rather than forcing you to
| think in convoluted ways.
|
| Features like actions put you close to the bare metal so to
| speak. I use those all the time.
| samtp wrote:
| Backing up how great it is that so much of Sveltekit is built
| using basic web standards. More often than not when I'm
| wondering what the shape of an object or function is in
| Sveltekit, I realize that it's exactly the same as you'd find
| on MDN documentation.
|
| It's an incredibly refreshing experience compared to other
| frameworks that create custom concepts for everything they
| do.
| culi wrote:
| This is what they said about React when it first blew up.
| Compared to Angular, it's much closer to being *just
| javascript(tm)*. But I wonder how well that'll hold up after
| the honeymoon phase
|
| The builder.io team made a tool called Mitosis[^0] that lets
| you input a component written in almost any framework and
| automatically recreate that same component in any other
| framework including Vue, React, Qwik, Angular, Svelte, React
| Native, Lit, web components, and even Swift
|
| It's always interesting to try out different frameworks and
| compare the plain HTML version of certain components with
| this tool
|
| [^0]: https://mitosis.builder.io/
| NetOpWibby wrote:
| I've been using Svelte for three years now, or close
| enough. The honeymoon phase hasn't waned.
| arxpoetica wrote:
| Unlike React/JSX, Svelte uses ASTs that adhere to HTML,
| JavaScript, and CSS (non-JSX) format. Yes, there is a
| minimal Svelte-only API footprint, but the native AST
| parsers means that parsing is much more respectful of
| correct code validation, versus JSX's own idiomatic set of
| ThingsYouCannotDo(tm).
| samtp wrote:
| It is absolutely crazy how much more idiomatic the Svelte
| code is in the example on Mitosis compared to the other
| frameworks on there.
| nicoburns wrote:
| > This is what they said about React when it first blew up
|
| FWIW, I think that "it's much closer to being _just
| javascript(tm)_ " statement has absolutely held up over
| time (Angular, esp. the old angular.js is painful compared
| to React for this reason), AND that Svelte is likely a step
| closer again (which they can do because they have an entire
| compiler and aren't reliant on embedded a DSL inside of
| JavaScript).
| culi wrote:
| I agree Svelte is a step closer, but most people agree
| that modern React has at least somewhat strayed from
| _just javascript_ (tm). Server components by default,
| hooks, JSX, synthetic events, etc have added many more
| layers of abstraction. I fully support these
| developments. I just think they're a necessary byproduct
| of a project maturing. I fear that if Svelte ever blows
| up past a niche framework, it will also stray from it's
| "use the platform" philosophy out of necessity as well
| Caged wrote:
| Svelte is such a pleasure to write and work with. It follows my
| mental model really well. Congrats to the team on this amazing
| milestone!
| nathias wrote:
| I'm a React expert, but whenever I can I choose Svelte, it really
| is a joy to use. I've been using SvelteKit for some time now,
| it's great to see it out of beta so I can shill it to more
| projects.
| onlyspaceghost wrote:
| Amazing!
| [deleted]
| mattwoodnyc wrote:
| There are a handful of them here - https://trpc.io/docs/example-
| apps
| swyx wrote:
| congrats team!
|
| the livestream and meta discussions around the launch are
| happening here https://www.youtube.com/watch?v=N4BRVkQVoMc
|
| theres a full in browser tutorial as well:
| https://learn.svelte.dev/
|
| I've been keeping a reference implementation of a SvelteKit blog,
| inspired by @leerob's nextjs site: https://github.com/sw-
| yx/swyxkit/ for the past year and it's now updated for 1.0. hope
| it helps someone get going!
| jdthedisciple wrote:
| I checked out the blog and it doesn't seem to be rendering the
| Markup correctly.
|
| For example the h2 headers appear literally as '## HEADER' on
| the website.
| swyx wrote:
| that is a stylistic choice on purpose - i actually add the
| #'s in with CSS - just makes headers stand out a little more
| :)
|
| i use h2, h3, and h4 often and just using font size alone
| makes it hard to tell which level of nesting the content is
| intended
|
| you can see this on my main blog https://www.swyx.io/
| davjhan wrote:
| Congratulations to the team!
| owlbynight wrote:
| If you're just learning SvelteKit, check this tool out:
| https://github.com/svelte-add/svelte-add
|
| It will save you a ton of time by making it really easy to add
| integrations to your projects (like Tailwind, Bootstrap,
| Supabase, Jest, etc)
| asdfdelta wrote:
| I've been following Svelte since it first appeared on the State
| of JS survey. So cool to see it evolve over time and happy to see
| all the hard work pay off!
| stephenstuder wrote:
| Svelte is soooo good. Hope it starts to get used more in large
| orgs.
| theonlytails wrote:
| congrats to everybody on the svelte team!
| Chipshuffle wrote:
| Is 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?
| grayrest wrote:
| > 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 that I am not
| aware of?
|
| Svelte is superb for producing NYT infographics and other
| relatively lightweight experiences. I work on interface
| builders and when you're scaling up the number of components on
| a page and the complexity then having the reactivity code
| repeated in the components instead of shared in a library
| becomes a drawback. What pushed me off of of Svelte was a ~500
| loc component that had ~40 reactions and resulted in a 4.1k LoC
| js file output. I looked through the output and didn't see any
| particularly egregious mis-compilations, just that the Svelte's
| approach resulted in verbose outputs. I don't think most people
| will have components this complex so I don't think Svelte is a
| bad choice and I do like the DX but that caused me to move on.
|
| Of the current options, I recommend Solid. It has fine grained
| reactivity all the way down, better perf, similar bundle size,
| and the community is generally performance obsessed. They're
| currently experimenting with islands/partial hydration/mixed
| server+client rendering and preliminary results are halving the
| delivered JS. As an example, their movies demo [1] is ~15k.
|
| [1] https://solid-movies.dev/
| swyx wrote:
| budibase is a notable interface builder in Svelte if anyone
| wants to compare https://github.com/Budibase/budibase
|
| and ofc huggingface gradio counts too
| https://www.svelteradio.com/episodes/gradio-with-pngwn
| hedgehog wrote:
| "This app requires modern web platform features. Please use a
| browser other than Safari." Looks cool but not production ready.
| bioemerl wrote:
| Every website should display this message until apple either
| fixes the browser or lets you install chrome.
| wirahx wrote:
| That's the tutorial - which uses WebContainers, which are
| indeed an experimental technology. It has nothing to do with
| the production readiness of SvelteKit the framework.
| b-lee wrote:
| That's for the interactive tutorial, not for the apps your
| build with Svelte/Kit.
| samtp wrote:
| I always wonder why Hacker News is such a magnet for comments
| trashing product announcements while also knowing almost
| nothing about the product being announced.
| hedgehog wrote:
| In the long run the approach Svelte takes seems very
| promising so I've kept an eye on it for a while now. I took
| umbrage at the snooty messaging towards a browser in a tool
| pitched as a way to "build production-grade websites".
| samtp wrote:
| Sure but the "snooty messaging" you're commenting on is
| from their tutorial, which is used to conveniently learn
| the framework in the browser.
|
| This has nothing to do with Sveltekit itself. You can
| download a demo repo, enter "npm run dev" and see that it
| works on Safari without any issues. Hell, I've deployed
| ecommerce sites using Sveltekit used by 500k people/month
| where 60% of visitors are on mobile Safari without any
| issues.
|
| So when a product is posted that you are unfamiliar with,
| maybe try giving it more that 30 seconds of consideration
| before dismissing it due to something completely unrelated
| to the product itself.
| Kuinox wrote:
| Safari is the new IE.
| fncivivue7 wrote:
| We had to support ie.
| rajasimon wrote:
| Wish it is but it's crazy fast with M1
| a3k wrote:
| Finally, I've been waiting for this moment for 2 years
| yamrzou wrote:
| There is a plethora of javascript frameworks: React, Vue, Svelte,
| Remix, etc. If I know nothing about front-end development, and
| would like to learn one that is:
|
| - Intuitive
|
| - Suitable for small projects as well as large projects.
|
| - That is here to stay, i.e. either adopted by many companies, or
| its adoption curve is going up.
|
| Which one should I pick? Would Svelte be a good choice?
| culi wrote:
| If it's for your career: React + (Next or Remix). Maybe Angular
| or Vue if the specific company you want uses it
|
| If it's for yourself: Svelte. Amazing community, very likely to
| be here in 5 years, but I don't think it's been proven to work
| at large scales yet.
|
| If you want to twist everything upside down and see the full
| potential of what front-end dev work could be: Qwik or Elm
| (imho)
| WXLCKNO wrote:
| What would be an example of large scale for a front-end app
| or site?
| culi wrote:
| 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 be used
| to make the frontend for a CMS, but you can also just get
| away with Wordpress, Squarespace, etc most of the time
| unless they want some really custom functionality. Then
| there's also micro-frontends and Astro and other related
| tools if you're trying to do a lot of different things and
| wanna mix and match different solutions to different
| problems
| sesm wrote:
| BTW, is CircleCI still using ClojureScript + React or
| they've changed their stack?
| swyx wrote:
| Elm hasnt had the momentum for years, its gonna be a long
| shot for it to go anywhere from here
|
| > but I don't think it's been proven to work at large scales
|
| i basically have this saved now:
|
| notable companies now using svelte not just for internal apps
| but customer facing, critical stuff:
|
| - huggingface (for everything, including gradio)
|
| - alaska airlines (entire customer flow)
|
| - razorpay (payment dialogs)
|
| - schneider electric (many things)
|
| - ikea (entire ecomm experience)
|
| - riot games (league of legends client)
|
| - Brave (search page)
|
| - Square (developer portal)
|
| - several YC startups
|
| - and basically every notable data journalism outlet on the
| planet (Bloomberg, the Economist, Reuters, Les Echos, german
| and japanese publications, pudding.cool, and of course the
| NYT)
|
| https://news.ycombinator.com/item?id=33827484
| culi wrote:
| Nice. I think the most significant one listed there is
| huggingface. It's very widely used but rarely "for
| everything". I think that shows most companies still aren't
| confident in it enough to bank everything on it quite yet,
| but it seems like we're pretty close!
|
| Edit: and yeah you're right about Elm. Probably not a good
| choice for first timers. But it's a great example of what a
| FE that adheres to functional programming philosophies
| could look like. Given React's recent developments I think
| the skills gained from trying it out would definitely carry
| over to React and other emerging frameworks. Although it's
| famously stable and error-free, it's not been battle tested
| for very large and complex apps so it's likely only a good
| choice for sideprojects atm.
| miohtama wrote:
| Svelte will be also the career choice in couple of years,
| like Angular was the career choice when React launched
| (although they have only 3 years between them).
| culi wrote:
| and before angular was jquery. But I do think there's quite
| a big difference between React and Angular. Angular never
| reached the level of marketshare that React has even if it
| was close. And even when it was close it was only for a few
| years. React has been the standard for nearly a decade now.
| And React has been much more explicit about growing its
| ecosystem whereas Angular has much fewer 3rd party
| plugins/tools. In addition to all that, Svelte has
| technically been around since 2016. Even if we cheat and
| say it only really started getting attention in 2018-2020,
| it has still been rising slower than Vue did when it
| launched. In the latest StackOverflow survey (2022), Svelte
| still hasn't even surpassed the 5% threshold for how many
| developers have used it.
|
| By pretty much every metric,[^0] svelte is a tiny community
| still. A darling of the web dev community for sure, but has
| not yet gained the confidence of commercial products.
| Perhaps this has actually been good for Svelte and its
| development. It definitely seems like it's heading towards
| much wider adoption so I guess we'll see it tested soon
| enough
|
| [^0]: https://gist.github.com/tkrotoff/b1caa4c3a185629299ec
| 234d231...
| have_faith wrote:
| > Suitable for small projects as well as large projects
|
| > That is here to stay, i.e. either adopted by many companies,
| or its adoption curve is going up.
|
| Arguably React for ecosystem and provability at every scale.
|
| > Intuitive
|
| Likely Svelte. React is mostly fine but hooks come with their
| footguns for newcomers.
| swyx wrote:
| remix isnt like those others in that you'd also need React to
| do UI
|
| at this point React Vue and Svelte are all decent production
| choices, as for what is intuitive that really depends what YOU
| like, different strokes different folks
|
| svelte is probably the most fully integrated toolkit
| (animations, state mgmt, server side rendering, serverless api
| routes, etc) and ships the least javascript at this point tho
| if u want the quick sales pitch
| apozem wrote:
| Probably React.
|
| - It works in small and large applications
|
| - Used in majority of new frontend apps
|
| - Reasonably intuitive, especially if you stick to functional
| components and aren't messing around with low-level renders
|
| That said, I enjoyed building a web app with Svelte. It's
| extremely simple and powerful. Its only disadvantage is it is
| new and has a fraction of the market share.
| dcre wrote:
| Svelte would be a good choice. It's important to note that
| there has been a ton of convergence in architecture, so for
| example, even though Remix uses React, the app architecture it
| encourages is quite similar to that of SvelteKit. So if you
| learn one, you would likely find the other familiar and easy to
| pick up.
| culi wrote:
| It's impossible to say this early. Still a very community-
| driven project. Rust was in a similar position at one point but
| it wasn't really until Mozilla took the helm that people felt
| confident enough to say "it's hear to stay". At this point it's
| been at least used by NYTimes, Facebook, Apple, Spotify, etc
| but I don't think any of these companies have a lot betting on
| it yet. It certainly has a huge following in the dataviz
| community and, for historical reasons, amongst journalists.
| Additionally it's regularly tops the State of JS surveys as the
| most loved framework. But none of that is really concrete imo
|
| If you're learning a new framework and you're concerned about
| stability React is still definitely the way to go. I think both
| React and Svelte are good at depending on generalizeable front-
| end skills that can carry over to other frameworks though so if
| your career doesn't depend on it, I don't think learning Svelte
| is a waste of time at all
| preommr wrote:
| I would strongly recommend Vue3 in the composition style with
| <script setup>.
|
| It's really close to svelte's style, of simplicity and
| principle of least astonishment. It also uses very explicit
| wrappers for reactive objects so that there's isn't as much
| magic happening. For me, vue's reactivity is order of magnitude
| simpler than things like svelte.
|
| Vue also has a pretty well established community and a pretty
| solid foundation.
| pastor_bob wrote:
| I can't remember a time I've seen a posting advertising use of
| Svelte on a team FWIW.
|
| The headwinds against React are strong.
| JonathanBeuys wrote:
| Why do you want a framework and not just plain HTML, CSS and
| Javascript?
|
| I have been doing frontend dev for over a decade and I never
| needed a framework. When I want to template data client side, I
| use Handlebars.
| veidelis wrote:
| You've never ran into DOM performance issues? You use a lot
| of createDocumentFragment? Please share more.
| didiraja wrote:
| Congrats all Svelte team and community, highly antecipated
| project. Played a lot with the early releases. To me, Svelte
| suite is the best option for front-end applications.
| KoljaL wrote:
| Great! Congrats to all the maintainers. I wish you will have a
| really really nice Christmas
| wirahx wrote:
| don't forget to watch the livestream!
| pier25 wrote:
| https://www.youtube.com/watch?v=N4BRVkQVoMc
| sergiotapia wrote:
| Congratulations on the milestone!
|
| I'm a bit confused, does this mean I can use Prisma with
| Sveltekit out of the box? It's server side rendered like a
| typical expressjs app?
| kenkunz wrote:
| Congratulations to the whole SvelteKit team!
|
| I've been using Svelte / SvelteKit for 1.5 years now - it is
| without comparison the most enjoyable and productive web
| framework language I've ever used.
|
| I'm lucky enough to work with Svelte / SvelteKit full-time. I'm
| gratified that the site I help build and maintain is included in
| the SvelteKit showcase: https://kit.svelte.dev
|
| Trading Strategy: https://tradingstrategy.ai
| lewantmontreal wrote:
| How so people feel about client side navigation? Browsing
| svelte.dev it appears back/forward navigation now requires a
| request each time as browser cache is no longer usable.
|
| Page refresh also seems to reset scroll position but that might
| be unrelated.
| swyx wrote:
| its just a setting now on sveltekit. clientside navigation is a
| single line of code
| dcre wrote:
| This appears to be deliberate depending on the page. Looking at
| the network inspector as I click around, I see cache-control:
| private, no-cache on the responses for docs content, but I do
| see caching on the blog pages.
| Lukas_S wrote:
| Sveltekit saves your scroll position in session storage so
| refresh and back/forward navigation feels like regular browser
| behavior. If your scroll position is resetting on refresh that
| may be a bug.
|
| Navigating back/forward will only make a new request if that
| page needs to fetch data in its +page.js component
| https://kit.svelte.dev/docs/load
| dimmke wrote:
| Congrats to the team for this!
|
| I have been building an application in SvelteKit and it's an
| incredible framework. I really believe it's going to become the
| dominant front-end framework in the next few years.
| pevey wrote:
| I completely agree except that I would say "full stack
| framework" instead of "frontend framework." Just add a db and
| you are good to go. I tried it out when building a couple of
| non-critical internal apps for clients (basic CRUD apps, but
| with some pretty complex business rules). SvelteKit is
| beautifully designed. It makes things that used to be a bit of
| a pain super easy to understand and implement. You can use
| pretty much any NPM vanilla js/ts library. The timing here
| could not be better for me. I will definitely be using SK for
| my next project.
| pier25 wrote:
| > _Just add a db and you are good to go_
|
| What about validation, CORS, cookies, encrypted sessions,
| etc? A backend (or full stack) framework should at the very
| minimum include those kind of things.
|
| It's a major gripe I have with all the new full stack
| frameworks. The focus is on rendering and dealing with
| requests but they are quite sparse in bread and butter
| backend features. Other than routing you're basically on your
| own.
|
| The community will probably start making third party plugins
| but I would rather have official plugins I can 100% trust
| like Fastify does.
| miohtama wrote:
| SvelteKit ships with a SSR server (Vite) and file system
| based routing out of the box. It does most of things,
| though not all. SvelteKit = Svelte + SSR + integration
| layer.
|
| Though I expect the situation improve a bit soon, as now
| SvelteKit 1.0 release is out from the door.
| pevey wrote:
| It's full stack because you write the code that you want to
| run on the server AND the code that you want to be shipped
| to the browser both within SK. Not because it does
| everything. You would want to choose your favorite
| libraries for those things, e.g., zod is my fave for
| validation.
| dang wrote:
| Related:
|
| _SvelteKit_ - https://news.ycombinator.com/item?id=29902450 -
| Jan 2022 (3 comments)
|
| _My Evaluation of SvelteKit for Full-Stack Web App Development_
| - https://news.ycombinator.com/item?id=29806385 - Jan 2022 (125
| comments)
|
| _SvelteKit Is in Public Beta_ -
| https://news.ycombinator.com/item?id=26557886 - March 2021 (114
| comments)
|
| _What 's the Deal with SvelteKit?_ -
| https://news.ycombinator.com/item?id=24996750 - Nov 2020 (2
| comments)
| batesy wrote:
| Well after reading the comments in this thread, I'm learning
| Svelte over the Holidays.
| gedy wrote:
| I enjoy Svelte a lot and congrats on the release. However the job
| market for Svelte seems really weak, at least for US dev
| salaries. I hope Sveltekit increases adoption, as it's a nice
| alternative to NextJS
| torartc wrote:
| Congrats team. SvelteKit is a great experience.
| arxpoetica wrote:
| The Sapper is dead! Long live the SvelteKit!
| gsanderson wrote:
| Congratulations! Watching the live stream now.
| newbieuser wrote:
| After a few minor versions, I hope they don't start to deprecate
| the newly added features.
| johninvirtual wrote:
| Congrats to all the people behind this, thanks for your work.
|
| I love svelte
| lairv wrote:
| Great news and looking forward to how this goes. I still find it
| incredible that the frontend javascript ecosystem hasn't found a
| reliable and productive contender yet, a framework you could be
| sure would be still relevant without too much changes in 5+
| years, something like what Ruby on Rails is for full-stack.
|
| Some would say that React/NextJS has this role but I have to
| disagree. When using React/NextJS you still have to rely on third
| party library for routing, state management, querying etc. like
| React-Query, React-Router, Redux (Next has a router but you still
| need libraries to do the rest). Some of these libraries change a
| lot, some become less relevant, new libraries emerge, and in the
| end when you start a React project you must go through the
| "library shopping" step.
| herrherrmann wrote:
| > When using React/NextJS you still have to rely on third party
| library for routing, state management, querying etc.
|
| You shouldn't need react-router or other routing-related third-
| party libraries because Next's router (and its file-based
| navigation system) should be enough(?). I'd also say that React
| itself has powerful-enough state management options (useState
| hook plus React context, if needed).
|
| The only annoyance I ran into was getting proper i18n working
| and integrated with Next (with i18next). There were some issues
| with Next's newer releases and a redesigned i18n setup that
| broke a lot of things for me and I regretted the dependence of
| multiple libraries and frameworks needing to work together.
| (Storybook is another library that kept breaking.)
| rglover wrote:
| > you still have to rely on third party library for routing,
| state management, querying etc.
|
| Take a peek at Joystick [1]. I designed it as the exact
| antithesis to this. It's full-stack (Node.js back-end with a
| fully ssr'd component framework designed for the long-term) and
| doesn't introduce any special paradigms (i.e., vanilla HTML,
| CSS, and JavaScript--no attribute tricks/compilers needed).
| Everything is designed to be a fixed-API with the only changes
| being added functionality (i.e., no random "hey this is
| deprecated now" rug pulls).
|
| Philosophy is described here:
| https://github.com/cheatcode/joystick#what-distinguishes-joy...
|
| [1] https://github.com/cheatcode/joystick
| lairv wrote:
| Will take a look at it, and good luck with building it, such
| projects requires effort and test of time
| rglover wrote:
| Thank you, appreciate that. If you have any questions feel
| free to contact me directly: ryan.glover@cheatcode.co.
| oxff wrote:
| Why is there a new frontend-whatever-work / tool every week?
| Database stuff is fairly stable, so is backend stuff. Browser
| APIs seem stable to me too? Why can't you guys decide that this
| is how things are best done
| didiraja wrote:
| if you know what you were doing on front-end you wouldn't
| spelling this words aberration compilation
| oxff wrote:
| I really don't know, that's why I asked.
| rk06 wrote:
| Because it is a not a new js framework, but a higher level tool
| based on a js framework I. E. svelte.
|
| Similar meta frameworks exist for other js frameworks eg:
| Next(react), Nuxt(vue), Remix(react), rakkas(react),
| Solidstart(solid) etc.
| arxpoetica wrote:
| SvelteKit is nothing new. It's been kicking around for 2+ years
| with tons of user satisfaction (and 3 years prior to that under
| another name), but this is the first major/stable release.
| - https://insights.stackoverflow.com/survey/2021#section-most-
| loved-dreaded-and-wanted-web-frameworks -
| https://2021.stateofjs.com/en-US/libraries/front-end-
| frameworks/ -
| https://twitter.com/Rich_Harris/status/1589675637195042817
| anon291 wrote:
| As someone who's written both a GUI framework and a database
| library for Haskell, the answer here is actually really
| obvious. There's only a small set of algorithms for database
| query execution, all of which are well understood. Thus, there
| are best algorithms that you can implement.
|
| On the other hand, there is no correct way to style, animate,
| interact with, etc a button. The design space for UX is much
| larger than that of databases, and existing libraries touch
| maybe a small percentage.
| ericmsimons wrote:
| Congrats to Rich & team- SvelteKit is an amazing experience to
| develop with. Excited to use 1.0 on some new projects!
| rohanrajpal wrote:
| Congrats team, we've built a HUGE SaaS with Sveltekit + NestJs
| and it has been a wonderful experience
| keyboards wrote:
| Thank you so much for this. I love Svelte to bits.
| joeldrake wrote:
| Hurray!
| akmittal wrote:
| Congratulations to the team for releasing this.
|
| For someone who hasn't followed svelte closely, How much JS
| sveltekit ship by default using SSR
| swyx wrote:
| its up to you - you can ship 0 kb of js if you want by turning
| off client side rendering https://kit.svelte.dev/docs/page-
| options#csr
|
| and you have this choice on a per page basis rather than having
| to choose between a static site generator or a full SPA
| akmittal wrote:
| 0kb is best size of JS. Curious if I do want JS, how much is
| extra framework overhead
| crucialfelix wrote:
| 3kB
| swyx wrote:
| as compared to nextjs' ~150kb baseline? (not a real
| number im just guesstimating)
| crucialfelix wrote:
| 79.46 kb which includes React. That's never where the
| bloat comes from.
| ovao wrote:
| It's not directly comparable. Svelte apps have an
| extremely minimal runtime, because Svelte compiles
| components into largely freestanding chunks of code.
|
| The benefit is that for smaller apps, SvelteKit can be
| extremely lean, but the cost grows as the number of
| components and pages increases, since a number of
| attributes can't draw from a larger, monolithic runtime
| (or set of runtimes).
|
| You do have to build moderately large apps to hit the
| point at which it's a drawback however.
| xiphias2 wrote:
| Thanks for finally having a SvelteKit tutorial :)
|
| I was using SvelteKit, but I really need the tutorial to get
| better at it (also to adapt better to the changes that have
| happened).
| yawnxyz wrote:
| For anyone who might have missed the announcement hidden in the
| launch video, there's Svelte Auth now from the Vercel NextAuth
| team: https://vercel.com/blog/announcing-sveltekit-auth
| doodlesdev wrote:
| Wow that's huge. Might need to find something to try out
| SvelteKit now. Loved Svelte already and I was only waiting for
| a 1.0 of SvelteKit.
| joeconway wrote:
| Congratulations to the team, you've built something really
| excellent
___________________________________________________________________
(page generated 2022-12-14 23:00 UTC)