Earlier quoted context omitted.
Someone on HN recommended it to me before, so I’ll just pass this along: look at intercooler JS for making individual “live widgets” on a well-designed graceful degradation site like you describe.
Also Alpine.js, which has got quite a community behind it (somehow promoted by Laravel, IIRC). It is less than intercooler, but provides timesavers for simple sites like described. A compromise between a framework and none.
Why Svelte is our choice for a large web project
121–130 of 136 posts
Re: Why Svelte is our choice for a large web project
#122Earlier quoted context omitted.
Haven't heard of that one. Thanks!
Also unpoly, which I prefer to Intercooler and it’s my favourite unknown library since jQuery was first released. It’s an incredible time saver.
Re: Why Svelte is our choice for a large web project
#123Earlier quoted context omitted.
What I found on several consecutive projects was that less the HTML generation resembles the final HTML, the harder it is for people to keep the CSS selectors wired up correctly. Getting text into the page as fast as possible at the cost of layout issues is a sucker's bet. You can't ship until it looks good, and the longer features are in-flight the worse management feels about the team's abilities.
A utility-first compile-time CSS framework (eg Tailwind) should be a perfect fit for this scenario, on multiple levels
You don't want situations where senior staff have to intervene on what should be a straightforward issue. It gums up the works.
Re: Why Svelte is our choice for a large web project
#124Earlier quoted context omitted.
> For those who can't live without a framework: What would you miss? The thing I miss the most is a good component and state abstraction. That's it. I would be very happy using ASP.NET WebForms today: components are rendered 100% in the server but the state is persisted by the client using a field. The server can be 100% stateless. Too bad it is impossible to convince anyone to pick up ASP.NET WebForms in 2020 :) Mod…
Aspnetcore Razor pages is basically web forms with cshtml, if you ask me...
Components in Blazor actually look like Svelte, or maybe it's the other way around.
Re: Why Svelte is our choice for a large web project
#125Earlier quoted context omitted.
Passing components is totally supported, and you can use slots. There isn’t a single issue I identify with in that GH thread...
Slots are currently an unwieldy band-aid. https://github.com/sveltejs/svelte/issues/1037 (open since 2017) https://github.com/sveltejs/svelte/issues/2079 The simple usage of passing a component to a component, which almost every decently-sized project will make use of, has no convenient syntax, only workarounds: // parent.svelte import Nested from './nested.svelte' import Child from './child.svelte'; // child.svelte…
import RedThing from './RedThing.svelte';
import GreenThing from './GreenThing.svelte';
import BlueThing from './BlueThing.svelte';
const options = [
{ color: 'red', component: RedThing },
{ color: 'green', component: GreenThing },
{ color: 'blue', component: BlueThing },
];
let selected = options[0];
{#each options as option}
{option.color}
{/each}
{#if selected.color === 'red'}
{:else if selected.color === 'green'}
{:else if selected.color === 'blue'}
{/if}Re: Why Svelte is our choice for a large web project
#126I dislike the templating pseudo language of Svelte (and many view frameworks). Maybe I am spoiled by react but I never ever want to write my view logic in anything else than JS. This is my main blocker for Svelte.
I've never fully understood this viewpoint, which comes up a lot in relation to React and JSX specifically. The templating in Svelte and Vue is (almost) html with some magic sprinkled here and there, so much closer to the end result. Using JS for everything is moving further away from the metal. What is it about writing views the React way that appeals to you more?
IMO a just a simple function/array based templates work better like this that I have used recently:
div({class: 'test'}, b({}, 'Hello world!'))
Or for the array syntax:
['div', {class: 'test'}, ['b', {}, 'Hello world!']]
Re: Why Svelte is our choice for a large web project
#127Earlier quoted context omitted.
Slots are currently an unwieldy band-aid. https://github.com/sveltejs/svelte/issues/1037 (open since 2017) https://github.com/sveltejs/svelte/issues/2079 The simple usage of passing a component to a component, which almost every decently-sized project will make use of, has no convenient syntax, only workarounds: // parent.svelte import Nested from './nested.svelte' import Child from './child.svelte'; // child.svelte…
I'm evaluating svelte and have yet to do much, however handling dynamic components is a key requirement, and appears to be supported like so: import RedThing from './RedThing.svelte'; import GreenThing from './GreenThing.svelte'; import BlueThing from './BlueThing.svelte'; const options = [ { color: 'red', component: RedThing }, { color: 'green', component: GreenThing }, { color: 'blue', component: BlueThing }, ]; le…
https://svelte.dev/tutorial/svelte-component
But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.
Re: Why Svelte is our choice for a large web project
#128Earlier quoted context omitted.
I'm evaluating svelte and have yet to do much, however handling dynamic components is a key requirement, and appears to be supported like so: import RedThing from './RedThing.svelte'; import GreenThing from './GreenThing.svelte'; import BlueThing from './BlueThing.svelte'; const options = [ { color: 'red', component: RedThing }, { color: 'green', component: GreenThing }, { color: 'blue', component: BlueThing }, ]; le…
That's the tutorial challenge code, you get the `svelte:component` solution after clicking "Show me". https://svelte.dev/tutorial/svelte-component But yea that's indeed what I should have done in my example if I wanted the component to be reactive, as you can see that's even more verbose and still doesn't take care of props.
And, isn't it likely this will be easier to support with Svelte eventually? My reasoning is that you just need to add a little syntactic sugar to the language and the compiler can add whatever code is necessary? With a runtime like React and Vue, it seems much harder to add in.
Re: Why Svelte is our choice for a large web project
#129How is it that 23 hours in and nobody is pointing out that svelte/sapper just freezes on runtime errors without the ability to show an error page or report them to a tracker like sentry/rollbar/etc.? This is one of the biggest barriers to being production ready or fit for use in large projects.
Wow is that true? My team has been considering moving to Svelte and not having Sentry integration would be a dealbreaker.
Re: Why Svelte is our choice for a large web project
#130I'm rapidly becoming a huge Svelte fan. Quick self-promotion plug (but in the name of altruism): I've been working on an open source project that glues together Svelte (on the front end) and Crystal (on the back end). https://github.com/noahlh/celestite Two slightly obscure (but growing) languages/frameworks, but hey, gotta pick a niche. Contributions & feedback welcome!
Found a straggler "CrystalVue" substring in the main .cr file, you should give 'er the old find-and-replace all to change them.