[HN Gopher] Tenets
___________________________________________________________________
Tenets
Author : wilbertliu
Score : 165 points
Date : 2024-02-10 15:57 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| TehShrike wrote:
| I like using Rich Harris's tools because he cares about actually
| getting stuff done and he's allergic to bullshit
| TehShrike wrote:
| I wasn't ever very tempted by React when it started getting hot
| because I had started using Rich's component library Ractive
| and it was so obviously better than React
| gedy wrote:
| Ractive was great, like Knockout++
|
| Svelte was then like Ractive++ as well
| sdwvit wrote:
| oh the irony
|
| one of the upvoted comments says 'Rich for president'
| carlossouza wrote:
| How old is he?
| c0brac0bra wrote:
| > "we explicitly aim to be the framework with the best vibes."
|
| I quite love this.
| jmull wrote:
| On its own it sounds like hand-wavy marketing bs to me...
|
| Then again, svelte has a great developer experience, so I would
| say he's delivering on this.
| nonethewiser wrote:
| It's meaningless.
| razemio wrote:
| It's absolutely not. It works wonders for the community.
| Sorry for saying, but I am quite certain such a comment as
| yours is a rare sight in the svelte community. Everything in
| svelte is around showing others how to do it. Most questions
| in the forum are solved with concrete examples despite its
| awesome documentation. People help each other. Good vibes ;).
| mhh__ wrote:
| That's a good thing, we should embrace it more -- we should
| be more driven by gut feelings than "objective" bullshit,
| that's how you end up with nonsense like megabytes of JS
| going down the wire in the first place.
| arxpoetica wrote:
| > The web matters
|
| nuff said
| nightski wrote:
| Now I know why I dislike Svelte so much, I don't believe in its
| principles. Which is perfectly fine, a framework can't please
| everyone.
|
| HTML is not the mother language - It's actually pretty terrible
| for describing dynamic user interfaces. This is why JS solutions
| are so appealing. If HTML is so magical why do they need a fancy
| template language?
|
| Magical, not magic - I really don't want it to feel magical
| either. I like explicit behavior and I think that is my problem
| with the whole wrap everything in observables approach. It's too
| magical.
|
| No one cares - The countless blogs, posts, and communication
| around frameworks implies that yes, developers do indeed care.
| Details are important. You can't waive away concepts like
| memoization because they need to be used in the right context.
| There's no one size fits all solution to caching.
| ramesh31 wrote:
| >HTML is not the mother language - It's actually pretty
| terrible for describing dynamic user interfaces.
|
| Compared to... what? XML? QML? XIB?
|
| There's literally nothing better than HTML for UI. Anything
| else is either buried in a mountain of proprietary nonsense, is
| platform specific, or is far inferior technically.
| bbkane wrote:
| Flutter has been a lot of fun in my few experiments with it,
| but it's not nearly as proven as HTML
| troupo wrote:
| > There's literally nothing better than HTML for UI.
|
| Except... Literally everything else. Imperative Delphi code
| from early 2000s or indeed Turbo Pascal code from 1995 will
| run circles around HTML any day of the week and twice on
| Sundays.
| hpeter wrote:
| My browser can't run Delphi or Turbo Pascal.
| troupo wrote:
| I was responding to this: "There's literally nothing
| better than HTML for UI."
|
| In general that is false statement. In particular, when
| it relates to browsers, HTML is the local minimum of what
| can be done to describe the "UI".
|
| Because HTML (well, DOM) is the only thing to describe
| the UI in the browser, and it's abhorrently awful. It can
| barely describe a page with static text and some images
| (and even then tools like Lighthouse will warn you that
| "you have too many elements on the page" if you dare go
| beyond 100 or so paragraphs). For the actual _UI_ (yes,
| _UI_ : complex layouts, interactions, dynamic parts,
| states, hundreds of complex interactable objects) HTML is
| unbelievably incredibly bad. Unfortunately that's the
| only thing you have running in the browser [1]
|
| [1] Well, there's canvas (Google Docs switched to canvas
| because of limitations of the DOM etc.) and WebGL (pretty
| much every in-browser graphics program out there). But
| they suffer from having to implement literally everything
| from scratch.
|
| _Edit._
|
| Just to show how inane "HTML is superior to everything
| is", here it is barfing at my _static_ web site that only
| contains text and images (and a total of 9 Youtube and
| maps embeds): https://pbs.twimg.com/media/GF__tHjXgAAZGUA
| ?format=jpg&name=...
|
| Yes. It chokes on the insane number of .... 943 elements
| with a maximum depth of 8.
|
| Apropos of nothing, here's a screenshot of a highly
| dynamic interface like Ableton Live with hundreds of
| dynamic elements https://cdm.link/app/uploads/2023/11/Cle
| anShot-2023-11-15-at... that the "technical superior"
| HTML would not even be able to represent, much less
| render.
|
| In reality it's very hard to find anything that is
| inferior to HTML when it comes to representing and
| rendering UIs.
| PaulDavisThe1st wrote:
| Even after all that, you still haven't made explicit the
| thing that needs to be explicit for any of this to make
| any sense: ".... for UI *IN A BROWSER*"
|
| I know it's convenient to forget the millions of us who
| spent years and continue to spend hours implementing UIs
| outside of a browser context, but it certainly doesn't
| feel very polite.
| CharlesW wrote:
| I don't think anyone's trying to be impolite or diminish
| What Came Before, but HTML is used for lots more than
| websites and browsers. (Examples that come to mind are
| email, desktop and mobile apps, ebooks, and digital
| signage.)
| troupo wrote:
| Yes. Unfortunately we've not inly settled for one of the
| worst systems, but we additionally further settled for
| limited _subsets_ of it as well (email, ebooks)
| troupo wrote:
| 1. I've already answered about "in the browser"
|
| 2. Even in the browser it's the worst possible system
|
| 3. The original comment I was replying to didn't make any
| references to "in the browser", and explicitly talked
| about things like QML and XIB which are very much not in
| the browser.
| WeAddValue wrote:
| So, like an election in Russia, there's only one
| candidate in the race?
| scotty79 wrote:
| HTML was designed to describe single A4 page of single column
| text.
|
| The fact that people started building apps with is was
| miraculous persistence. HTML acquire some functionalities
| that supported such advanced things as multiple columns or
| fairly recently some automatic layouts not directly stemming
| from its text displaying roots. But in terms of flexibility
| and ease of use they are still behind layouts of Delphi from
| 20 years ago.
| patcon wrote:
| I am not a svelte user, but I really like these principles.
|
| I feel very different than you, but I am sincerely glad you
| have clarity and that you better understand what YOU are
| looking for :) having said that, we'll likely end up happily
| working on different things in different pastures
| jmull wrote:
| I'm not a big fan of HTML itself, but I do think svelte is
| right to focus on it for specifying UI.
|
| That's because HTML is the native language for describing UI in
| the browser.
|
| No matter what you use to specify UI, you have to understand
| how it translates to HTML to use it in the browser (and how
| HTML translates back, for debugging). The further your UI
| specification language deviates from HTML the harder that it.
|
| Of course, there are plenty of people using various frameworks
| that don't really understand HTML or how the code they write
| translates to it. But they end up with crappy web sites and
| bugs they don't know how to fix and various other compromises
| and frustrations.
| blowski wrote:
| > HTML is the native language for describing UI in the
| browser
|
| In the same way that assembler is the native language for
| giving instructions to the CPU. In practice, it is of zero
| importance, because there are powerful abstractions built on
| top of it, with wonderful benefits once you're building
| anything more complicated than one-page documents.
| bl4kers wrote:
| It's quite important for accessibility.
| threatofrain wrote:
| I've found that web accessibility often calls for nice
| templates and abstraction, not less, because you often
| need to do some dynamic rewriting.
|
| For example, in a world where components are embedded
| into different places on a website and where users might
| submit rich text content, you have to rewrite their
| headers (h1...h6) to fit with accessibility guidelines.
| jmull wrote:
| That's not the same because the abstraction a mature
| computer language provides is nearly complete (not totally
| complete, of course, but the situations where you ought to
| go digging through machine code or lower are pretty rare).
|
| Outside of games, almost all the frameworks people use
| don't try to do that -- you are essentially trying to write
| HTML, but using the syntax of a different language, or each
| HTML thing in a thing from a different language. (Flutter
| is the exception -- it really does try to provide a
| complete abstraction, though it's certainly not without its
| tradeoffs.)
| nine_k wrote:
| Abstractions are great, as long as you understand their
| performance implications. Some are essentially free, some
| are surprisingly costly if you hold them wrong.
|
| Sadly, there's no way around understanding HTML and CSS
| when you need to troubleshoot what a high-level framework
| built for you. (Or maybe there is! Render everything using
| WebGL, the way Flutter does, and Flash did before it. But
| it's a different kettle of fish.)
| amadeuspagel wrote:
| Open the browsers dev tools and you see HTML. Read MDN and
| you see HTML. Constantly translating back and forth between
| that and another language isn't worth it.
| Aerbil313 wrote:
| Though if there was a better language to describe the UI
| which is as performant, widely supported and documented
| as HTML, I can easily see people using it. Maybe someone
| will start that project today based on my comment, and a
| decade later browsers will integrate it natively because
| it's such a success and everyone is using it :).
| PaulDavisThe1st wrote:
| problem is, the most important "abstractions" for
| describing the UI are not built "on top of" HTML, but along
| side it (CSS and to a limited degree JS). the relationship
| between contemporary "frameworks" and HTML is not like that
| of C and assembler or even Rust and assembler. It is more
| like that of a driver of a vehicle that has each of a
| gasoline, electric and steam powered motor, and must
| constantly pick which one to use for a given situation
| (sometimes two and occasionally all three).
| foota wrote:
| Sure, you should understand how your html will render, but
| expressing logic and handlers etc., in the html is just
| painful to me.
| nightski wrote:
| I hear you, but at the end of the day it isn't really
| targeting HTML. Not when it looks like this -
|
| {#if answer === 42} <p>what was the question?</p> {/if}
| spankalee wrote:
| Sure it is, all the rest of the markup is HTML. Just
| because it's an extension of HTML doesn't mean it's still
| not very HTML.
| nightski wrote:
| The same argument could be said of JSX though.
| jmull wrote:
| Sure... but there are degrees of closeness to HTML and
| the closer to HTML it is, the less translation you have
| to do and the easier it is to deal with.
|
| That is, the closer to HTML the better.
|
| Plain javascript is a crappy way to represent HTML
| because both the syntax and semantics are different (and
| sometimes there are conflicts, like with "class").
|
| JSX is better than plain javascript because the syntax is
| closer, but the semantics are still Javascript, and there
| are still a number of differences you need to work
| through.
|
| svelte is even better, because the HTML parts are
| strictly character-by-character the same as HTML, but you
| still need to know the syntax of a few escape mechanisms.
|
| If there were a way to improve significantly on svelte
| then I'd be all for it. (Maybe HTMX? I'm skeptical of the
| approach of putting a network round-trip into every UI
| interaction, but they sure have nailed down the HTML
| aspect of it.)
| nightski wrote:
| I'm not buying it. Svelte's template language also has
| different syntax/semantics from HTML as well - arguably
| just as much. The JSX parts are character for character
| the same as HTML as well, except for the class/className
| distinction (which if you have used Preact it does not
| have that issue).
| scotty79 wrote:
| It's html plus adhoc behavior description language.
| Behavior does not belong in HTML. You shouldn't have full
| programming language in HTML. And if you do, at least use
| existing language not make your own.
|
| Since all of this is client side (and display: none; is
| the best you can do in terms of not revealing everything
| to the user anyways) you don't even need any behavior
| language in HTML. Just set classes to elements and
| manipulate them with the framework from outside.
| jmull wrote:
| You're just pointing out that svelte isn't 100% the same as
| HTML...
|
| That is true... but of course, if you wanted 100% HTML, you
| aren't looking for a framework at all.
|
| The approach in svelte is that you write the HTML parts of
| your app in HTML. It sounds almost silly to say -- that
| should almost be a silly circular statement -- but with
| some popular frameworks you write the HMTL for your app in
| something sorta like HTML but with various syntactic and
| semantic differences.
|
| (You also write most of your UI logic in Javascript or
| typescript. The amount of syntax that is svelte-specific is
| pretty small, though semantically, the Javascript you write
| for the UI is built on the svelte concepts.)
| ForHackernews wrote:
| No accounting for taste, I suppose. Writing JSX is a nightmare
| to me. It's like we've forgotten 20 years worth of hard-earned
| knowledge about the value of separation of concerns.
| notpachet wrote:
| I agree with you about separation of concerns, but I don't
| think JSX is the guilty party there, so much as the
| overarching frontend ethos that pushes the idea of "single
| file components" to extremes.
| satvikpendem wrote:
| What is the value of separation of concerns when it comes to
| UI? Because I find not colocating the logic and styling for a
| component to be very annoying when it comes to looking for
| the right files.
| vagrantJin wrote:
| The component DIR should have css, logic/js and
| template/markup. Seperation of concerns right down to
| component level. It really comes down to how organised the
| devs and their tools are.
| satvikpendem wrote:
| Or you could put all that stuff in a single-file
| component or use JSX with atomic CSS or CSS in JS.
| troupo wrote:
| > It's like we've forgotten 20 years worth of hard-earned
| knowledge about the value of separation of concerns.
|
| No. We haven't. Because there's a different separation of
| concerns:
| https://twitter.com/simonswiss/status/1664736786671869952
| shdh wrote:
| JSX is an anti-pattern IMO. People just don't wana see it as
| such.
| amelius wrote:
| > Magical, not magic
|
| The problem with magical is that bugs and performance issues
| will make you feel like you're dealing with a bad spell and
| there's no logical solution.
| furyofantares wrote:
| I feel like this phrase is causing confusion and the
| distinction the author is trying to make is clear in their
| mind but very unclear to read.
|
| I'm not sure but I _think_ the distinction being made is
| "not magic" means you're expected to be able to understand
| how and why something works. And "magical" means it should be
| surprisingly easy to do what you want.
| satvikpendem wrote:
| I agree, I'm not going to learn yet another DSL for describing
| basic programming constructs when I can just...use a
| programming language itself. The lack of TypeScript and LSP
| support for quite a few of these DSLs is also very annoying,
| you're basically reinventing new tooling for every new
| framework.
| spankalee wrote:
| > HTML is not the mother language - It's actually pretty
| terrible for describing dynamic user interfaces.
|
| I disagree a lot on HTML here - it's a pretty fantastic way of
| describing a render and layout tree, so much so that people are
| embedding HTML-like syntax in programming languages because the
| syntax is better than what the language already has to offer.
|
| To paraphrase something I've heard: JSX proves that HTML
| actually won.
|
| And you can see this because even in a language with concise
| object literals like JS, a markup based syntax is nicer. There
| are template systems where you write objects, and I find them
| cumbersome and they're not very popular.
|
| But markup is king, whether it's in JS like JSX or Lit-like
| tagged template literals, or in an HTML-like file like Angular,
| Vue, or Svelte. They all share a markup-based syntax.
|
| > If HTML is so magical why do they need a fancy template
| language?
|
| Note that Rich doesn't say that HTML is magical. He says it's
| good, which it undeniably is. It describes elements with
| attributes and children, which happens to be exactly the
| structure you need for the vast majority of UI widget concepts.
|
| The reason you need a fancier template syntax is that while
| HTML is good it isn't perfect. HTML doesn't have a dynamic
| binding syntax (though standards is working on that with
| Template Instantiation) or conditionals, and attributes are
| underpowered.
|
| So template systems generally add those things. Whether it's
| JSX, Svelte, lit-html, Angular, etc... they share those common
| enhancements.
|
| The only real big disagreement is whether you embed the logic
| in HTML or the HTML in JS. It's not even that fundamental of a
| difference.
|
| I prefer HTML-in-JS myself (note: I'm on the Lit team) because
| JS already has binding syntax, expressions, control flow;
| because the data is already available in JS; and because JS has
| a module system and you can do all the things without forking a
| language or a build step.
|
| But having been on the Polymer side too, which is logic-in-
| HTML, I know that a lot of people prefer HTML syntax and that
| to some it's more clear how it maps to the DOM created on the
| page, simply due to syntax similarity. That's fine. But it's
| really all variants of HTML in the end.
| spankalee wrote:
| Also, these differences in syntax and opinion are why I
| vehemently support and work on web components. You shouldn't
| have to have two incompatible silos of UI building just
| because of some frankly minor differences in preferences.
|
| Component authors and component users should be able to
| seamlessly interoperate which disagreeing about such trivial
| things.
| Hugsun wrote:
| I suspect that the dominance of HTML is largely due to it
| being the only browser native markup language. Crucially, the
| browsers' dev tools always show HTML and having an obvious
| mapping from there to your code is hard to beat.
|
| I personally dislike HTML due to the verbosity. I prefer
| hyperscript.
| codeflo wrote:
| > JSX proves that HTML actually won.
|
| While I think that might be true, similarly, JSX proves that
| for the dynamic parts of the template, you want a real
| programming language.
| scotty79 wrote:
| I'd say that it's better to use real programming language,
| but you shouldn't use it in JSX beyond the simplest
| statements like ifs and loops.
|
| Mixing any logic beyond that with HTML makes a mess of
| both.
|
| I'm personally a fan of minimalist templating engines that
| provide only simple loops and conditionals so that template
| has to receive prepared data tree which is created by the
| actual programming language first and passed into the
| template.
| PaulDavisThe1st wrote:
| > I disagree a lot on HTML here - it's a pretty fantastic way
| of describing a render and layout tree,
|
| In the context of the discussion, that would imply that "a
| render and layout tree" is a good way to describe a UI. That
| too is subject to serious questions.
| hpeter wrote:
| "HTML is not the mother language"
|
| You don't need js to create a website, you only need HTML.
|
| For dynamic UI you need a server, not javascript. Your server
| can render html, it doesn't have to serve json.
| shdh wrote:
| Have used: Angular, Vue, Polymer 1 and 2, React
|
| Svelte is by far my favorite framework of the lot. It's also
| the most productive for me.
| pier25 wrote:
| > describing dynamic user interfaces
|
| GUIs are essentially 2d scene graphs. Basically you need to
| describe a tree of hierarchical relationships.
|
| I agree HTML is not great for the dynamic part and the
| reacitivity but it's the lingua franca of the web. Why reinvent
| some new DSL when you already have one that was already
| designed to represent a scene graph.
| scotty79 wrote:
| > HTML is not the mother language
|
| Personally I just don't like when people go too much into
| "<lang> in <lang>" mentality. HTML is decent at describing
| what's there. CSS is sort of fine at describing how it looks.
| And JS is ok for describing what should happen.
|
| My second guiding principle is that everything should be split
| into composable components, without anything being privileged.
| So I don't like page components being special in any way.
|
| I can excuse some violations of the first principle in the
| service of the second one like putting a bit of HTML into JS
| file instead of keeping separate HTML template file for each
| component. But I don't really like any CSS in JS. The only
| connection surface between CSS and JS (and HTML) should be
| selectors that say what is addressed. CSS classes should
| identify elements. If you want some classes that describe
| groups of styles (like tailwind) you can have them but don't
| cram them directly into HTML. Include them in styles for given
| element using SASS (or LESS) include functionality. HTML (or
| JS) shouldn't describe how things look.
|
| Also all the frameworks that claim to be almost pure HTML but
| they cram the adhoc behavior description into fake HTML
| attributes rub me the wrong way. They remind me of what was
| there 20 years ago.
|
| And any reactive bindings between arbitrary stuff is just
| ordering whole bowl of old time spaghetti, after Redux (and
| React) shown that it doesn't have to be like that anymore.
|
| I agree that additional challenge of keeping the flow of state
| centralized and unidirectional might feel unnecessary for
| simple projects, but it's worth it if the project survives more
| than few years and grows.
| ramesh31 wrote:
| > We want Svelte to feel magical -- we want you to feel like a
| wizard when you're writing Svelte code... So when we design
| things we need to think about the people who haven't read the
| docs in a while, if at all, and don't care about things like
| that. This means that things need to be intuitive, that we
| shouldn't need to worry about manual optimisations like
| memoisation, that we should have as few APIs as possible, and
| that things need to be discoverable
|
| Amen. After being forced into working on a large Vue project as a
| React dev who had sworn it off, I've slowly come around to
| falling in love with it. Once you get over the "black magic" of
| it all, the productivity is insane. For people who just need to
| get things done, and couldn't care less about millisecond level
| rendering benchmarks, I would easily suggest it over React at
| this point.
| maelito wrote:
| What makes Vue "insanely" more productive than React ?
| ForHackernews wrote:
| Vue is a unified ecosystem of tools written by the same
| authors and designed to work with one another. React gives
| you way more rope to hang yourself. Good luck figuring out
| what the routing and state management flavor of the minute
| is.
| maelito wrote:
| Then you're looking for Next.
|
| It's a unified ecosystem of tools written by people closely
| related and designed to work with one another.
| ForHackernews wrote:
| I'm not looking for Next. I'm quite happy with Vue or
| Sveltekit.
| ramesh31 wrote:
| >What makes Vue "insanely" more productive than React ?
|
| React is a fantastic rendering library but there are no great
| React frameworks. Next is ok, but it's a beast that most
| people don't need. The beauty of something like Vue is having
| your batteries included in a standardized way that _you don
| 't have to worry about_ when upgrading, while also still
| being fairly lightweight. The average React app becomes a
| hodgepodge of dependencies that get frozen in time due to the
| fragile nature of NPM. Versus having a known and documented
| upgrade path for your router, state, styling, etc.
| recursive wrote:
| Vue benchmarks better than react anyway.
| preommr wrote:
| > Instead of striving to be the fastest or smallest or
| whateverest, we explicitly aim to be the framework with the best
| vibes.
|
| Except that svelte advertises itself constantly as being faster
| and with smaller bundle sizes. Which is a good thing. I don't buy
| that it priortizes 'good vibes' at the cost of those other
| things. If it's saying it prioritizes 'good vibes' and everything
| else, then that's pretty meaningless - they might as well say
| they're good at everything.
|
| Would also help to actually define what 'good vibes' are because
| I think every tool tries to make DX as nice as possible.
|
| I honestly dislike fluff like this because it conveys nothing and
| gives fodder for people to ignore practical evidence in favor of
| biased advertising i.e. someone's going to make a bullet point
| list about things they dislike, and someone will just point to
| this and say "nuh uh, you're wrong, they care about being user-
| friendly, it says so right here".
|
| Since we're talking about front-end frameworks, I still maintain
| that vue has some of the best documentation. I fell in love with
| vue 2 because the documentation did a great balancing act between
| being brief, simple, and somehow dense at the same time. In
| particular, I remember a page about it's comparisons to other
| frameworks that in a few paragraphs, gave a history lesson,
| simplified differences to barebones, explained the practical
| implications all in a way that put vue in a good light. It was
| much better than the angular and react docs at the time.
| gmaster1440 wrote:
| > Except that svelte advertises itself constantly as being
| faster and with smaller bundle sizes.
|
| Maybe this is a subtle difference, but I understood it as
| Svelte still caring about and prioritizing speed and bundle
| size, but not necessarily as the primary focus with the goal of
| being _the_ smallest or _the_ fastest.
| shdh wrote:
| Svelte is better than Vue IMO
| Aerbil313 wrote:
| I love Svelte, but please make substantial comments on HN.
| Flagged.
| pier25 wrote:
| I agree but there's a difference between the DX vs the
| execution (how the thing runs internally).
|
| I believe the vibes thing refers to the DX, not the engine
| itself.
| doctor_eval wrote:
| I gotta say, the "vibe" of the new $props syntax, to me, is
| awful.
|
| I love that I can just use export let prop;
|
| because it's just JavaScript.
|
| The new runes syntax let { prop } = $props
|
| Is not. This just makes me incredibly sad.
|
| Like all things, everyone is going to switch to the new syntax
| because it's shiny, even though it objectively has a greater
| cognitive load (and IMO, looks ugly). My components are going
| to start looking like Svelte, rather than JavaScript.
|
| The reason I prefer svelte over Vue is because there's less to
| remember. Looks like I'll be looking for a new framework after
| Svelte 5. Just like I did after Vue 3.
|
| Also,
|
| > Snippets are more powerful and flexible, and as such slots
| are deprecated in Svelte 5.
|
| Removing slots, which feel really natural in HTML, with
| snippets - that are expressed as JavaScript values passed to a
| component - honestly, I don't see the prioritisation of vibe,
| here.
| nathias wrote:
| Svelte to me is how objective progress in building the web looks
| like, much like React was just much better than Angular 10 years
| ago, Svelte just makes sense.
| rykuno wrote:
| The direction React/NextJS has taken modern web development is a
| modern day abomination. I say this as a passionate fullstack
| developer whos worked for YC startups and a fortune 10 company
| within the past decade. I appreciate Vercel as a company too; I
| have no hate towards them but the NextJS 13 release almost made
| me quit web development.
|
| Svelte is an absolute love language to the web and a direction
| for healing the damage caused by modern "web frameworks". It's
| the absolute direction we need to head in.
|
| Here's something beautiful. I'm teaching my brother-in-law
| programming to get a job when he's out of the military. He's
| learning JS/CSS/HTML and doing quite well. With about a 2 minute
| tutorial of how Svelte works; he was able to start creating some
| pretty impressive projects. A day later because he already knew
| the basics of how the web works, he was in Sveltekit building
| fullstack apps -_-.
| nonethewiser wrote:
| Astro is a pretty cool alternative too
| throwaway77384 wrote:
| So glad to see someone else say this. NextJS 13 was (is) a
| complete an utter disaster. I took on a reasonable-size project
| around that time and the documentation was incomplete, no
| library worked on it. Mystery caching and fetch-call
| deduplication all over the place. It was horrific. I wonder if
| things have improved since.
| addandsubtract wrote:
| The trick is to just stick to the Pages Router in Next. The
| app router and RSC is still too early to use, imo, and needs
| at least another version or two to gain some support.
| zackify wrote:
| It's still this bad
| rich_harris wrote:
| Ha, did not expect this to be on the front page of HN today! Some
| quick context: in January I was in London for a few days, and
| while I was there we had a Svelte Society London event.
|
| This document is a text version of a talk I gave there, which
| expands on some of these ideas:
| https://www.youtube.com/watch?v=eswNQiq4T2w&t=5211s
|
| It's deliberately brief and vague in parts, because it's designed
| to spur conversation. It's not set in stone, nor is it an
| Official Statement on behalf of the Svelte team -- it's an
| attempt to articulate the way that the maintainers tend to find
| ourselves thinking about some of these topics, as viewed through
| my personal lens. If it helps explain why you like Svelte, great!
| If it helps explain why you hate it, that's great too -- that's
| the whole point. Have fun with it, and if there are parts you
| disagree with then your homework is to think through what kind of
| tenets would describe your ideal framework.
|
| Also, it's Saturday -- get off Hacker News :)
| monero-xmr wrote:
| Svelte rekindled my love for frontend development - thanks for
| your efforts!
| SandraBucky wrote:
| Hey rich, we love your work at my team mahn. Keep doing what
| you are doing.
| rykuno wrote:
| Awesome efforts on Svelte Rich; have a good weekend!
| iamcreasy wrote:
| Thank you for creating Svelte. I have basic web dev experience
| using no-framework. Is there any high level overview article
| explaining how Svelte compiler transpiles Svelte file into a
| series of html,css and javascript and wires them up together?
| k__ wrote:
| That whole text sounds like he gave up.
|
| Like, Svelte isn't better than any alternative in a meaningful
| way, he's just doing it because he wants to.
| DotaFan wrote:
| Chose Svelte for a client project 5 months ago, client loves the
| speed, I love developing with it. In general it's quite a nice
| tool, fast development, feels easy to learn. I do dislike server-
| less functions, which comes in pair with Svelte ability to do
| SSR, which doesn't have to do anything with Svelte tho.
| pm wrote:
| Svelte and SvelteKit have earnt a place in my heart. They've
| allowed me to enjoy learning reactive- and component-based
| development. In comparison, React has always felt like a chore,
| and I avoid it as much as possible, despite it being the most
| popular framework.
|
| (Side note: I rate Vue as well, though I prefer SvelteKit over it
| these days)
|
| Rich Harris and the Svelte family have always been pragmatically
| minded, and there's value in expounding one's development
| philosophy, but I've gained no insights with this list. Perhaps
| it's the language used, rather than the tenets themselves.
| SandraBucky wrote:
| I am doing UI in svelte for few months now, I worked on React
| before, It feels like some weight has been lifted off my
| shoulder.
| levmiseri wrote:
| As someone used to doing everything with vanilla JS and having
| troubles with getting deep into any web frameworks (especially
| React), Svelte has been a godsend. I'm in love with the
| philosophy and approach and its natural combination of
| JS/CSS/HTML is, in my personal bubble, second to none. Most
| recent experiment was https://meoweler.com, but I'm now trying
| more complex projects and can't sing high enough praises. I
| sincerely hope the future of Svelte is bright.
| csswizardry wrote:
| Off-topic, but Meoweler is a goldmine--thank you!
| doctor_eval wrote:
| Meowler is really cool. Like, I don't get it. But I love it.
| dayjah wrote:
| Can anyone fill me in on the backstory about lighthouse? What is
| it? Why is it a bad measure?
| noSyncCloud wrote:
| It's a set of performance tests built into the Chrome dev
| tools. It profiles your site on a variety of metrics and gives
| you a report. I'm not exactly sure what's wrong with it in the
| context of this post.
| bowsamic wrote:
| Whenever I've tried Svelte I've honestly had a horrible
| experience, which surprises me somehow. It definitely failed on
| the "magical, not magic" thing. The exact workings of $ is still
| extremely confusing
|
| It's funny, a lot of the Svelte fans made me think that it would
| be very simple and nice, and that React was much clunkier,
| confusing, and implicit, but my experience was the total opposite
| tpict wrote:
| I feel insane whenever the Svelte reactivity thing is touted to
| me as an improvement over React state. Surely it's not so hard
| to internalise JS equality rules that such a huge break from
| convention is necessary?
|
| PS. I looked up the reactivity token docs on the Svelte website
| to make sure I was remembering correctly, but it repeatedly
| crashes the latest version of Safari on iOS. Oops!
| pier25 wrote:
| I started using Svelte a couple of years ago and I love it. Very
| quickly it became the only client side solution I want to use.
|
| Can't say the same about SvelteKit though. I've tried it a couple
| of times and it's just not fot me. It's really a tool built
| around a client side library and it shows (instead of being a
| backend framework).
| Hugsun wrote:
| I've been using it professionally for some time and find it
| pretty nice. What are your frustrations with it?
| pier25 wrote:
| It's severely lacking in the backend but I guess this is more
| of a general issue with all so called full stack JS
| frameworks.
|
| Specifically with SvelteKit the big deal breaker is routing.
| I also find the whole +page.svelte stuff to be a usability
| nightmare since I barely use the file explorer to move around
| a project and instead use fuzzy search. Unfortunately
| SvelteKit is pretty unflexible so you either love it or hate
| it.
|
| It's really weird that I agree 100% with all the decisions
| regarding Svelte itself and how it's evolving (runes etc) but
| SvelteKit is just a big nope from me.
| robwg wrote:
| I wouldn't judge any JS framework like SvelteKit or Next.js
| on its lacking in the backend. They have a server to handle
| frontend problems, not solve your backend problems.
| xk_id wrote:
| I think it's wonderful that their official website doesn't even
| work in iOS 14.3 Safari, which is only 3 years old (it crashes
| completely with "500 internal server error"). I encourage
| everyone who genuinely cares about the web to stop updating
| compulsively and just allow themselves to be gracefully excluded
| from this foolishness.
| moffkalast wrote:
| > Instead of striving to be the fastest or smallest or
| whateverest, we explicitly aim to be the framework with the best
| vibes.
|
| Wat.
| baxtr wrote:
| Anyone know why these principales are called tenets? I believe
| it's a concept that originates from amazon.
| mpalmer wrote:
| Tenet has a dictionary definition; as far as I can tell there's
| nothing to suggest that it's specific to some industry-speak
| concept.
|
| If one is being _super_ pedantic, tenets and principles aren 't
| the same thing, but they're very close in meaning to each
| other.
|
| The linked page contains examples of both tenets and
| principles, and uses the terms interchangeably in the
| title/intro.
|
| Tenets are positions/beliefs/qualitative statements presented
| without proof. "The web matters", "No one cares" are examples
| from the OP.
|
| Principles are related, but more like guidelines or
| instructions. "Optimise for vibes" is an example.
| laurels-marts wrote:
| Svelte 5 moves closer to React in quite a few ways. The single
| component per file is still a dealbreaker for me. React got it
| right with composition and being able to break a component out
| into its sub-components.
___________________________________________________________________
(page generated 2024-02-10 23:01 UTC)