Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Svelte is our choice for a large web project

github.com

Post reply on HN
Print view View original

111–120 of 136 posts

Re: Why Svelte is our choice for a large web project

#111

Post by aliswe »

ratww wrote: post #55
TekMol wrote: post #6

I have switched to pure HTML/CSS/Javascript for frontend. And I am very happy with it. I sometimes use external libraries. For example handlebars if I want to template something clientside. But no more frameworks. I think pure Javascript is plenty enough these days. For those who can't live without a framework: What would you miss?

> 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...

Re: Why Svelte is our choice for a large web project

#112

Post by Can_Not »

How 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.

Re: Why Svelte is our choice for a large web project

#113

Post by arvinsim »

untog wrote: post #72
crubier wrote: post #69

I 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.

To my mind the templating language isn't that different to JSX, and all that. I agree that if and else statements feel a little less natural but for me it's more than worth the price of admission.

Not having to learn yet another tempting language is why I vastly prefer React. JSX is just JS.

Re: Why Svelte is our choice for a large web project

#114

Post by combatentropy »

hinkley wrote: post #94

The one thing that gives me reservations about Svelte is that the description about how code turns into web pages makes me wonder if there are any problems with code-build-run-test cycles. I'm concerned I'll spend all of my time restarting my application to validate changes. Is this a non-issue?

I followed the tutorial (https://svelte.dev/blog/the-easiest-way-to-get-started). It starts a local server and automatically reloads whenever you save changes.

Re: Why Svelte is our choice for a large web project

#115

Post by marcus_holmes »

overtowed wrote: post #16

Author here, just wanted to make a note. This isn't written to hype a battle in the holy war. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of i…

I'm curious that you didn't mention Elm here. Did you look at it and decide not, or not look at it?

Re: Why Svelte is our choice for a large web project

#116

Post by overtowed »

marcus_holmes wrote: post #115
overtowed wrote: post #16

Author here, just wanted to make a note. This isn't written to hype a battle in the holy war. Frontend frameworks are a positive sum game! Svelte has no monopoly on the compiler paradigm either. Just like I think React is worth learning for the mental model it imparts, where UI is a (pure) function of state, I think the frontend framework-as-compiler paradigm is worth understanding. We're going to see a lot more of i…

I'm curious that you didn't mention Elm here. Did you look at it and decide not, or not look at it?

It's not a comprehensive weighing of alternatives, instead it's a deep dive into Svelte's pros and cons as they relate to my experience and our project.

Elm is awesome! There's nothing quite like it that I know of in its design space to bring user-friendly functional programming to the web. Similar to Svelte, its design holistically packages up the web's languages. Compared to PureScript, it's focused on a small and beginner-friendly feature set, trading general power to optimize for the webapp use cases. Elm has also been influential to a lot of toolmakers!

Re: Why Svelte is our choice for a large web project

#117

Post by overtowed »

okareaman wrote: post #58

I watched a tutorial by the author Rich Harris today after reading this link on HN earlier and stopped when he started talking about a DSL he created for Svelte so you don't have to write as much JS. I don't want to learn another DSL. I don't see what the big deal is about compiling. We've have many languages that compile to JavaScript and Google Closure Compiler to tree shake and minify. For years now! Svelte is a n…

Svelte is a component compiler, not a general language compiler. Big distinction! Being purpose-built for this use case opens up a lot of opportunities.

The article goes into this more, but Svelte's DSL is an extension of web languages - not much to learn really! Your existing knowledge of HTML, CSS, and JS transfers directly.

Re: Why Svelte is our choice for a large web project

#118

Post by sw19 »

Can_Not wrote: post #112

How 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

#119

Post by jiofih »

leppr wrote: post #85
xrd wrote: post #24

I love React and I love Svelte. There, I said it. These are the complaints that standout for me with Svelte after using it for a few months: * Sub-par editor support. For me, the litmus test is whether I can use F2 to rename a variable, and it often does not work inside a Svelte template. There are other places where the editor does not know what to do with your code, because it is not pure JS. Vue is much worse with…

Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte? Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone…

Passing components is totally supported, and you can use slots. There isn’t a single issue I identify with in that GH thread...

Re: Why Svelte is our choice for a large web project

#120

Post by leppr »

jiofih wrote: post #119
leppr wrote: post #85

Earlier quoted context omitted.

Since you've been using Svelte for a few months after using React, haven't you been hit by the lack of composability in Svelte? Passing around components as variables is such a common pattern in React, and there's no good replacement in Svelte. The lack of dynamism in components and styles makes theming and crafting reusable components (outside of simple widgets) very tedious [1][2]. I'm genuinely curious how someone…

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
Passing down an element as a prop requires separating the component constructor and its data and manually re-conciliating the two in the child component every time, since components can't be rendered from functions. It works but it's unnecessary boilerplate.

    // parent.svelte
    
      import Nested from './nested.svelte';
      import Child from './child.svelte';
    
    
    
    // child.svelte
    
      let export Component;
      let export componentData;
Post reply on HN