[HN Gopher] Thoughts on Svelte(Kit), one year and 3B requests later
___________________________________________________________________
Thoughts on Svelte(Kit), one year and 3B requests later
Author : thunderbong
Score : 290 points
Date : 2023-06-22 03:09 UTC (19 hours ago)
(HTM) web link (claudioholanda.ch)
(TXT) w3m dump (claudioholanda.ch)
| swyx wrote:
| as someone close to the Svelte community, i think the "lack of
| protagonism" comment is due to the relatively loud voices of
| those mentioned names.
|
| however the activity in svelte genuinely has picked up year to
| year. you can follow Svelte Society on Twitter and YouTube to see
| the many projects going on, in particular
| https://twitter.com/SvelteSociety/lists for people building and
| teaching and evangelising Svelte. they're out there! just
| necessarily smaller because they got started later + have less
| funding from Facebook.
| XCSme wrote:
| Will Web Components ever replace those front-end libraries? What
| are they lacking?
| yawnxyz wrote:
| > Reactive declarations and statements are useful features, just
| remember not to abuse them, otherwise you may end up switching
| Svelte's productivity by headaches and infinite debug sessions
|
| I wish they got into more of that; I've heard of stories but I've
| never run into this after several years of building Svelte
| projects, so I'd love to learn so I don't make those mistakes
| myself
|
| > Svelte's lack of protagonism
|
| This doesn't look like it reflects on the system itself? I'd
| rather have something that works well and doesn't focus on
| flashy-ness. I guess the real downside is that there are such few
| plugins / tools for Svelte compared to React, but with Rich
| Harris working with Vercel on Svelte, I can only see things go up
| from here -- like Vercel AI having out of the box Svelte support.
| andrewstuart wrote:
| You need very strong argument not to take the most popular
| technologies these days.
|
| I don't hear any arguments against react here strong enough to
| justify not choosing VueJS or React.
|
| It's not in the interests of your client.
| sfg wrote:
| He said that he couldn't have met the deadline without Svelte.
| orangepanda wrote:
| Of course it could have been done without Svelte. Thats the
| only stack their team know and/or wanted to work with.
| Nothing wrong with that, but would be nice if they were more
| upfront about that instead of "impossible for a different
| solution to exist".
|
| There was a psychological term for it, making a decision
| first and only then finding supportive arguments in favour of
| the decision?
| sfg wrote:
| He's worked with React and Svelte. He didn't think he could
| get it done in time with React. How do you know he is
| wrong?
| fud101 wrote:
| how does vuejs belong in the same sentence as React and
| popular?
| bunga-bunga wrote:
| There are plenty other articles for them. Not every
| _alternative_ article has to denigrate the incumbent.
| colordrops wrote:
| Standards-based is really the only thing that challenges react
| these days, i.e. raw JS with es modules, web components, and no
| build step/bundling. It only works in certain situations
| though, but when it does work, it's _so_ much better than the
| giant web of black boxes and indirection that is the React
| universe.
| WA wrote:
| Potentially true, but this doesn't give you reactivity or
| state management.
| KronisLV wrote:
| > Standards-based is really the only thing that challenges
| react these days
|
| I feel like Vue would be a better fit for this role,
| especially since now they have a Composition API that's as
| pleasant to use as React, except that they do lifecycle hooks
| better than React (no messing about with dependency arrays):
| https://vuejs.org/guide/extras/composition-api-faq.html
|
| There's also Pinia which is a lot simpler than trying to use
| Redux, it's closer to MobX: https://pinia.vuejs.org/
|
| There are also plenty of component libraries, like PrimeVue:
| https://primevue.org/
|
| Seriously, the only actual complaint I have about Vue is that
| the 2 to 3 migration wasn't all that pleasant (albeit not as
| painful as what Python dealt with hah).
|
| Oh and for more complex use cases (like what Next provides),
| there is Nuxt: https://nuxt.com/
| yurishimo wrote:
| Vue 3 is seriously an amazing piece of tech. Nuxt is going
| after the same DX of Next but without all of the big
| company IPO baggage behind it.
|
| Vue also takes a lot of inspiration from compiler first
| frameworks and will be implementing an optional API to
| bring those optimizations to core in a coming point
| release.
|
| I agree with you that hooks are a great feature that many
| React devs would probably enjoy using.
|
| The only downside to Vue atm is the lacking _comprehensive_
| community support for libraries like `react-aria` and
| `framermotion`. I think the community is working on ports,
| but we all know that sometimes ports make compromises that
| might miss the nuance of the primary library author
| thinking about those problems directly in relation to the
| target client.
| 9dev wrote:
| I like Vue as much as the next guy, but comparing Nuxt to
| Next doesn't really do Next justice. Nuxt is pretty much a
| glorified blog engine, a conceptually broken tech demo. Its
| performance is abysmal, the developer experience
| frustrating, and many things that seem convenient when you
| read the docs turn out to be a hassle in production.
|
| Next is so much more refined compared to that.
| barrongineer wrote:
| This description of Nuxt 3 couldn't be further from
| reality. Performance is on par with anything else I've
| tried (SvelteKit, Remix, Next) and the DX (module
| ecosystem, layers, auto imports, vite, etc ) are actually
| what's made it my default.
| miohtama wrote:
| Often choosing the most popular is like "Million flies cannot
| be wrong, shit is good." New technology is created to improve
| things, so it would not exist and people would not use it,
| unless there is something to improve.
| slimebot80 wrote:
| Can we see the news site?
|
| (also wouldn't mind a follow up article on hosting such a busy
| site!)
| spyke112 wrote:
| Lost me at building a custom CMS for the MVP, or did I
| misunderstand?
| rizky05 wrote:
| [dead]
| coolgoose wrote:
| Nope, that's my feeling too. Somehow for a news site mvp in
| 2023 we still reinvent the wheel.
| loktarogar wrote:
| It was a replacement for an existing website (requirements
| are well known), so a custom CMS being part of what they were
| hired to build and an MVP of that CMS being what they're
| talking about isn't so irrational.
| foota wrote:
| It's a storied tradition.
|
| (I know that at least Django was written for a news site)
| [deleted]
| jer0me wrote:
| Svelte was written for a news site!
| wg0 wrote:
| What other off the self solutions you'd recommend for such a
| news website?
| mozey wrote:
| > by wrapping a vanilla lib to a component or an action, you've
| essentially created basic Svelte version of that lib
|
| This is the key to making framework churn go away. The DX of
| using vanilla JavaScript is getting better every day. And is a
| much better experience than it was a decade ago.
|
| > Islands architecture and partial hydration can help you render
| static HTML with just a small portion of JavaScript for those
| components who need it
|
| I'm doing this with Hugo for rendering the static parts, and htmx
| for loading hydrated partials. The HATEOAS approach simplifies
| state management in the application. There is no client side
| "routing", just links and the back button.
|
| In addition to vanilla libs, I include one "app.js" bundle. This
| file is created with esbuild and linted with deno. My "business
| logic" can be written in TypeScript in VSCode with the Deno
| extension and LSP server.
| graftak wrote:
| This is all fun and games until you work on a platform that
| requires dynamically loaded modules, error boundaries and
| suspense (or another form of components loading their own data)
| and then the no-nonsense approach falls flat.
|
| It is easy to put your nose up towards bloated frameworks when
| you're doing small (static) stuff but as soon as you need the
| bloat you're just reinventing a wobbly wheel without one.
|
| There's always an air of disdain against front end frameworks
| on HN but people often project their own not-needing-a-
| framework on the tool itself.
| white_dragon88 wrote:
| I work on a huge angular project and I can't help but see
| svelte as a toy in comparison. Must be nice when everything
| just falls into place.
| continuational wrote:
| What are you missing in Svelte?
| junon wrote:
| Maybe it's because angular is like dropping a nuke to kill
| a spider?
| mozey wrote:
| > dynamically loaded modules, error boundaries
|
| In an MPA, modules https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Guid... can be included on the pages
| that require them with a script tag. Errors (and new
| features) are limited to a specific page, and the rest of the
| site remains unchanged.
|
| > suspense (or another form of components loading their own
| data)
|
| The htmx lib https://htmx.org/ mostly takes care of this:
| "gives you access to AJAX, CSS Transitions, WebSockets and
| Server Sent Events directly in HTML". The hx-boost tag can
| also be used for progressive enhancement.
|
| > as soon as you need the bloat you're just reinventing a
| wobbly wheel without one
|
| When building a rich client, using a framework could be
| productive. For example a photo/video editor app. For a news
| site and CMS I would probably stick to the approach I've
| described above.
| chasd00 wrote:
| doesn't the csp issue in htmx basically make it a non-
| starter for most applications? maybe that's been fixed
| somehow..
| mozey wrote:
| The hx-disable attribute can be used to disable htmx for
| parts of the DOM that load user generated content, is
| that what you're referring to?
| https://htmx.org/docs/#security
| revskill wrote:
| If SvelteKit supports streaming Server Component, i'll move.
| siquick wrote:
| - "hmm, I'll try this crazy approach, but will the framework even
| accept that?" - "..." - "whoa, oddly enough it did... Alright
| then, next task..."
|
| This sounds like the opposite of a nice DX for anyone but the
| engineer who wrote the original code.
| sametmax wrote:
| I like the fact minimalist approaches, like svelte, htmx and
| alpine.js are getting more and more traction.
|
| I felt like fighting this fight alone for years in the golden
| years of node, webpack and react where everybody was creating
| crazy stacks and adding GraphQL and so on, to basically get what
| Django + jquery did 10 years ago in a tenth of the time and code.
|
| So far I also survived:
|
| - xml is the future
|
| - let's use nosql for all the things
|
| - you must use the same language at the back and front
|
| - yes, you site must have an AMP version (ah, you forgot this
| one, didn't you? It was sooo imporant, and then pouf, it was gone
| like tear in the rain)
|
| - yes, your home page must be an SPA
|
| - you can't code anything without async
|
| - you can't live without a message queue
|
| - everything must become a micro service
|
| - of course you need a container for that
|
| - of course you need a orchestrator to organize those containers
|
| - of course you need the cloud, it would be crazy to deal with
| those containers and orchestrators yourself
|
| - dude, why do you have a server? Use a serveless backend!
|
| - dude, why do you have a backend? Just call saas from the edge!
|
| Every year, some generation of engineers have to learn the
| concepts of "there is no silver bullet", "use the right tech for
| the right problem", "your are not google", "rewriting a codebase
| every 2 years is not a good business decision", "things cost
| money".
| JodieBenitez wrote:
| Wouah ! Sam&Max, je me demandais bien ou vous etiez passe.
| hardwaregeek wrote:
| Honest question: how is htmx/svelte/alpine any different than
| other trends? Could it just be that you prefer this particular
| spot in the trend cycle?
| comte7092 wrote:
| I think that's parent comments point. They like that the
| trends are swinging from complexity to simplicity.
| kubb wrote:
| why not just use pure typescript + postgres + go/java? all
| these libraries bloat your app for no good reason
| DigitalSea wrote:
| One of the exact reasons I've been working with Aurelia as my
| Javascript framework of choice since 2015. Aurelia 1 has served
| me well and I have apps that have been in production for eight
| years untouched. They just keep running without fail and
| they're so simple. Similarly, Aurelia 2 (currently in beta) is
| even better and as stable (same templating syntax, DI, etc). I
| tend to avoid all of the hype in the front-end space. The only
| thing clients and companies care about at the end of the day
| are results.
|
| - Simple syntax
|
| - Convention over configuration, but gives you the ability to
| configure it when you need too
|
| - Standards compliance
|
| - Has state management, routing, validation, Fetch client and
| translation packages
|
| - Completely written in TypeScript, so everything is strongly
| typed
|
| - Great docs
|
| - HTML templating syntax is standards compliant, so everything
| looks similar to native HTML. None of this weird curly, banana
| in a box, square bracket and weird symbol nonsense that is not
| intuitive.
|
| People always ask, "Why not React?", "Why not Vue?", "Why not
| Svelte?", etc. People think you need to use the most popular
| option like it's a popularity contest. I find it laughable to
| build a React application in 2023 you don't just `npm install
| react`, people tell you to use something like Next.js which is
| a framework built on React (the very thing developers tried
| arguing for years you didn't need to build apps and that
| libraries were enough). I can guarantee that most of the people
| in this comments section either tried Aurelia years ago when it
| was v1 or have never heard of it. Then you would have some that
| won't use it because it's not big or popular enough.
|
| I can build an app using Aurelia faster than most developers
| could using React or any other convoluted framework or library.
| Even Vue used to be nice and basic, before Vue 3 where they
| decided they would become React Lite and introduce complexity
| in the way you build things because everyone bought into the
| myth everything has to be functions and classes are bad.
|
| At the end of the day the safest strategy is to use what works
| for you and ignore everything else.
| duringwork12 wrote:
| I used to love knockout.js. this brought memories
| stephenhuey wrote:
| 2015 was when I used Aurelia, too. As someone who used the
| first version of Angular, it was a breath of fresh air, and I
| agree that you can get results quickly using Aurelia. I left
| that company so haven't been using it, but I've secretly
| hoped people would catch on and switch to it somewhere down
| the road. But as you say, it's fine that it's not popular--
| quite often, the best things are not the popular things.
| andsoitis wrote:
| > you can't code anything without async
|
| I'd like to understand what you mean by this. As soon as you
| introduce network requests in a system, don't you need to deal
| with asynchrony?
| ehnto wrote:
| You can just wait for the network request to finish before
| continuing. Many actions require it anyway.
|
| Asynchronous code should be intentional and deliberate in my
| opinion, but in modern JS/Node it is the default which leads
| to all kinds of crazy workarounds, callback hell and race
| conditions. Node has the same issue PHP had now, where green
| devs will crank out code without realising they need to be
| watching out for these things.
|
| Is it cool that a .forEach loop could be async? Heck yeah,
| should it be the default? The shit people write around
| .forEach loops suggests, maybe not!
| c-hendricks wrote:
| What's not deliberate about marking a function as `async`,
| and marking calls that need to be awaited with `await`?
|
| Callback hell? When was the last time you gave an honest
| effort into JavaScript?
| aobdev wrote:
| Everything in JS started with callbacks, then promises came
| on to the scene with libraries like Bluebird, then the
| async/await syntax was added to the spec. The language was
| always able to handle concurrency but it was a long road to
| the current state.
| pmarreck wrote:
| Ha, tell me you've been a full stack dev for over 10 years
| without actually doing so... ;)
| xkcd1963 wrote:
| Software itself hasn't "evolved" over the last 40 or 50 years.
| It only ever gets better because the hardware becomes better.
| There is no true innovation in software development. Folks that
| "innovate" either reinvent the wheel or capitalise on hardware
| improvement.
| [deleted]
| [deleted]
| amadeuspagel wrote:
| I love svelte, but how is it minimalist? How is requiring a
| compiler for a web app minimalist?
| cageface wrote:
| I like Svelte but I'm not sure I'd describe it as "minimalist".
| It's a new language with its own compiler and reactivity
| system.
| RamblingCTO wrote:
| Yeah, I did a project in sveltekit + go and then one in htmx,
| alpinejs + golang. Sveltekit is quite big and not low
| maintenance.
|
| Not sure what exact use case sveltekit would be good for,
| that can't be solved with htmx + alpinejs.
| devbent wrote:
| Svelte by itself is super tiny.
|
| Sveltekit does a lot more stuff and is accordingly bigger.
| biomcgary wrote:
| htmx, alpinejs + golang is the exact stack I've been
| thinking about. I'm not a front-end developer, but want to
| be able to prototype things quickly. Are you aware of any
| public examples of this stack that go beyond "Hello,
| World!"?
| ravenstine wrote:
| [removed]
| 10xDev wrote:
| Reactive declarations that work using syntax outside of JS
| thanks to the compiler does make it a bit more than just
| JS. https://twitter.com/youyuxi/status/1057291776724271104
| pcthrowaway wrote:
| Kind of like how JSX is actually JSXScript, sure
| zdragnar wrote:
| JSX is, imho, more akin to a macro; the syntax is
| replaced with simple expressions. Technically, the JSX
| syntax isn't even necessary to use React, though most
| people prefer it.
|
| Svelte bakes itself fully into your code in a way that
| you can't do without the compiler and still be using
| svelte.
| waboremo wrote:
| JSX is necessary to use React otherwise you create even
| more footguns in a library that's littered with them.
| cassepipe wrote:
| So you're saying that svelte does not _just_ transpiles
| to js /css/html ? Could you expand on that a bit more ?
| npsomaratna wrote:
| This reflects my experience from the 00's onwards. Survived and
| avoided most of these--except the nosql bandwagon. A worn out
| and wiser man, ended up switching back to relational DBs
| several years later.
| lewhoo wrote:
| Unfortunately it takes time and experience to filter out the
| hype and marketing but hype and marketing usually acts against
| good experience. I thought something is wrong with me when a
| thought came to mind that (early) no-sql really really could
| use relations. People said I'm silly for trying to make no-sql
| sql-like.
| tarkin2 wrote:
| > it takes time and experience to filter out the hype and
| marketing
|
| When you have that experience, you subsequently apply for
| jobs that demand you be up-to-your-elbows in the over-hyped
| and over-marketed tech.
|
| The industry, eagerly lapping up any and all shiny-marketing
| and advocacy, financially incentivises bandwagon-jumping over
| listening to experience.
| danjac wrote:
| I think (or rather, hope) that this is a symptom of the low
| interest-rate era, and companies may be less willing to
| waste money and development cycles on chasing the latest
| shiny.
| papito wrote:
| It's the second, younger generation of devs who are realizing
| that "complexity kills". Those of us who started in 2000's have
| already seen this. It's a natural cycle. We are seeing a
| spring-back to monoliths and away from micro-services and crazy
| tooling chains.
|
| It was completely unnecessary, and most importantly, cost the
| industry a fortune. If you are older, you have been wondering
| why you need to work more to achieve less. To me this has been
| demoralizing, and actually put me through some tough cycles of
| depression. I no longer enjoy this job. I used to DO things and
| walk away from my desk every day having a sense of achievement.
| Now it takes 3 days to set up your microservices locally just
| to reproduce a bug, apparently because your system with
| moderate traffic needs to look like Shopify.
|
| Bad example - Shopify is a monolith.
| azangru wrote:
| > it takes 3 days to set up your microservices locally
|
| Why do you need all microservices locally? Why wouldn't you
| set up just the relevant one, and proxy the traffic to the
| rest of the services already deployed? Or, failing that, why
| don't you have a docker-compose file that has already pre-
| configured your services to run locally?
| Gasp0de wrote:
| I think technology choices should be made depending on the
| team. If you have 5 teams with 10 people each, then it is a
| great idea if your service is comprised of 5 microservices
| that talk to each other across team borders through well
| defined APIs. If it takes you 3 days to run your microservice
| locally, then you somehow didn't set up your development
| environment when you should have.
| chasd00 wrote:
| > If you have 5 teams with 10 people each, then it is a
| great idea if your service is comprised of 5 microservices
|
| i've always thought a micro-service architecture should be
| decided and defined by the org chart and not technology.
| gpderetta wrote:
| > If it takes you 3 days to run your microservice locally,
| then you somehow didn't set up your development environment
| when you should have.
|
| The fact that setting up your dev env takes such complex
| rituals and incantations that need to be prepacked in a
| spellbook is itself a red flag.
| EnragedParrot wrote:
| A well-tooled development environment takes minutes to
| set up.
| papito wrote:
| A well-tooled environment does not just spring out of an
| ether. Maintaining proper tooling in a distributed system
| often requires more work than the system itself. In a lot
| of cases, the business does not even consider this kind
| of time commitment, pushing the team to churn out
| features, and who eventually just bog down in insane
| complexity.
| EnragedParrot wrote:
| This strikes me as a, "poor carpenter blames his tools"
| situation. Obviously if a business does a bad job
| considering the needs of their engineers then the needs
| of their engineers won't be met, but that doesn't mean
| that the modern development environment is the problem.
| gpderetta wrote:
| Well, if the tool is a Swiss Army Chainsaw and you just
| need to cut a piece of paper, just maybe the carpenter is
| not fully to blame.
| yurishimo wrote:
| > then you somehow didn't set up your development
| environment _when you should have._
|
| This is great! ...in theory. But why do so many teams seem
| to have these kinds of problems? I think we have to come
| into these conversations with an over abundance of good
| faith that people are trying their best. Something in this
| microservice architecture conversation of the past decade
| isn't working as elegantly for a huge portion of the
| devshops that try it.
|
| People _should_ do lots of things, but that doesn 't mean
| they always get done. There is merit to the argument that
| you may do things in a simpler way and adopt a different
| approach to cross team communication and complexity
| management. Your final sentence reads as a moral judgement
| equivalent to "your doing it wrong" without offering a
| solution.
|
| We've had a decade of telling people they're doing it wrong
| and it's still being done with the same problems over and
| over and over again.
| EnragedParrot wrote:
| This sounds like a symptom of you falling behind the
| technology curve more than a problem with the technology
| curve. Most people are achieving _vastly_ more with newer
| tech than ever could have been done in the early 2000s. You
| 've gotta be looking through some densely rose colored
| glasses if you think that that the web in the 2000s was just
| as powerful as the web of today.
| papito wrote:
| I resisted learning a lot of it knowing that there will be
| a snap-back to simpler designs long-term, and it's
| happening now.
|
| And when I tried, it went nowhere. After months of work on
| my side project with Electron, Typescript, and Vue, I was
| in the same place because every time I opened IntelliJ, it
| seemed all of my effort went into _just having it build
| again_.
|
| Now I chose ArrowJS for my project, and it's been a
| delight. Look, I get it, but I would refrain from accusing
| the other person of laziness in this case.
|
| Learnings from 5 years of tech startup code audits:
| https://kenkantzer.com/learnings-from-5-years-of-tech-
| startu...
|
| The very first two points prove that it's not just me.
| EnragedParrot wrote:
| I don't think there is laziness in falling behind the
| technology curve - the things that worked ten years ago
| still work today and if you're shipping code then what
| you're doing is working. But new technologies aren't
| overly complex and they generally make a developer's life
| easier, not harder, but they all come with a learning
| curve. And the landscape evolves quickly, so in order to
| leverage them you have to stay on top of it.
| [deleted]
| tacker2000 wrote:
| Exactly my words!
|
| The only thing that I would single out here as actual progress
| is the container thing. This really has helped me a lot, with
| local dev and deployment. I havent touched any orchestration
| like k8s yet though, so I am still on the "lite" side.
| rgrieselhuber wrote:
| Totally agreed on containers but I've noticed so many
| developers promptly ignore using the containers that are set
| up for them when developing locally. Then days are wasted
| again on deployment issues down the road.
| ehnto wrote:
| The issue I always run into is that containers don't get
| maintained. I have never encountered a project where a
| container "just worked".
|
| I absolutely love them when they do, but they have wasted
| so much of my time when they don't that I just skip them
| now. It takes me 5 minutes to set up a local env, and with
| a staging env at parity with production to test on there's
| never any issues.
| tacker2000 wrote:
| Do you mean you skip the project's container config and
| set up your own? Or just skip containers entirely?
| jonatron wrote:
| There's a HN world of what's gaining traction and what
| "everybody" is using, and the real world reality. If I search
| for Django jobs on indeed, I get way more results for Django
| than if I search for Svelte (183:11). If I ctrl+f on "Who is
| Hiring?", the ratio gets a lot closer (13:4).
| pmarreck wrote:
| Chasing what's popular right now is a recipe for ending up in
| a has-been tech
| prometheon1 wrote:
| I think sametmax was saying that "everybody" is using React
| for usecases that Django could do long ago, and that Svelte
| is in the "gaining traction" category.
|
| On indeed.com I get 311 Django jobs and 3421 React jobs so in
| that sense it looks like "everybody" moved from Django to
| React.
| EnragedParrot wrote:
| I hear the argument being made, it just doesn't make any
| sense. We are using React to do things vanilla JS could do
| eyears ago. That doesn't mean React doesn't make doing
| those things easier. I like Svelte as well, but it likely
| wouldn't exist today without lessons learned from other
| frameworks like React.
| [deleted]
| a_c wrote:
| The list is not complete without mentioning the site has a
| total number of users equal to or less than the amount of
| people you can spam and still consider you a friend
| EMM_386 wrote:
| > Every year, some generation of engineers have to learn the
| concepts of "there is no silver bullet", "use the right tech
| for the right problem", "your are not google", "rewriting a
| codebase every 2 years is not a good business decision",
| "things cost money".
|
| Ah, yes, the wheel of time. I've been through all of the things
| you've listed and more. My first job programming was in 1996
| and involved HTML/JS/CSS and SQL. JS came out in 1995. CSS in
| 1996.
|
| First it was cgi-bin, ASP, then ASP.Net and ASP.Net MVC, now I
| work with SPAs. When I hear the term "SSR" it instantly throws
| me back 20 years, when _everything was_ server-side rendered.
|
| As you mentioned, it's the same with things like SQL. When
| JavaScript exploded, we got NoSql, because it's easy to toss
| JSON into a KV store. Then a few years later, you see many more
| posts about people discovering how powerful relational SQL is,
| or awesome SQLite is, etc. It's the next generation realizing
| that things may have been done a particular way for a reason.
|
| On the front-end, I work with enterprise Angular now. I have no
| desire to move on to the next shiny object/framework, because
| if it's bleeding-edge, that means the community is small. And
| if it doesn't explode in popularity, that community will
| disappear and you'll be left with an application running on
| something nobody knows. I try to keep pace with Angular's 6
| month cadance and so far, so good. My current project has gone
| from 13-16 without any issues.
|
| And don't get me started on microservices. Get off my lawn.
| stcredzero wrote:
| _> Ah, yes, the wheel of time. I 've been through all of the
| things you've listed and more._
|
| Heh. "The Wheel of Time." It's a very good name for what Alan
| Kay called, "not quite a field." In the modern era, fields of
| knowledge aren't supposed to forget what they learned every 5
| years or so.
| davej wrote:
| We have recently moved our website[1] to SvelteKit. Previously we
| were on Sapper. Previous to that we used a custom Webpack + React
| setup to output a static site.
|
| Our desktop app builder is also built on Svelte (not SvelteKit).
|
| I agree with pretty much everything in this article. I wouldn't
| put "Reactive declarations and statements" in the "Ugly" section
| though. They are definitely a bit tougher to fully grok than the
| rest of Svelte (Svelte is incredibly easy to learn compared to
| other frameworks) but once you learn how they work they are
| incredibly powerful and concise.
|
| I also feel like "Svelte's lack of protagonism" is a bit off the
| mark. Rich Harris is a great communicator and tends to be pretty
| public but the focus is more on community. Svelte Society's
| Youtube channel [2] does a 1 hour long "This week in Svelte"
| video every week and it is all killer content with no filler.
|
| [1] https://www.todesktop.com [2]
| https://www.youtube.com/@SvelteSociety/videos
| wg0 wrote:
| I don't want people preaching hooks as the greatest invention
| since fire talks anyways. Such code if spotted anywhere in a
| backend would be slammed for being horrendous and violating
| almost any intuition definition of maintainable code.
|
| The svelte documentation is already great. This evengleism is
| good for commercial products. For technical open source,
| subjective evaluation is all that is needed. You evaluate
| whether it fits for your needs, you adopt or not.
|
| Not everybody is walking into conferences and sticking swag on
| back of their notebook lids.
|
| Rich Haris seems a humble great guy and he's doing good enough
| IMHO.
| Capricorn2481 wrote:
| Rich Harris is definitely not a humble guy. He pretty much
| can't talk about Svelte without framing it as the savior to
| modern web. And I would say some of the things he pushes are
| blatantly false
| cassepipe wrote:
| The things that bit me with svelte's reactive statements is
| that they are run _at the end_ of componenent initialization
| (but they are part of it, unlike onMount 's arg)
|
| Now I always keep my reactive statements below my regular js
| statements, to remember.
|
| Also I think it would have been clearer to call onMount,
| afterMount
| mr90210 wrote:
| I gave up the Javscript rat chase, for now I am sticking with
| React.js.
|
| Svelte has been around for years, and in my opinion it won't
| really gain that much traction anymore. (It's just an opinion,
| let's not be religious)
| synergy20 wrote:
| same here for my SPA.
|
| even react is shifting more from CSR to SSR,I wonder when I
| will just switch back to Django with htmx and leave react all
| together if SSR is what I need.
| thomasfromcdnjs wrote:
| How to build a custom CMS and new frontend codebase in 2 months
| that can handle 3 billion hits per year in a corporate setting.
|
| Would be more interested in how your work flow was managed.
| katzgrau wrote:
| > After several meetings, we came to the conclusion that the best
| approach was to simply halt the old website development and build
| a new one from scratch using the best technologies and practices.
|
| Spoken like a true developer. Trash the old system, reinvent the
| wheel, prioritize the delight of the devs, leave the client with
| something that is totally obsolete and nobody else knows how to
| work on in a couple of years.
|
| If that's not contract development in a nutshell I don't know
| what is.
| bsaul wrote:
| I usually never post those kind of comments on HN because they
| don't add any value, but : your comment made me laugh out loud,
| thanks a lot :)))
|
| Maybe i'm dreaming but i'm starting to feel a new << let's stop
| with the fashion addict attitude to tech >> vibe on HN, which i
| really really like :)
| ozten wrote:
| They mention that the legacy system was scaled vertically and
| expensive. Sometimes a complete re-write makes sense.
|
| Some companies spend hundreds of thousands of dollars a year
| for terrible CMS websites. I've seen this situation 3 times in
| my career and for all three a re-write was the best long term
| option when balancing all the pros and cons.
| [deleted]
| Tade0 wrote:
| > Reactive declarations and statements feel like powerful magic,
| and they are, but it's very easy to hurt yourself by writing code
| that is almost impossible to debug,
|
| That's interesting, because one thing I'd discovered in Svelte,
| which I didn't even dream of seeing ever again was a legible
| stack trace. It literally goes all the way down to the very
| change that caused all the mayhem.
|
| > Svelte's lack of protagonism
|
| I see this as a good thing. My main gripe with React isn't even
| its design(which I also dislike, but acknowledge the fact that
| the market decided on a solution), but the social aspect of being
| a React developer. You have to accept everything Dan Abramov says
| as gospel, or else you'll be ostracized.
|
| The frontend space would use less celebrities and more focused
| problem solving.
|
| I remember when hooks came out - everyone jumped on the bandwagon
| and started rewriting normal, working components to this new
| paradigm. Net effect of course was unpredictable performance,
| because hooks are only simple on the surface.
| bavell wrote:
| Full stack dev going on a decade here. Stack traces and errors
| in React are pretty awful, fully agree there.
|
| I've never even thought about the social aspect of being a
| react dev - is there one? Frontend sure, but react
| specifically? It's just a tool, nothing to get ideological or
| bent out of shape over.
|
| Couldn't give a shit what Abramov says beyond what is useful in
| my day-to-day. There are probably a lot of junior devs who are
| starstruck but I've never seen any hint of ostracization (lol).
| There are tons of junior web devs (and more everyday) though so
| I can understand how one could form that perception.
|
| Yes to less celebrities and more problem solving.
|
| Hooks are fantastic and so much more composable than the class
| methods. I use 100% hooks and functional components in my code
| nowadays and it has never been easier to build and understand
| my UIs - especially those with non-trivial logic and state.
| Never had a problem with them being "simple on the surface" but
| ymmv I guess.
| Capricorn2481 wrote:
| I feel like there is much more hate towards people using
| React than hype for React itself.
|
| I agree that hooks are great, but a lot of people disagree
| and claim it's overly complex.
| Tade0 wrote:
| > I've never even thought about the social aspect of being a
| react dev - is there one?
|
| I've dipped my toes professionally in all the popular
| frameworks and only in React are people this hyped for every
| little thing.
|
| Case in point: there was a demo on Twitter - of some new
| feature which I don't recall - that showed how React "renders
| 3000 components in real time" - components being 3D polygons.
|
| Many comments praising the performance.
|
| Then an outsider asked "is 3000 polygons really that much?"
| And he had a point.
|
| > Never had a problem with them being "simple on the surface"
| but ymmv I guess.
|
| Yes, you specifically. But if you look at your typical junior
| to mid developer, you'll see them get into hard to debug
| performance issues bery quickly.
|
| It's the same issue as with RxJS in Angular - many praise it,
| but most understand it only just enough to get by, making a
| lot of mistakes along the way.
|
| I think the phrase for this is "footgun".
| chrisjayden wrote:
| I've used Next.js quite a bit, but once I tried SvelteKit, I
| never looked back. One of the things I built with it is
| https://landing.gallery/
| Dowwie wrote:
| Please change the heading font at landing gallery. I thought
| something was wrong with my glasses as the font characters
| distorted.
| chrisjayden wrote:
| [dead]
| game_the0ry wrote:
| Well done!
|
| From inspecting the html:
|
| - sanity for cms
|
| - tailwind for css
|
| - partytown for running script in web worker
|
| - most of the icons on the footer are just unicode emojis, no
| separate library just for icons....nice!
|
| Only feedback I have:
|
| - the sticky footer looks like what you would see in a mobile
| view and looks a little odd in desktop (I am not on a phone
| atm)
|
| - Home page drop down in top left and some footer items are
| redundant, I would nix one (if I had to choose, nix the footer
| links, keep drop down)
|
| - Super minor, but for the nav drop downs, implement animation
| for the up/down arrow icons to indicate open state
|
| Overall, very clean. I'm going to follow your twitter and steal
| the styles from your html to apply to my own projects (bc I am
| bad at design, so thank you).
| chrisjayden wrote:
| [dead]
| jwmoz wrote:
| Nice, I need a site like this for inspiration. Is it ranking
| for any seo?
| chrisjayden wrote:
| [dead]
| troxwalt wrote:
| Would be interested in seeing how you implemented your filter
| functionality. So smooth!
| chrisjayden wrote:
| [dead]
| bavell wrote:
| Very nice! Love the site and content. Small issue - 500 error
| page (nyan-flavored!) when clicking the logo.
| chrisjayden wrote:
| [dead]
| efields wrote:
| I really appreciated this article. No framework is perfect.
| Svelte always looked like the right approach for a modern
| component framework, but modern Vue borrowed a lot of its better
| ideas and ran with it.
| ralphc wrote:
| Could you give an example of this or point to an article that
| does so? I feel the pull between "framework I'd most want to
| use (svelte)" vs "framework that is more popular, more docs,
| more devs (vue)". If Vue is getting more Svelte goodness that's
| a consideration.
| efields wrote:
| Not really, but the single file component (SFC) patterns I
| liked so much in Svelte when I first looked at it are now in
| Vue: https://vuejs.org/api/sfc-css-features.html#scoped-css
|
| If it's a couple folks and you work well together and you
| want to use Svelte, I'd use svelte. If it's a larger team or
| a large project that will be iterated on for quite a while,
| probably Vue. I like Vue quite a lot more than React at this
| point.
| abhishekjha wrote:
| How is this[1] diagram built? I have seen this font in quite a
| few places.
|
| [1]https://claudioholanda.ch/assets/blog/en/0003/1.svg
| topnde wrote:
| drawcharts.xyz
| Arcanum-XIII wrote:
| draw.io if I'm not mistaken !
| daedbe wrote:
| Actually, it looks like Excalidraw[1] to me. The shading and
| line style match very closely.
|
| [1] https://excalidraw.com/
| ygra wrote:
| The hatching and general hand-drawn style is probably done
| by rough.js, which is used by basically all those
| solutions.
| swan_escape wrote:
| excalidraw
| hbbio wrote:
| As the author states, ... Svelte Stores are rough. Beyond just
| missing usage patterns and documentation, we found that several
| features are lacking, especially when used with native reactivity
| (`$:`). Another area lacking is TypeScript support.
|
| Our frontend codebase at OKcontract is implemented with Svelte,
| but we had to build some low-level libraries (including a wholly
| new implementation of Stores) to make it worthwhile. We're very
| busy with our main launch now, but plan to open source these libs
| asap.
|
| PS: We're not using SvelteKit
| pcthrowaway wrote:
| I find this a bit confusing, because stores are one of Svelte's
| answers to react's state, and React's state is a hot mess once
| you go beyond component-local state
| hbbio wrote:
| React state is a hot mess, yes!
|
| We kept the same interface as the Svelte store, but with
| different semantics: - special management of
| undefined values - error management - promise
| management
| bavell wrote:
| Curious - what makes react state a mess? Is it just that
| there's not much batteries included?
| pcthrowaway wrote:
| Briefly speaking, it's because the mechanisms for dealing
| with complex state structures which are either global, or
| shared between multiple components which are not direct
| ancestors/ descendents of one another, are really
| complicated, due to how changes within that state need to
| be managed and propagated through the component
| dependency graph.
|
| Spend an hour, a day, or a year (depending on how broad
| you want your "introduction" to this topic to be) reading
| the various blogs and docs on state management systems if
| you want to see how crazy this gets.
| tomgp wrote:
| stores are nice (i've found the transitions especially useful)
| but very much optional. i've used redux with svelte with good
| results and as the article says, it's easy to get svelte to
| work with any pure js libraries
| devbent wrote:
| What is wrong with svelte stores? I've found them to be
| incredibly powerful and much easier than dealing with redux.
| Capricorn2481 wrote:
| They are zustand/context with extra steps
| wildrhythms wrote:
| Can you elaborate on lacking typescript support in stores?
|
| interface Book {...}
|
| export const selectedBook = writable<Book|null>(null);
|
| Works fine.
| zygo wrote:
| I have used both SvelteKit and React. Dev velocity was great in
| the beginning with SvelteKit when everything was super simple but
| decreased drastically as the project grew. Went back to Next.
| Apart from devs, none really cares if you wrote it in Svelte,
| React or bare HTML/CSS or if your site loads double digit
| milliseconds slower.
| WuxiFingerHold wrote:
| >> but decreased drastically as the project grew
|
| I'm curious why?
| wg0 wrote:
| Could you please give a heads up what makes Seveltkit difficult
| in a larger code base?
| EnragedParrot wrote:
| Lack of dev familiarity.
| jmull wrote:
| My app had about 50 routes (by the design there were about 80
| pages, but of course some common patterns emerged). I
| wouldn't call it large, but it's past "toy" and probably not
| "small" for most.
|
| I didn't have a problem, so I'm curious what the previous
| poster ran in to.
|
| the only thing I can think of is that it doesn't impose much
| structure on the "lib" folder -- that's where code/components
| that aren't directly in the route files go. But there's
| nothing keeping you from keeping that organized yourself. So
| that's not really a problem, but something you might want to
| think about early if you plan to build out the app in the
| future.
| maxboone wrote:
| Personally, I really missed the larger state management
| libraries that are well-available for react.
|
| Layouts, passing difficult props to components, passing state
| up and down in the tree (i.e. refs)
|
| Feels like SvelteKit has a major - just use whatever
| SvelteKit offers, which is generally enough for smaller
| projects.
| NorwegianDude wrote:
| I have tried to use sveltekit once and turned around in 20
| minutes as routing is severely limited. All I wanted to do
| was to route based on domain, with a different set of routes
| for one of the domains. Not exactly complicated or uncommon,
| but not something you can do with the sveltekit router.
| pie_flavor wrote:
| This is gone over in the github threads about such a
| feature - basically, as two different projects
| semantically, the best thing is to create two different
| projects physically, in a monorepo. All the code-sharing
| with none of the additional complexity.
| wg0 wrote:
| As for routing, I guess that gets unmanageable pretty fast.
| Just in the sample blog tutorial here [0], you get confused
| with the number of files and nested folders that has same
| file names as level above.
|
| [0] https://learn.svelte.dev/tutorial/params
| cetra3 wrote:
| I've moved my little hobby website to SvelteKit[1] from react and
| I am not regretting it.. yet.
|
| The only main frustrations I have are:
|
| - Library support is pretty lousy. You need to fudge things
| around to get working. I.e, with leaflet and others I have
| vendored in the libs and redone them.
|
| - Incremental static refresh with svelte kit is not really there.
| I'd like a web hook or api callback that allows me to refresh
| certain static pages as I know that changes are made. Right now
| I'm doing a janky refresh using a file lock notifier & it's a
| blemish on an otherwise great framework.
|
| - The URL routing in svelte kit is... a little ugly. It's really
| hard when you have an editor open with 5 `+page.svelte` files. I
| wish they re-introduced file name routes, rather than folder name
| routes. It is entirely a personal preference I know, but I have
| seen a lot of negative things around it.
|
| [1] - https://github.com/cetra3/divedb - deployed at
| https://divedb.net/
| madacol wrote:
| > It's really hard when you have an editor open with 5
| `+page.svelte` files.
|
| +1. I've been pushed to change tabs using `Ctrl+P` instead
| (search tab command) and write its route (folder's name). But
| it's still a bit painful
| benmccann wrote:
| Can you clarify how you would normally switch tabs and why
| that's difficult? If I open up a bunch of `+page.svelte`
| files I see them as "+page.svelte ../docs" or "+page.svelte
| ../blog" and so it's fairly obvious which one is which to me.
| Longer-term, I think we can tweak VS Code to get rid of the
| duplicate "+page.svelte" part as it is duplicative and
| unnecessary, but I don't find it unworkable at the moment.
| I'm wondering if it's simply that we have different
| tolerances for this or if there's something else going on in
| some cases.
|
| Some people have mentioned liking to set the label format to
| short under File > Preferences > Settings and then search for
| Label Format.
| nop_slide wrote:
| Cool site!
|
| I just looked through your repo. I'm still relatively new to
| SvelteKit and rewriting a similar content based site from
| React.
|
| What led you to use the SSG adapter vs the node adapter (which
| uses SSR)?
|
| How long does the build take to pre-render all of your content
| pages like the sea life?
|
| Was there a particular reason you didn't want to use Form
| Actions?
|
| Not criticizing your decisions by the way, I'm mostly just
| curious about the decisions others make to learn something
| myself :)
| cetra3 wrote:
| Thank you! I've tried to address your questions below. Most
| of these decisions stem from having the backend written in
| Rust, & using GraphQL. That decoupling in the end made it a
| lot easier to port from react.
|
| - I am using a rust backend for the static files and didn't
| want NodeJS part of the request workflow. Most pages aren't
| changed all that much, like maybe once every few months & so
| having yet another service as part of the connection flow
| just adds resources/delay when it's not needed. It's a lot
| faster/easier/cacheable to serve a static file.
|
| - The prerender doesn't take all that long, maybe a minute or
| so, it's fast enough for the site as it stands, but if it got
| super massive it'd be a different story. I throttle how often
| it happens currently, so that there is a bit of time between
| pre-renders.
|
| - The frontend communicates to the backend via GraphQL & the
| backend is not part of svelte kit, it's an entirely separate
| service, and so things like `page.server.ts` won't apply.
| onion2k wrote:
| _Library support is pretty lousy._
|
| Next 13's app directory and React Server Components is killing
| library support in React, so that's not such a big problem.
| Kiro wrote:
| What does that mean?
| onion2k wrote:
| It means that library maintainers are having to make
| changes to their libraries to get them to work on the
| serverside, and a lot of them aren't not really doing that
| very quickly.Consequently moving to RSC reduces the number
| of libraries that work with your React code.
|
| It's a short term problem because most popular libraries
| will get updated eventually, but some won't and they'll
| only ever work on the client side.
|
| In the case of Next, maintainers need to package their
| libraries differently to support ESM modules, or you need
| to configure your project to use the
| experimental.esmModules=false flag. Again, it's not a
| particularly big problem but it does reduce the size of the
| available ecosystem _a bit_.
| yunohn wrote:
| But that doesn't mean React will /break/ existing
| libraries? It's just a new feature that they need to
| start supporting, as you described.
| reducesuffering wrote:
| Before, there was only client-side. Server-side is opt-
| in. So all the libraries you used client-side, you can
| still use client-side by using client-side components
| yunohn wrote:
| I don't know much about the former, but it's not clear why
| React server components are going to kill library support.
| scosman wrote:
| Giant +1 to everything being named "+page.svelte" being
| painful. It clashes with every dev environment I've tried (vim
| tabs, vs code).
| benmccann wrote:
| I haven't had much trouble in VS Code since it shows the
| directory name just after the file name. Some people have
| mentioned liking to set the editor tab label format to short.
| Go to File > Preferences > Settings then search for Label
| Format.
|
| I'm hoping https://github.com/microsoft/vscode/issues/41909
| will get implemented so we can make the problem go away
| entirely
| gl-prod wrote:
| I know the routing isn't the easiest, but I find myself
| navigating with CTRL+P and typing the route I want to work on.
| benmccann wrote:
| How would you otherwise navigate that you find difficult with
| SvelteKit?
| renatofontes wrote:
| Haven't had that refresh issue because I don't use that.
|
| But I'm 100% with you on the routing. It's weird. One thing I
| had a lot of trouble was with "sub routing", like being in a
| route, opening a modal and having the url change so it can be
| linked to.
|
| I had to implement some ugly workaround in the layout to catch
| hasthag # navigation.
| fortunateregard wrote:
| Rich Harris demo'd an upcoming "shallow routing" feature a
| few weeks ago: https://youtu.be/HdkJTOTY-Js?t=419
|
| _around the 7:00 min mark_
| andrewstuart wrote:
| This is the vaguest argument against react I've heard. Not the
| basis for any rational decision making:
|
| >>> But once you leave this path you may (and more likely will)
| get into trouble at some point. And sometimes there are projects
| where you don't want (or can't) risk getting in trouble because
| of the tool you've chosen for your UI development. There simply
| isn't any room for that.
| impulser_ wrote:
| I never built a web app in my life. I have always been on the
| server side.
|
| Recently I spent a couple days building the same web app in Next,
| Nuxt, and SvelteKit just to get a feel of how to build a web app
| today. The web app was pretty basic. A couple of pages showing
| data from different apis and auth with user setting page.
|
| My favorite by far was SvelteKit despite being the one with the
| smaller community. It was actually enjoyable compared to the
| others. It was very easy to feel like I was actually building
| something. You feel productive right away. The app automatically
| felt well organized with how the file layout was. Everything
| belong in a specific place. Layout goes here, Server stuff goes
| there, pages go here. Even form processing with nice. Building
| components was like building components in regular JS.
|
| Next was my least favorite mostly due to the syntax and how you
| had to build the application. I really didn't like the whole
| style of Next and React. Just felt dirty.
|
| I would highly suggest people to try SvelteKit. The file names
| might be a bit weird but it will teach you to use file finder in
| your IDE.
| Graffur wrote:
| > I never built a web app in my life.
|
| > I would highly suggest people to try SvelteKit.
|
| I feel like this is a good summary of tech trends these days.
| Buttons840 wrote:
| A beginner suggesting something to _try_ seems fine to me.
| They have something no amount of study can give, a fresh
| perspective.
| efdee wrote:
| Fresh perspective, or lack of perspective?
| andsoitis wrote:
| > A beginner suggesting something to try seems fine to me.
| They have something no amount of study can give, a fresh
| perspective.
|
| When the beginner's critique of the competition is that it
| felt dirty: _Next was my least favorite mostly due to the
| syntax and how you had to build the application. I really
| didn 't like the whole style of Next and React. Just felt
| dirty._
|
| .... then I don't know that I trust their suggestion.
|
| More importantly, technologies like programming languages
| and frameworks tend to shine at different levels of app
| size and complexity. Novice building a demo app says
| nothing about how the developer experience and code
| complexity will scale as you evolve your app or add more
| developers to the team.
| sebastianconcpt wrote:
| Which is valid as an unpolluted testimony about smoothness of
| adoption, right?
|
| BTW, is noticeable that you were careful to omit the `I have
| always been on the server side` part.
| XCSme wrote:
| Relevant: https://www.youtube.com/watch?v=Uo3cL4nrGOk
| say_it_as_it_is wrote:
| It goes all the way upstream. People build SAAS companies
| offering services based on best practices while the
| product/engineering have had zero prior experience with the
| subject until their current project. People found companies
| selling themselves to investors as experts in the field that
| they have no experience in. Investors sell themselves as
| experts of the industry that they just invested in these
| founders for. Pension managers investing in the VC funds sell
| themselves as investment managers who practice a disciplined
| investment strategy.
|
| Yet, the only people who usually are carefully evaluated are
| the engineers. The rest get a pass based on personality and
| character.
| sph wrote:
| Then there's "I build one web app in my life. Typescript is
| the best thing ever."
|
| And us greybeards: "I have built 50 different web apps across
| 20 years and I'd rather poke my eyes than work on client-side
| Javascript again. No, your new framework isn't any better."
| IshKebab wrote:
| Typescript is very different to Javascript (and it isn't a
| framework). But I get your point.
| pcthrowaway wrote:
| Then there's "I've been writing frontends since Javascript
| was a thing and I think developing for the frontend with
| anything but Typescript is more effort than its worth and a
| little bit ridiculous, but maybe I'll give something with
| WASM a try when it's more mature"
| theironhammer wrote:
| If you're a Rust programmer Leptos looks pretty
| intriguing. It uses Signals like SolidJS.
| pcthrowaway wrote:
| Oh that sounds cool, thanks
| draw_down wrote:
| [dead]
| [deleted]
| throwaway290 wrote:
| Ease of building from scratch and long term maintainability are
| different concerns and maintainability can require higher
| complexity at first.
|
| Eg. I would say involving TypeScript 100% loses at ease of
| building something simple quickly but with some experience I
| would not start a significant project without it anymore.
| barrongineer wrote:
| Just curious why you preferred SvelteKit to Nuxt? Literally
| every single thing you said of SvelteKit is also true of Nuxt.
|
| I like them both, but tend to lean more toward Nuxt for the
| modules ecosystem and layers/extends. I also find composing
| reusable props with typescript to be nicer in Nuxt, but that's
| more of a Vue vs Svelte thing than Nuxt vs SvelteKit.
| tgtweak wrote:
| I don't agree at all with the fact that productivity is that far
| ahead on svelte - much of the react productivity lift is with the
| extensive support from other libraries and platforms.
|
| The point about it being more efficient in terms of performance
| certainly rings true but to claim that it's 2x as productive
| (twice as fast to get something out in svelte) than react, to the
| extent you've graphed it in the introduction, is a fabrication.
| I've seen 2 year old actively-developed svelte projects with so
| much shimming baked in to support common components that the dev
| teams essentially have their own toolkits just to work with it.
| That is not what I would consider 2x as productive. It is an age-
| old paradigm of "less features = quicker" that at some level of
| required complexity does invert.
|
| It's not a static "this is universally faster" equation.
| aitchnyu wrote:
| Tangential but is anybody doing SSR using Django or any non-js
| framework? What is your setup? Wish Django had a library that
| allows `return SSRResponse(bundlename, context=['foo', 'bar'])`.
| _hl_ wrote:
| Isn't that what django's html templating is designed for? It's
| not interactive using js in the client, but it is rendered on
| the server.
___________________________________________________________________
(page generated 2023-06-22 23:02 UTC)