[HN Gopher] Rich Harris joins Vercel to work on Svelte full time
___________________________________________________________________
Rich Harris joins Vercel to work on Svelte full time
Author : leodriesch
Score : 629 points
Date : 2021-11-11 15:43 UTC (7 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| uzername wrote:
| Is this a bet against React or a bet for ecosystem variety and
| choice? I feel it's the latter right now.
| hunterb123 wrote:
| Seems more like variety. React is in a league of it's own with
| React Native. For web tech Svelte is cool, for app tech it's
| not on the radar.
|
| I used to be a web developer, now I'm a React Native / RNW
| developer.
|
| I don't use web tech unless I'm making a simple web page, when
| I do I use vanilla HTML/CSS/optional JS.
|
| You get a web app for free when you make a RN app. You can
| share 95% of code among 5 platforms. (web, windows, macos, ios,
| android)
|
| Conditionals can change any styling you need amongst them. You
| can swap out scripts depending on platforms, you can access any
| extra native platform function with extensions.
|
| Svelte doesn't work for me because you need JS. I don't want to
| need JS for simple web pages, for apps I need cross-platform.
|
| Svelte could work well for edge computing like CF workers.
| dexwiz wrote:
| How is RN? I have seen several teams try to consolidate their
| App Devs into RN devs, only to split back into iOS/Android
| devs. From what I'm told, if your app could be a webpage, RN
| is great. But if you need to really leverage the specific
| platforms, it's hard to do that.
| ativzzz wrote:
| It's probably because they had a team of experienced
| iOS/Android engineers, who are significantly more
| productive in their respective platforms.
| hunterb123 wrote:
| > But if you need to really leverage the specific
| platforms, it's hard to do that.
|
| Not my experience. I have a production app for web, ios,
| and android, with desktop platforms coming.
|
| You can swap out anything per platform and write any
| extension for any native functionality you don't have, but
| the std and community extensions are plentiful.
|
| RN sucks for "web pages", great for apps. In fact sometimes
| I embed web pages inside my RN apps. (surveys, etc.)
|
| I haven't heard a single good argument of why it doesn't
| work. If you were going to write a native app you can write
| a native extension and share the common parts in JS.
|
| RN is not Cordova, it's not a black box, it's very flexible
| and extensible.
|
| -- @Jcampuzano2 because of post limit --
|
| Earlier yes there's some fickleness with the toolchain, I
| don't really have issues now, it's fine unless you're on
| bleeding edge versions or old versions. Performance issues
| usually relate to the JS bridge, JSI will alleviate that,
| most devs won't experience an issue. I don't know why
| others struggle with RN, it works well for me. Flutter is a
| no go because it emulates native, it's not true native. You
| can feel the difference on iOS and the web part sucks so
| hard.
| Jcampuzano2 wrote:
| Weird because this is the exact opposite of everything I
| hear from most developers I know.
|
| I personally also worked with React Native for a while,
| and sure, you can write native extensions for everything,
| but the biggest complaint is how fickle it is when it
| comes to upgrading, package management, mind boggling
| errors related to the metro bundler, etc.
|
| I.E. It's great when it works and you have something
| simple, but things broke so often compared to native
| development when you had to do anything complex. And the
| performance characteristics weren't very great on top of
| this.
|
| I haven't done React Native in a bit more than a year but
| from people I talk to not much has changed, and most
| people I talk to who were all in on React Native mention
| to use Flutter instead nowadays if you really want cross
| platform UI.
| penjelly wrote:
| react native can definitely ship production ready
| applications that large teams work on. bundler problems
| arent even react native related.. theyre webpack/babel
| etc. Package management? how is that related to RN?
| throwaway1777 wrote:
| Because you never have to deal with that stuff in mobile
| apps unless you use react native? So sure maybe it's not
| directly react native's fault but it is an issue.
| penjelly wrote:
| you will always have to manage dependencies somehow.
| Maybe you prefer the model used by flutter or something,
| thats preference. Its not a matter of whether of one is
| unsustainable or not. react native is fine for
| professional or hobby projects. even if you have problems
| with babel/webpack/etc bundle server (which btw can be
| worked around using inline bundling...)
| hunterb123 wrote:
| This thread initially started by me comparing Svelte to
| React.
|
| React uses webpack usually, RN uses metro usually, you
| can use esbuild, swc, etc for either though.
|
| Svelte is a web tech, and thus uses web bundlers like
| webpack, thus has the same "faults", though I'm not sure
| what specifically is being critiqued.
|
| When comparing RN to other cross platform solutions like
| Flutter you're wanting to compare it's package manager /
| bundler to Metro and the native dependency systems such
| as Cocoapods.
|
| Just wanted to clear that up.
| BackBlast wrote:
| My experience with the tool chain was abysmal. It's been
| almost 3 years away now for me, so I don't know the
| current state of things. I hope it has improved.
|
| But every update was a large effort in bringing the app
| back into compliance with the new changes. The debugging
| platform used a different interpreter than in app
| resulting in things that worked in the debugger but not
| in production. Odd bugs at boundary layers nobody could
| (easily) decipher. The inability to even catch or do
| anything with some crashes.
|
| It was the worse experience I ever had with a development
| tool chain in my entire career.
| leerob wrote:
| To me, it's uplifting the entire web ecosystem. There will
| always be developers who pick Svelte and friends over React,
| even if that reason is just syntax preference. Those developers
| should still have the best infrastructure for their apps.
| Better to be pragmatic than over-prescriptive.
| dexwiz wrote:
| If you are building a platform for web dev, it's better to be
| able to control your technology. Any change FB makes to React
| may leave you scrambling to patch your tech. Or What if one day
| FB decides to stop supporting React, or they make a design
| decision incompatible with your business? While it sounds
| unlikely, it's bitter pill to swallow from a business angle.
| [deleted]
| penjelly wrote:
| react is used so many places professionally that i think
| someone would just fork or remake react from scratch if they
| ever did that.
| dexwiz wrote:
| And then you would probably be forced to support classic FB
| React for customers that didn't want to migrate, and forked
| React.
|
| The real issue is if you build any special sauce on top of
| React. Say you went all in on providing a customized
| React.Component that worked like a React.Component, but had
| your platform's logging, perf metrics, etc built in. Then
| React comes out with hooks and functional components and
| then you are stuck trying to reimplement your special sauce
| using these. Or you have to tell customers, "we only
| support class based components." While functional
| components are old, FB has shown it will introduce paradigm
| changes into React, and you are left holding the bag when
| it comes to supporting them in your platform. And if
| customers saw a new React feature previewed yesterday, be
| sure they will be asking for support for it today. FB isn't
| likely to hand over React to Apache or any sort of open
| governance model, so changes can be easily made without a
| huge amount of forewarning, or even a business
| relationship. Last time I checked FB wasn't selling support
| contracts or partnerships for React.
| [deleted]
| bartq wrote:
| Feels like a good move. How else could framework be developed
| than implementing some requirements. Vercel should provide lots
| of them. What else can be added to Svelte btw? It looks like a
| finished project already. People can only invent in Svelte area
| if browser standards move forward, right? Otherwise Svelte can
| only be used to support needs of some platform.
| dang wrote:
| We changed the url from https://vercel.com/blog/vercel-welcomes-
| rich-harris-creator-... to Rich's own post.
|
| There were two other submissions - one to an interview ( _Svelte
| Creator Rich Harris: Web development should be more fun_ -
| https://news.ycombinator.com/item?id=29189209) and the other to
| this Twitter link
| (https://news.ycombinator.com/item?id=29189467). I've merged
| those threads into the current submission because it was posted
| first.
| pier25 wrote:
| Thanks dang! This was the right move.
| leerob wrote:
| Agreed, thank you so much.
| ithkuil wrote:
| I heard about vercel before but this announcement made me try it
| out.
|
| Oh boy, what an amazing onboarding experience!
| penjelly wrote:
| i just started rebuilding my personal site with nextjs but the
| enthusiasm here is pushing me to try svelte for the first time..
| guess ill have to take a look at the feature list
| midrus wrote:
| It is really worth it. Svelte is sooooo much better than React.
| Believe me, I was one of the skepticals about the entire SPA
| thing but after trying Svelte I think my problem was with
| React, not with the concept per se.
| penjelly wrote:
| i dont actually have any problem with react, but im
| definitely open to new things this thread reveals to me that
| this Rich character has some useful information i should look
| into.
| didip wrote:
| Can someone teach me how Svelte does what it does? The front page
| is not telling me much?
|
| How does it "surgically" update the DOM? Why is it better than
| virtual DOM?
| rglover wrote:
| Surgical = "It checks a diff of what the component rendered
| before an update vs. after and then only patches or updates the
| parts of the DOM that need to be changed (as opposed to
| replacing the _entire_ DOM, which is slow). " Similar to React.
| Svelte may not be using the exact same mechanisms but this is
| in the ballpark.
|
| Virtual DOM is just an in-memory representation of the DOM that
| describes which child elements (e.g., a <p /> nested within a
| <div />) belong to which parents, and which attributes/values
| those elements need at render time. When a change happens, you
| can generate an updated virtual DOM and diff it against the
| previous (or current) version and pick out what specifically
| needs to be changed in the DOM (read: surgically).
| bdougherty wrote:
| There is no diff going on with Svelte. And there doesn't need
| to be an in-memory representation of anything. Because it is
| compiling the code, it knows exactly what will change and in
| response to what.
|
| https://svelte.dev/repl/7161f10f8eb645d8984fb231a0bc3982?ver.
| ..
|
| For example in that repl, you can see that it makes a call to
| `$$invalidate` when the input value changes (see
| `input_input_handler()`) which triggers a `set_data` call
| (see `p()`) to update just the textNode that contains the
| name. This is what is meant by surgical. No other work is
| done other than what is required to update the specific
| places where a variable is used.
| rglover wrote:
| This is a cool approach, thank you for sharing that link.
| jitl wrote:
| When your React component renders, it returns an object that
| describes the desired state of the component tree. Take this
| component: function MyComponent() {
| return <div>Here's <b>bold text</b></div> }
|
| At runtime, React calls your component function and then
| applies the returned data to the DOM imperatively. If your
| component has rendered before, React needs to _diff_ the
| virtual DOM your latest render returned against the VDOM React
| last applied to the real DOM. Very simplified idea of what
| happens on every render: function
| reactInternalRenderLoop(root) { const newVdom =
| MyComponent({}) const diff = diffVdoms(root.prevVdom,
| newVdom) for (const change of diff) {
| change.applyToDOM(root.domNode) }
| root.prevVdom = newVdom }
|
| React's runtime time complexity is fundamentally limited by
| this `diffVdoms` function, and React's memory usage is
| fundamentally limited by the size of the VDOM returned by
| components.
|
| What Svelte does is entirely eliminate this whole process
| involving diffing and what-not. At compile time, Svelte
| analyzes the data dependencies between the rendered template
| and reactive values in the app, and generates self-contained
| components that know how to update their own DOMs. You can
| think of it as essentially moving the entire
| `reactInternalRenderLoop` function from _runtime_ to _compile
| time_. There is no more diffVdoms function call on your user's
| devices. There is no more big allocation of VDOM data
| structures.
|
| Svelte might compile `MyComponent` to something that looks like
| this: const MyComponent = {
| mount(parent) { const element =
| document.createElement('div') div.innerHTML =
| "Here's <b>bold text</b>" parent.appendChild(div)
| }, update() { /* no-op */ } }
|
| And since the Svelte compiler knows the contents of MyComponent
| never change, the mount function will only be called once for
| the entire runtime of your app.
| tuan wrote:
| So it sounds like the tradeoff here is that the generated
| bundle is more complicated/bigger. I'm not familiar with
| Svelt, but wondering about bundle size + debuggability.
| jgalentine007 wrote:
| When I tried Svelte a while back (year or two ago) I had
| difficulty working with code in the debugger, couldn't seem
| to get source maps to work correctly, I wonder if it's
| fixed.
| bdougherty wrote:
| At a certain size, yeah the bundle will be larger, but it
| would take a lot to get to that point. For pretty much
| anything you would do, the bundle will be much smaller.
| Especially if you use SvelteKit which is smarter about what
| is bundled and when it loads.
|
| As for complexity, the generated Svelte code is extremely
| readable. Take a look at the generated JS tab in the repl:
| https://svelte.dev/repl
| [deleted]
| xrd wrote:
| So smart by Vercel. So many people will use their platform
| because of the association with Rich. This is a marketing expense
| that will show up on the books as headcount. Rich deserves this,
| he's created an amazing project with an amazing community.
| aogaili wrote:
| Personally I have mixed feeling about this.
|
| I guess I'm not a fan of seeing investors money expand it's
| control over the open source ecosystem. I like open source
| because it empower the little guys. But I don't expect others to
| share my values and perspective and perhaps Rich Harris turns out
| to be a robinhood. Why not doing something like the creator of
| Vue? With that said I look forward to see what comes out of their
| shop. Good luck :)
| pier25 wrote:
| Woah as a Svelte user I'm super happy and this is going to change
| everything.
|
| I can only speculate as to the reasons behind this decision by
| Vercel. Why Svelte and not Preact for example?
|
| In any case, congrats Rich!
| leerob wrote:
| We love Svelte and are super excited to help it grow. IMO it's
| fun, easy to learn, and is fresh take on modern web
| development.
|
| More here: https://vercel.com/blog/vercel-welcomes-rich-harris-
| creator-...
| owlbynight wrote:
| Started learning JS a few years ago. Picked svelte for my front
| end stuff because the other frameworks seemed saturated with
| experienced devs already and I wanted to be closer to the ground
| floor on something. I've been waffling the last year or so,
| wondering if I should focus more on NextJS because it was backed
| by Vercel.
|
| I breathe a little easier today! This is great and can only be a
| good thing for svelte and sveltekit.
| whiddershins wrote:
| We have used Svelte for a major internal project and it has been
| an absolute joy to work with.
|
| This is really exciting news.
| kosolam wrote:
| Svelte is really great. It really needs this boost in cash to
| polish the rough edges and improve tooling etc. I'd add that most
| people here who are hating on the syntax didn't go to check what
| svelte is actually about. I say that even though I work with
| React professionally
| solarmist wrote:
| Any Svelte UI component libraries with good i18n and a11y
| support?
| tropix126 wrote:
| Carbon and SMUI are both good.
| tekkk wrote:
| Wow, this should be great news for Svelte and SvelteKit!
| Hopefully with Vercel's backing these projects will fly off.
|
| Having worked with React for about 5 years (with a project in Vue
| in-between) and now having dabbled with Svelte, there is just
| something more appealing working with less higher-level
| abstractions. Sure with large apps React does have its benefits
| and its ecosystem is larger by a good amount.
|
| But there is just something about being _less_ annoying that to
| me is perhaps one of the most important things with any tool. If
| I enjoy using it, I don 't mind that it may not be the "current
| best choice" of the moment. People who enjoy MobX especially I
| think ought to find Svelte quite nice.
|
| Sure though would wish SvelteKit was at the same level with
| Next.js. Fixing dev server errors is a little distracting at
| times.
| [deleted]
| FractalHQ wrote:
| > ecosystem is larger by a good amount.
|
| Svelte's ecosystem is, in practice, actually much larger than
| React and any other framework because Vanilla JS works out of
| the box without framework specific wrappers. So just about any
| JavaScript package can be imported into a Svelte file and used
| without hassle.
| noir_lord wrote:
| It's also _really_ easy to use with typescript.
|
| The last place I worked was a React shop, before that I did
| most of the frontend as well and used Vue, Current place uses
| Svelte and I'm really glad they did/do, the continual
| surprise is how Svelte makes easy things easy and hard things
| doable.
| benmccann wrote:
| > Fixing dev server errors is a little distracting at times
|
| You will be very pleased with the upcoming release of Vite 2.7!
| It's by far the most impactful release of Vite thus far for
| SvelteKit. All the major known issues we've been tracking have
| been addressed in the latest Vite 2.7 beta (assuming that one
| of the PRs we're still working out the kinks of doesn't get
| rolled back, but either way it'll be a huge improvement!)
| sxiao wrote:
| Ben, please don't surprise us and tell that you are the next
| one on Vercel's payroll.
| benmccann wrote:
| I'm doing my own thing and won't be joining any existing
| company ;-)
| sxiao wrote:
| > won't be joining any existing company
|
| Good news and the most underrated and overseen comment in
| this thread. Nice man!
| kall wrote:
| Well if there's any place to learn from next.js it's probably
| Vercel. Looks like great news for Svelte.
| _puk wrote:
| This is absolutely fantastic news!
|
| I love Svelte, and have been using it for a year or so now, but
| lack of community mindshare means that I've had to roll a lot of
| my own components.
|
| That said, I think Netlify missed the boat on this one - happily
| using Netlify with Sveltekit, and it would have been great to
| have the competition in the PaaS space.
| yumraj wrote:
| Can someone explain what Vercel does.
|
| I'm familiar with Svelte, but interestingly not with Vercel. A
| scan of their website wasn't completely clear, but that is
| probably just me.
|
| Edit: thanks to all who answered, very helpful.
| ryanSrich wrote:
| Used to be called Now. It's a PaaS.
| inglor wrote:
| They are a competitor with other clouds like
| AWS/Azure/GCP/DigitalOcean with a focus on JAMStack and modern
| workflows.
| dbbk wrote:
| More like a competitor to Netlify, GitHub Pages, etc
| _fat_santa wrote:
| Vercel is a hosting provider for static websites. I see it as a
| simplified versions of AWS, specifically for static websites.
| leerob wrote:
| Hey! I'm Lee, Head of DevRel at Vercel :) Happy to answer any
| questions you have.
|
| Vercel is a frontend cloud platform that integrates with any
| framework you prefer (or just plain HTML!). We are also the
| creators of Next.js, which is a React framework. We try to make
| it as easy as possible for you to write some code and put it on
| the web, globally.
| dceddia wrote:
| This seems like a huge positive step forward for Svelte and the
| community. Big congrats to Rich!
|
| I've been excited about Svelte for a while and recently chose to
| use it as the UI for a cross-platform video editing app
| (https://getrecut.com), with the back end in Rust. I've found it
| a pleasure to work with -- Svelte Stores and the Context system
| are especially great for sharing state, and the app feels snappy.
| Last few weeks most of the focus has been on the Rust backend but
| I'm really looking forward to building out more of the UI soon.
|
| I've also been happy to find that its generated code is pretty
| readable. On one little performance-tuning side quest, I was
| profiling to figure out why the app was performing a Layout on
| every video frame, and I was able to step through the compiled
| Svelte component code and narrow it down to one of my own
| functions. I also briefly went down a path of trying to manually
| set the text content on an element, to see if it'd be faster than
| letting Svelte do it. Turned out the answer was no, but it was
| nice to know that level of control is available if I need it some
| day.
|
| Excited to see where the Svelte community goes from here!
| gnrlst wrote:
| I see your app is MacOS only at the moment. Are you re-writing
| it in Electron or what? Very curious
| dceddia wrote:
| Yeah, rewriting it with Electron + Svelte + a Rust backend
| for the heavy lifting.
|
| I looked at alternatives to Electron because I wanted to
| avoid the bloat, but nothing felt like the right fit. Tauri
| (https://tauri.studio/) is the most exciting, but I couldn't
| find a good way to get raw video frames into the UI without a
| bunch of expensive copies or serialization. I also looked at
| native toolkits like Qt (I've worked with it in the past) but
| I didn't love the idea of building lots of custom UI
| components without the benefit of HTML + CSS. So for now it's
| Rust + Electron, and I'm paying extra attention to
| performance.
| vips7L wrote:
| Did you look at .Net solutions like Maui, xamarin, uno
| platform, or AvaloniaUI?
| dceddia wrote:
| My thought process was, if I'm gonna have to rewrite the
| app, I may as well use the web dev skills I already have,
| so that at least the UI work will be in my wheelhouse.
| Rust is new to me, as is low-level ffmpeg stuff, both of
| which I've had to learn from scratch.
|
| I learned Swift in order to build the Mac app, and I know
| from that experience that building custom UI controls
| while learning a new ecosystem slowed me down a lot. I
| didn't love the idea of repeating that experience, and
| where I'm headed there's gonna be a good bit of custom
| UI.
| spoils19 wrote:
| Sounds like an easier process for you, but at the cost of
| your users. This proliferation of web tooling when it
| clearly doesn't suit the environment (desktop) is part of
| the reason why our software is getting slower, even as
| our hardware is improving.
| cakoose wrote:
| Not always at the cost of the users?
|
| If dceddia is able to add features and fixes more
| quickly, that's good for users too.
|
| And if Svelte on the desktop becomes popular, people will
| likely come up with more efficient options. For example,
| a more efficient Electron or something like "Svelte
| Native", which could be a good thing.
|
| I'd love if all software were more efficient, but getting
| up to speed on a new platform has a huge opportunity cost
| too.
| dceddia wrote:
| Being very conscious of those downsides, I'm putting in
| extra effort to make sure it's fast. So far it seems to
| be working!
|
| It uses less CPU than any other Electron-based video apps
| I've seen (and even less than a few Qt-based editors I
| tried) and it feels snappy.
|
| I think tools like Figma have shown what's possible when
| enough attention is paid to performance early on - but
| yeah, it's one of my main worries with going with
| Electron and I'm trying to avoid the downsides as much as
| I'm able.
|
| The ones I have less control over are memory usage and
| disk space. I'd _love_ to get those down but it seems
| like that 'd require digging into Chromium and ripping
| things out. Which, honestly, I looked at doing, but that
| code base is a beast and I'd rather get something into
| peoples' hands sooner.
|
| On a related note: I think there's a real opportunity for
| an "Electron Lite", like some kind of custom
| Electron/Chromium build that turns off stuff you don't
| need. I suspect it could help disk usage + memory usage +
| startup time. Chromium's build system has lots of flags
| that make it _seem_ like you can turn things off. But it
| didn 't work that way when I tried, so I think it
| probably requires source-level changes, which then means
| maintaining those patches across Chromium updates etc.
| But really, though: I don't need WebRTC, or printing, or
| media codecs, or probably a zillion other things. It'd be
| so cool to be able to turn those things off at will.
| O_H_E wrote:
| That sounds like a responsible way to divide focus. Kudos
|
| I forget the word or the link, but I think there was a
| "rule of thumb" thing that circulated HN about having a
| limited budget for taking-risks/being-bleeding-edge, and
| focus in spending that on differentiating properties of
| your projects, while the rest should stay "old and
| boring"
| dceddia wrote:
| Thanks, and yes! "Choose Boring Technology", love this:
| http://boringtechnology.club/
|
| The idea of spending fewer "innovation tokens" was
| definitely on my mind when I was thinking through this.
| rickstanley wrote:
| > without the benefit of HTML + CSS
|
| Are you referring to ease in complexity of creating
| components compared to the alternatives? Because I end up
| with the same choice when sieving frameworks to use
| crossplatform. But I've been looking nto Flutter recently,
| although it's still in beta, it has potential.
| dceddia wrote:
| Yeah. I talked about this in another reply but I've had
| mostly web development experience over the past few years
| and UI work is familiar. I didn't love the idea of having
| the entire tech stack being unfamiliar. (I'm already new
| to Rust and ffmpeg/video stuff)
| nicoburns wrote:
| React-native might be the close to what you're looking for
| at the moment. But the ecosystem is still tiny on Desktop,
| and I don't think it supports desktop linux at all.
| dceddia wrote:
| Yeah I looked at it briefly but the lack of usage was a
| bit of a worry. And if I'm honest I really wanted a
| chance to use Svelte :)
| protonimitate wrote:
| Also curious - I'm spinning up a small side project with Rust
| and Svelte. Was looking in Tauri as a replacement for
| Electron but wondering what other approaches people have
| worked with (assuming this is a cross platform desktop app,
| that is).
| dceddia wrote:
| Tauri seems like a nice option. It's not as full-featured
| as Electron yet but their focus on security is great to see
| (last I saw they were getting the codebase professionally
| audited). The main reason I didn't go with it was just that
| doesn't seem to (yet?) suit my use case with zero-copy data
| transfer between Rust <-> Browser.
|
| My hope is that by writing most of my backend in Rust, that
| it'd be easy-ish to switch to Tauri or other options if
| something changes down the road.
| Tade0 wrote:
| > I was able to step through the compiled Svelte component code
| and narrow it down to one of my own functions.
|
| This is the best part about next-gen frontend frameworks. We
| can go back to having a stack trace uncluttered by layers of
| asynchronous abstractions.
| dceddia wrote:
| Love me some good old synchronous code! :D
| vgel wrote:
| Do you have a mailing list I can toss my email on for when this
| is available on Linux? Honestly I was ready to buy it instantly
| before I saw the platform limitation, but it would be even
| better if it could run some basic filters like removing pops
| and de-essing, which I always struggle to get working right in
| Audacity (I have a screenshot saved of my filter curve because
| Audacity doesn't save it, it's so stupid).
| dceddia wrote:
| It's not Linux-specific but you can sign up to hear about the
| Windows one (click the "Get Notified" button on the home
| page) and I'll let everyone know if/when there's a Linux
| version.
|
| Fair warning I haven't even tried getting it to run on Linux
| yet... but I've been meaning to try it out, if only for the
| profiling and debugging tools! (rr looks really cool!)
|
| In theory it runs everywhere because Electron, but my gut
| says the difficulty with supporting other platforms will come
| down to compiling and packaging. That's been the biggest
| hurdle with Windows so far anyway.
| kingcharles wrote:
| Looks cool - what is the timescale for Windows?
| dceddia wrote:
| Weeks to months, hopefully by the end of the year? We'll see!
| A lot depends on what other challenges come up, heh.
| falafelite wrote:
| Thrilled to hear it! As someone who has primarily written back-
| end code, I found Svelte to be the most accessible (readable,
| good/simple docs with lots of examples, easy getting started
| instructions, clear conceptual framework). Eager to see what
| comes out of this.
| midrus wrote:
| I've been pretty skeptical about SPAs but having tried out Svelte
| for a few side projects, I have to admin I was probably directing
| my skepticism to the wrong thing, probably React was the cause of
| my dislike for SPAs. Svelte looks really awesome and the
| simplicity it brings back is invaluable. I really wish it takes
| off, for real. Looks very promising.
| solarmist wrote:
| What bits were misdirected? What worries did you have?
| midrus wrote:
| The complexity and the over engineering going on, mostly.
|
| Things such as redux, rxjs, observables, thunks, etc really
| put me off when you compare that to just MVC with Rails for
| example, plus most applications I worked with React were just
| forms anyway, with some fancy controls/widgets on top.
|
| Not having a clear way, even today with Next, to load data
| (client side, without doing SSR) before a route transition
| happens (which leads to spinners everywhere), and now the
| solution seems to be all the server components, concurrent
| mode, suspense, etc, etc which to me is just mind blowing how
| complex things became.
|
| Also hooks which conceptually they make a lot of sense and I
| like them, but then you have to do all the dependencies
| tracking manually, they have a lot of gotchas (async in
| useEffect, ordering, etc).
|
| The "rerendering of everything" and the need for manual memo,
| useMemo, useCallback, etc and the whole "don't optimize it
| until you need it" (guess what, a my company as in many
| others it never was a product priority to make it fast).
|
| Now, take the good parts of the approach, remove all these
| complications, and you have a very nice and clean approach to
| do web apps. To me that is what Svelte brings back.
| solarmist wrote:
| Oh, okay. Thank you for the explanation.
|
| Yes. I totally agree with this. That's why I chose Vue as
| well. As I've gotten into it more I've found chunks that
| certainly feel over engineered here and there too.
| _benj wrote:
| This is such great news! I've been vaguely aware of svelte for
| some time now but it wasn't until a few months ago that I started
| using it professionally and it is such a joy to use!
|
| I recently did an onboarding and explained why svelte instead of
| react of vue, and svelte code, to me, is so much more intuitive
| and clean!
|
| Thanks for the awesome work Rich and best of luck in this new
| chapter!
| solarmist wrote:
| I'd like to hear more. What were your conclusions? I'm
| particularly interested in it compared to Vue.
|
| I picked Vue because of most people's complaints about React,
| so most of the comments I'm seeing are about specific gripes
| with React and don't really help me make an informed opinion.
| _benj wrote:
| For React, I agree with the complaints. The change from class
| components to functional components and the addition of hooks
| for we was a step backwards.
|
| As for vue, most of my experience is with vue 2, never really
| spent a lot of time with the features of vue 3.
|
| To the the some of the syntax of svelte makes more sense than
| that of vue. For example, to list something in vue an html
| with v-for is needed, or <template v-for... >. This always
| felt a little awkward to me. In svelte you iterate on the
| data, not on an html element. So you have an array and just
| put {#each item i items} ... {/each}, not need for extra html
| or pseudo <template>
|
| I also prefer svelte's computed properties to vue's. All it
| takes is a $: value = a + b and from there whenever a or b
| changes value also changes. Sometimes my computed property on
| vue will start growing a little too much.
|
| Something similar in vue and svelte that I enjoy a lot is
| that the code is separated from the html and from the style.
| Some people are fans of JSX but I can't stand it! It allows
| me to shoot myself in the feet and I do it way too often.
|
| The store is VERY VERY nice too! it's lighter than vuex but
| seems to have some of the limitations that redux/mobx have,
| say, it has to be functional. I haven't had to write any
| reducers like with redux tho, but stuff like [].push() won't
| update.
|
| Overall I really really like it because it's almost
| transparent. I really didn't have to "learn" svelte as I had
| to vue or react. It was similar enough to HTML/CSS/JS that it
| took no time picking it up.
|
| But, that's just me
| ummonk wrote:
| I like React's opinionated top-down model (with callbacks passed
| downwards as needed either directly as props or through a store /
| context) for handling state changes, as this improves
| composability and ability to reason about state.
|
| My understanding is that Svelte's main difference from React is
| that it is not opinionated in this way, and this is considered a
| positive feature by its proponents. Is my understanding
| incorrect?
| ravenstine wrote:
| Awesome news! Having worked with frontend frameworks for years,
| I've grown pessimistic about them in general, but I'm
| enthusiastic about Svelte because it does so many things _right_
| that actually avoid a lot of the issues other frameworks claim to
| solve but actually make worse.
|
| Interacting with the Svelte compiler is ridiculously easy. Though
| the documentation can be improved, I found it trivial to import
| the Svelte compiler and prerender a component into an HTML
| string. Yes, this is somewhat of a niche thing to do, but I
| appreciate it when libraries and frameworks make it easy to
| access its internals. Heck, I pretty easily managed to implement
| Typescript support for Svelte components using Deno's `emit`
| function; hooking into Svelte's preprocessing was trivial, the
| complexity I ran into being on the Deno side.
|
| Contrast that with Ember, which seems to have an attitude of "no
| one would or should ever want to do _that_ ", making it really
| hard to do anything slightly off the beaten path without lots of
| trial and error or entering the Ember inner-circle.
|
| _Yes, I know I 'm comparing a component library to a framework,
| but what I'm commenting on is more about development philosophy._
|
| It's good to hear the creator of Svelte will be able to dedicate
| his time to it and be able to provide project guidance. I think
| he has the right vision for what Svelte should be.
| cobertos wrote:
| Ember was the first framework I used and also the most
| frustrating. At least with Vue and React I can poke at the
| internals and they make sense, but Ember's internals had so
| many oddities that thoroughly confused me.
| ravenstine wrote:
| What I like about Ember is that it gives a lot of rigid
| structure that, at least at one point, made it comparatively
| easy to work on multiple Ember based projects and be
| productive sooner.
|
| As you've pointed out, a problem with that project is that
| there's a ton of intimate knowledge for how things work under
| the hood or why things are the way they are. They also seem
| to oscillate between opting for simplicity and opting for
| complexity and magic.
|
| One example would be the latest version of Ember which
| doesn't even ship with `@ember/render-modifiers` by default
| despite how everyone will end up installing it out of
| necessity anyway.
|
| Why might that be, you may ask?
|
| > [...] we recommend using these modifiers with caution. They
| are very useful for quickly bridging the gap between classic
| components and Glimmer components, but they are still
| generally an anti-pattern.
|
| https://github.com/emberjs/ember-render-modifiers
|
| Why on earth did they reinvent components and ship them
| without providing the supposedly correct way of interacting
| with their lifecycle? You actually have to install a separate
| add-on to develop a production-ready app with Ember, which
| completely flies in the face of the idea that you can run
| `ember new` and have pretty much everything you need. Go
| ahead and try interacting with individual elements of a
| Glimmer component in a vanilla Ember project and see how
| productive and ambitious your web app will be.
|
| Strangely (and thankfully), the RFC for what I think is a
| needlessly complicated alternative for lifecycle interaction
| is effectively stalled:
|
| https://github.com/emberjs/rfcs/pull/567
|
| By their own verbiage, the only official way to interact with
| component/element lifecycle is an _antipattern_.
|
| So far Svelte and SvelteKit are avoiding all that extra crap.
| The day that Svelte calls its own solutions "antipatterns"
| and spends years pontificating things like the actor pattern
| will be a sad one.
|
| /rant
| sxiao wrote:
| This is so HN, in an Svelte thread memories from Ember
| (sharing your sentiments though).
| ravenstine wrote:
| HAHAHA
|
| I try not to go full HN, but sometimes you do.
|
| And I shouldn't have made it about that. As I get older I
| the more I just get tired of extra things. There's always a
| price when you add more things. Svelte technically does add
| things, but I think it has better bang for its buck. The
| fact it doesn't pointlessly impose OOP constructs upon the
| end-developer is a big win for me.
| sxiao wrote:
| Yeah, Svelte is pure gold.
| leerob wrote:
| What could be improved in the documentation?
| brightball wrote:
| I'm definitely curious about it. I'm one of those "swore off
| frontend framework" people who's attracted to tools like
| Phoenix Liveview so I never have to deal with it.
|
| Svelte does look pretty sharp and simple though. I wonder how
| well it works with something like LiveView? Does it really
| depend on the styling structure mentioned or can I use it with
| Tailwind?
| dceddia wrote:
| It works great with Tailwind, I'm doing that in a project
| right now. I haven't tried pairing Svelte with LiveView and
| I'd worry they would end up fighting over elements of the
| page, but I'd think you could have them control separate
| parts of the same page, or have them controlling distinct
| pages just fine.
| sxiao wrote:
| Why is this 'awesome news' for us devs, the market and
| competition if one vendor now controls all modern SSR
| frameworks plus significant parts of the tool chain (swc)?
| afavour wrote:
| Does Vercel actually "control" Svelte, though? The existing
| governance structure is untouched, they're just paying the
| salary of the lead (and definitely not only) developer.
| sxiao wrote:
| Not sure if this topic is worth our time to debate. There
| are millions of ways of subtly controlling/influencing
| entities. And it's much easier if you pay money, ESOP and
| pay even more money if future goals and exits come alive.
| DonHopkins wrote:
| The Zope Corporation hired Guido van Rossum to work on
| Zope for three years (a Python web application server and
| content management system), then he moved on. That didn't
| destroy Guido, or Zope, or Python.
|
| https://en.wikipedia.org/wiki/Zope
|
| https://en.wikipedia.org/wiki/Guido_van_Rossum#Work
|
| >He has worked for various research institutes, including
| the Centrum Wiskunde & Informatica (CWI) in the
| Netherlands, the U.S. National Institute of Standards and
| Technology (NIST), and the Corporation for National
| Research Initiatives (CNRI). From 2000 until 2003 he
| worked for Zope Corporation. In 2003 Van Rossum left Zope
| for Elemental Security. While there he worked on a custom
| programming language for the organization. From 2005 to
| December 2012, he worked at Google, where he spent half
| of his time developing the Python language. In January
| 2013, he started working for Dropbox. In October 2019,
| Van Rossum officially retired before coming out of
| retirement the following year to join Microsoft.
|
| Guido and Rich are both uncontrollable forces of nature!
| afavour wrote:
| Even if Vercel came out and said "we've bought Rich
| Harris's voice, every choice will be controlled by us"
| (which they haven't!) they _still_ wouldn't control the
| project because Rich isn't a BDFL.
| sxiao wrote:
| Good point and I agree about Rich but I rather trust
| healthy markets and competition more than people.
| ahevia wrote:
| Wouldn't Vercel benefit from being the defacto platform
| to deploy Next & SvelteKit apps?
| sxiao wrote:
| Yes sure and it's not Vercel's fault that there's no
| other competitor left out there. I would have hired Rich
| as well if I were Vercel. But the market will suffer
| because one (and the better) player just left the market.
| We can only blame Rich who got weak but yeah, nobody is
| perfect.
| emteycz wrote:
| He did not leave the market and on top of that now has
| financial safety so can work on the project 100%. That's
| a net gain.
| leeoniya wrote:
| > We can only blame Rich who got weak but yeah, nobody is
| perfect.
|
| this comment. just wow.
| ahevia wrote:
| Calling someone weak is a personal attack. You are not
| Rich. Don't speak for him or his attributes. Keep the
| discussion constructive, you've already been asked in
| this post to calm down the personal attacks even after
| Rich gave you a kind reply
|
| https://news.ycombinator.com/newsguidelines.html
| [deleted]
| arendtio wrote:
| First time I took a few more minutes to look into svelte. To me
| it looks like it could be successor of Vue.
|
| Do you know of other high potential candidates?
| Glench wrote:
| Awesome. Been using Svelte exclusively for a couple years in my
| projects and don't see myself using React ever again.
| barelysapient wrote:
| This is my first look at Svelte. It looks amazing. I hope for day
| when front-end development is more language primitives and less
| frameworks--what with their 'useEffectOf' and @Component's of the
| world.
| WORMS_EAT_WORMS wrote:
| Cloudflare will regret not having a developer go-to framework for
| their advanced Worker stuff one day.
|
| I think they are waiting for someone else to build for it which
| is IMO the completely wrong approach for the dream of the
| serverless app. You got to own the full stack including software.
|
| I can easily see Vercel becoming the pretty much only go-to in
| this space just from the developer trust they have created with
| Next (and now Svelte). The general getting started experience
| between the two serverless providers is night and day.
|
| One is where do I begin / how should I do this (cloudflare).
|
| The other is simply code... and... go! (vercel)
|
| I'll be all in on whatever Rich makes there. Been waiting for a
| solid Cloudflare Worker framework for literally years bridging
| front-end and back-end. Instead, we got Pages (which is cool,
| just boring for the fun stuff).
| ksubedi wrote:
| They do have https://flareact.com/ and although it is still
| early, it is very promising. They have used patterns from
| Next.js so it is easy for developers to migrate.
| WORMS_EAT_WORMS wrote:
| This is not Cloudflare:
|
| > Flareact is an experiment created by Josh Larson in August
| 2020.
| ksubedi wrote:
| You are right. Sounds like they need to sponsor him!
| andrew_ wrote:
| Denoflare (https://news.ycombinator.com/item?id=29142772) is
| compelling.
| WORMS_EAT_WORMS wrote:
| Also not Cloudflare (to my knowledge)
| johanndev wrote:
| Do you have experience with denoflare? I _really_ would like
| to try it, but I can 't even get the basic `hello-worker`
| sample working, see
| https://github.com/skymethod/denoflare/issues/2
| rce wrote:
| SvelteKit has an out-of-the-box adapter for Cloudflare workers:
| https://github.com/sveltejs/kit/tree/master/packages/adapter...
| WORMS_EAT_WORMS wrote:
| This is kind of exactly my point in not owning the full stack
| with Serverless.
|
| I'd be a bit nervous right now if I built my business / app
| on that.
| mwcampbell wrote:
| I hope that Rich joining Vercel doesn't end up compromising
| SvelteKit's current neutrality when it comes to deployment
| targets.
| benmccann wrote:
| As a heavy contributor to SvelteKit, I can't see a loss in
| neutrality happening. I personally use other hosting
| platforms frequently with SvelteKit, both Rich and Vercel
| have expressed they want to avoid this outcome, and other
| SvelteKit maintainers work full-time at Vercel competitors
| and also wouldn't let that happen ;-)
| kall wrote:
| Yes! To compete, cloudflare really needs a nicer "full-stack"
| experience where you have one repo, one config file, one CLI
| and one codebase that is shipped automatically into pages and
| however many workers, dns rules, kv stores, durable objects,
| Images and Stream deployments etc. They have Wrangler but it
| doesn't really feel "complete". At least they should rename it
| to cloudflare-cli and cloudflare.toml.
| friedman23 wrote:
| Vercel is built on cloudflare workers meaning vercel winning
| means cloudflare wins. Also I think building out the
| datacenters across the globe is a much harder problem than
| building out a framework.
| leerob wrote:
| Vercel's infrastructure is multi-cloud, primarily using AWS.
| We're currently using Workers specifically for Edge Functions
| (https://vercel.com/edge).
| sva_ wrote:
| That animation in the background could use a little
| optimization. It's redrawing nonstop for no reason. Left
| the site open for a few mins and it got my humble
| Thinkpad's fans going hard (Vivaldi).
| leerob wrote:
| Thanks for the feedback, we'll improve this!
| rabaut wrote:
| Do you have a reference for this? Curious to learn more. I
| thought Vercel was built on AWS.
| lmeyerov wrote:
| making a framework popular is harder than making data center
| stuff; people successfully rack boxes and crank rust/go/js/..
| every day, but most js frameworks fail
| [deleted]
| blackandsqueaky wrote:
| Cloudflare currently markets successfully to a very different
| calibre of engineer. Meanwhile, Vercel don't even support 2FA
| login yet, and publish mandatory cache-busting query string
| parameters to the public Internet. Their "CDN" is a BYOIP range
| running on AWS Global Accelerator
| Rauchg wrote:
| Hey! Guillermo, CEO of Vercel here. Security is the absolute
| top priority at Vercel, and you should be seeing continued
| progress in that area in the coming weeks and months.
|
| We're heavily investing in security all the way from the SDK
| and its supply chain[1] to platform, product and cloud.
|
| We proudly use the best infrastructure and products available
| to help our customers scale without stress. AGA is quite
| incredible[2] and so is Cloudflare[3] and we are honored to
| be able to work closely with the purveyors of the finest
| infrastructure on the Internet!
|
| [1] https://news.ycombinator.com/item?id=29003089
|
| [2] https://news.ycombinator.com/item?id=29158742
|
| [3] https://twitter.com/swyx/status/1456665048949018626
| kadomony wrote:
| Hey Guillermo,
|
| Thanks for chiming in here. Unrelated, I saw that Vercel is
| ramping up hiring for designers. I've always worked in
| consumer-facing design spaces (banking, travel, etc.) and
| want to make a change toward something more dev-oriented
| like Vercel, but I worry being told that "I don't have the
| right experience". Does Vercel hire folks looking to change
| the industry they design for? I'm a senior IC in design
| systems, so the extent of what I design for devs is mainly
| documentation sites.
| Rauchg wrote:
| Absolutely. A core goal for us is to Lower the Barrier of
| Entry[1] to building for the Web.
|
| Building a beautiful and fast Web experience needs to
| feel myspace-code-easy (or as Rich Harris puts it: it has
| to be fun!). I think ultimately that's what makes the Web
| win long term. It's open and accessible.
|
| The best way to contribute to this mission is to come in
| with a fresh mindset, passion and big ambitions. Please
| reach out: https://vercel.com/careers
|
| [1] https://rauchg.com/2021/making-the-web-
| faster#realtime
| systemvoltage wrote:
| I predict that Cloudflare will acquire Vercel one day.
| admn2 wrote:
| I do think it's interesting how they've positioned Cloudflare
| Pages. Kind of an "Amazon" move. Unlimited bandwidth and
| seats. Will be interesting to see though if it works for
| Cloudflare, they still don't even have Gitlab integration.
| deltron3030 wrote:
| The 25mb limit in folder size isn't enough for mid-sized
| blog though, even if you host the images somewhere else.
| WORMS_EAT_WORMS wrote:
| I think an executive has commented before that is not going
| to happen. Things can change though.
|
| If I were Vercel, absolutely would not sell either. They
| aren't like "Netlify" and positioned to be truly the goat of
| serverless.
| skrebbel wrote:
| > They aren't like "Netlify"
|
| What do you mean by this?
| sholladay wrote:
| Rich Harris has done a lot of great work. Until esbuild came
| along, Rollup was the only sane JS bundler for those of us who
| can't stand Webpack. Svelte has some interesting concepts, albeit
| I am planning to stay with React. His code is always interesting
| to read.
|
| Then there's Vercel. I was a big advocate for them years ago,
| back when they were Zeit. I used them in production at multiple
| companies and I contributed to their CLI to improve its error
| handling. But they really screwed me as a vendor with changes to
| their hosting platform and then again with changes to their
| authoritative DNS service. They broke every promise or
| expectation they ever set with me and reversed practically every
| facet of their original philosophy as a platform. They are
| bordering on being on my "never again" list. I hope Rich is
| genuinely able to stay independent creatively.
| enumjorge wrote:
| Maybe I'm misreading your comment, but Richard Harris did not
| create esbuild. Evan Wallace, co-founder of Figma, is the
| person behind it.
| kevinak wrote:
| This is such amazing news! Betting on Svelte was the best thing
| ever for both my career and sanity. I'm now heavily involved in
| the Svelte community and next Saturday we'll be hosting our
| fourth conference solely dedicated to Svelte.
|
| If you're interested in checking it out the URL is here, it's
| free and will be streamed on YouTube: https://sveltesummit.com
|
| There are also two watch parties that will be hosted in New York
| (Rich will attend!) and in Mainz, Germany.
|
| Links: - https://lu.ma/sveltenyc -
| https://lu.ma/sveltesummit-2021-mainz
| fidesomnes wrote:
| I guess you could say I don't care.
| MisterBastahrd wrote:
| It'd be more fun if I could do it in something that wasn't in
| Javascript or one of its Frankenstein cousins.
| tempest_ wrote:
| You can!
|
| Elm is interesting, though it's developer is a bit polarizing
|
| Also there are a host of nascent Rust/WASM frameworks starting
| to pop up. They really like the tree puns. There is Yew,
| Sycamore and Seed.
| tormeh wrote:
| That's still all web tech, though. Druid and Iced look more
| interesting, as they are general UI frameworks which lets you
| build both web and desktop apps without dealing with HTML or
| CSS.
| cutler wrote:
| Don't forget Clojurescript.
| clivestaples wrote:
| I do React for my day job. For personal projects and MVPs, I
| came back to Rails and it has been insanely fun. I can drop in
| whatever frontend framework I want or none at all.
| slantyyz wrote:
| With Sveltekit, you can actually build your back end with it
| as well. The path based routing is so nice and intuitive
| (compared to my recollection of Rails 3.x), and if you
| compile your SvelteKit application with the node adapter, it
| will include a back-end server too.
|
| The only catch of course, is that you have to like both
| Svelte and NodeJS.
| jhgb wrote:
| Is there any reason why something like Svelte couldn't be
| written in one of the lisply languages? The compiler approach
| seems definitely like a good fit.
| rglover wrote:
| JavaScript-based but plain HTML/CSS/JS. No Mary Shelley:
| https://github.com/cheatcode/joystick
| Graffur wrote:
| Because of redwoodjs, I've gone off Svelte a bit
| joshgrib wrote:
| I've been a fan of Svelte and Vercel for a while so it's cool to
| see Rich working with them, and for Svelte to get more support.
| Very excited to see what comes of this!
| DonHopkins wrote:
| I've been following Svelte, and it sounded great, so I've wanted
| to use it for some time. Now I've finally started a project with
| SvelteKit, and it's even better than I hoped, with extra layers
| of greatness I didn't even realize, like pre-rendering pages, at
| the same time as being very mobile SPA friendly.
| slantyyz wrote:
| My favorite feature of Sveltekit is probably the server-side
| endpoints. It's so easy to create an API using them.
| arberx wrote:
| Svelte is fucking awesome.
|
| Long way to go to catch up to React, but it'll get there. No
| brainer.
| Donckele wrote:
| Yes, it is good. In many ways I hope it doesn't catch up to
| React - it's running a different journey which I also prefer.
| arberx wrote:
| Catch up in terms of hirability/company usage.
| smt88 wrote:
| Yeah, I stupidly started some projects with SvelteKit
| instead of NextJS and am having a very hard time finding
| people to work on them.
| lucasyvas wrote:
| Consider trying to hire outside Svelte - Anyone that can
| write using the major frameworks will do just fine. If
| the problem is candidates uninterested in using it,
| that's a different problem.
| smt88 wrote:
| This is what I've done, but it's still hard to find
| someone who will do things in idiomatic Svelte.
| _fat_santa wrote:
| I think the problem Svelte is having in this area is
| folks looks at it the same way they look at React,
| Angular and Vue. All those frameworks (especially React
| and Angular) have their own way of doing things, so you
| have to know "HTML, CSS, JS and React/Angular".
|
| I think folks think that Svelte is the same way, while it
| does have it's own special sauce, it's nothing compared
| to React/Angular. Like others have said, when hiring for
| Svelte, you don't really need the candidate to have
| Svelte experience.
| [deleted]
| FractalHQ wrote:
| Have you made a post on the Svelte discord #jobs channel?
| All job postings that go up there get gobbled up pretty
| quickly.
| cphoover wrote:
| I'm tired of having to learn yet another templating language
| without a very compelling reason.
|
| Why do I have to learn, what is essentially, a new programming
| language for each of these frameworks (Angular, Svelte, Vue,
| React... Do I really need to learn yet another language construct
| for stuff like `loops`, `if/else`, event handlers...etc.
|
| Why must all of these frameworks re-invent the wheel?
|
| At least with React it is most close to the languages we already
| have learned, JavaScript, and HTML.
|
| From what I can tell Svelte looks similar handlebars templating
| with it's own unique syntax variations... I can't count how many
| different versions of the same thing I've had to relearn again,
| and again.
| tpict wrote:
| JSX is syntactic sugar for `React.createElement(...)` (most
| commonly), so React pretty much _is_ plain JavaScript.
| kall wrote:
| Yeah, It's my favorite templating abstraction because I could
| convert it by hand and so I don't really need to mentally
| model it as an additional layer.
| gaws wrote:
| You're getting flamed on Twitter for this comment lol:
| https://twitter.com/dancow/status/1458906853488967684
| dbbk wrote:
| React is a free for all, you can render pretty much anything
| you want at any time. With templating languages, the DOM output
| can be statically analyzed at build time, so the amount of work
| needed to diff the HTML output when things change at runtime
| can be dramatically shortened.
| d23 wrote:
| As a backend guy who moved away from frontend long ago for
| these very reasons, I have to ask: why are people downvoting
| this? Is it wrong? I'm genuinely asking, because from a
| bystander's point of view, it certainly seems like the pattern
| of the Framework Du Jour hasn't really slowed down much in the
| frontend community.
| SparkyMcUnicorn wrote:
| I didn't downvote, but I'll speak to my experience.
|
| First off, you don't have to go learning every framework out
| there. Pick one and stick with it, or just go vanilla. That
| said, The features these frameworks provide gives a boost in
| productivity that far outweighs the low learning curve.
|
| My pick was VueJS and I'm very happy with it. Using Single
| File Components is pretty similar to vanilla HTML/JS/CSS.
| Beginners that were under my guidance (with only HTML/CSS/JS
| experience) usually pick it up and were productive in the
| same day.
|
| I disagree that React (JSX) is most similar to vanilla
| JS/HTML at all (I don't prefer it, but to each their own).
| Vue and Svelte are much further on the side of a vanilla-ish
| approach.
| spoils19 wrote:
| Frontend developers like to change frameworks every week it
| seems like, so it's in my best interest to learn every
| framework (or at least some abstracted part of it) in order
| to stay employable and up-to-date.
|
| The problem is that each framework has their own
| abstraction and language that you have to learn. Compare it
| to "old-school" Java frameworks, where things were much
| simpler and you didn't have to worry about egregious layers
| of complexity to just render a DOM.
|
| Grumble grumble
| mikewhy wrote:
| > Frontend developers like to change frameworks every
| week it seems like
|
| This sentiment is so old and played out.
| 2muchcoffeeman wrote:
| Is it false though? If it's true, then maybe we need to
| look at why it's true.
|
| It's not just front end developers though. I think other
| domains and their frameworks went through the same thing.
| This is just the time for front end.
| winphone1974 wrote:
| Why is no complaining that there more than one way to
| build a php app? Perhaps because like JS it's a huge
| ecosystem with a giant user base and millions of use
| cases. Front end dev has lots of room to support the
| dozen or so mainstream frameworks we've used over the
| past decade-plus
| tshaddox wrote:
| Indeed, it's false. React is 8 years old, and when React
| was first released jQuery was only 7 years old. I follow
| this stuff pretty closely and I can only think of _maybe_
| 10 JS UI frameworks that have attracted remotely
| significant use and active development at any point in
| the past 15 years.
| vosper wrote:
| Yes, it is false. Anyone in the space can tell you how
| stable things have been for years now.
|
| Plus, there are a _lot_ of people writing JS. It's not a
| tiny community fracturing itself over different ways of
| doing things, and becoming destined for obscurity. It's
| tens or hundreds of thousands of developers. In a
| community this big I'd say having a few choices is a sign
| of health.
| vosper wrote:
| Agree, and it's nice to see this worn-out trope getting
| downvoted for once. Sneering at JS / Frontend developers
| is one of the more distasteful tendencies of HN.
| spoils19 wrote:
| Probably because it's an entire industry that is self-
| sustaining, without really a reason for it to exist. Most
| software can be built with regular HTML / JS / CSS
| without some convoluted framework. Even better, let's
| make a desktop application (when was the last time we had
| those?!), and we can get all kinds of performance and
| security gains without having to tack everything on to
| the web as a platform.
| winphone1974 wrote:
| The "just build a desktop app" trope is even more played
| out.
|
| Plus you know all these front end frameworks are "just
| HTML/ JS/CSS" right?
| dmitriid wrote:
| > Frontend developers like to change frameworks every
| week
|
| React is 8 years old
|
| Vue is 8 years old
|
| Svelte is the relative newcomer, at 4 years (and the
| major third version at ~2 years).
|
| The idea of "frameworks are changing every week" hasn't
| been true in a very long time
| [deleted]
| jayflux wrote:
| > Frontend developers like to change frameworks every
| week it seems like
|
| React is now 8 years old... so is Vue. What are these new
| frontend frameworks you keep seeing?
| l30n4da5 wrote:
| > Frontend developers like to change frameworks every
| week it seems like
|
| Most of the popular frontend frameworks (Vue, React,
| Angular, Svelte) have been around for years at this
| point. It is like arguing Ruby on Rails vs Spring Boot.
| breakfastduck wrote:
| 'Frontend developers' like who exactly?
|
| Anyone that's worked in a reasonably sized FE codebase
| can very clearly understand that changing your framework
| is essentially migrating a huge production DB but on
| steroids.
|
| Where exactly have you seen a team of developers change
| their front end framework every week?
| sam0x17 wrote:
| Well in this case, it's more that svelte is the least of all
| evils when it comes to this. React and Vue have way more
| boilerplate and React in particular has the most framework-
| specific stuff of them all. Svelte is much closer to pure
| html/css, or so I'm told.
| winphone1974 wrote:
| I assume because there's no value to it. What's the opposite
| side of the argument? You have an area with a lot of growth
| and many problems with the way we're solving these problems
| and something like svelte is not"completely reinventing the
| wheel" as the OP positions it, by nature it's try to solve
| specific problems using our existing tooling whenever
| possible. The original post is a shallow, feel-good rant
| fendy3002 wrote:
| I've used react for some years now and it's very very hard to
| do animation and event-driven operations with pure react
| render. You'll need extensive lifecycle events or hooks and
| refs to get animation or handle focus, etc well. It's due to
| how react render the components.
|
| It doesn't make react bad but I guess some newer frameworks
| (vue, svelte, I haven't learned those yet) try to tackle this
| from different approach.
| wishinghand wrote:
| It's a false truth that anyone has to learn yet another one
| of these. Even Angular 1 and Backbone.js are still in
| production.
| sergiotapia wrote:
| So is Joomla - yet I wouldn't recommend people learn it
| today. Might as well learn COBOL and Zend Framework too.
| locallost wrote:
| It might be true, but it's a rant that just barely touches
| the actual topic, which is mostly: a company will pay
| somebody to work full time on an open source project that is
| still independent. And I think it's pretty nice. And also I
| think Rich Harris has given a lot to people for free and I'm
| happy for him that he will be paid to work on something that
| he loves.
|
| So all in all it would be nice if we would for once be spared
| of rants how tiring, immature, half baked whatever whatever
| the JavaScript world is. Show us maybe how it should be
| really done, but maybe in a separate post please.
| ramesh31 wrote:
| > I'm genuinely asking, because from a bystander's point of
| view, it certainly seems like the pattern of the Framework Du
| Jour hasn't really slowed down much in the frontend
| community.
|
| Perhaps not in the "frontend community", no it hasn't slowed
| down. There will always be new frameworks coming and going,
| and people will work on them as fun open source projects or
| use them in their side projects or whatever. But people doing
| real work are almost unanimously settled upon React as an
| industry standard at this point. There's still a decent sized
| faction of contrarian Vue holdouts, but by and large the JS
| framework wars are over.
| rglover wrote:
| No, it's not wrong, it's absolutely correct. There's a lot of
| flexing around who can come up with the most elegant
| abstraction which ignores the important point: making sure
| what's necessary to understand the framework, use it long-
| term, and move away from it after is focusing on the core
| technologies of the web (HTML, CSS, and JavaScript).
|
| The abstractions are cool, but completely unnecessary (see
| link to my framework above where I circumvent that problem
| entirely).
| tshaddox wrote:
| I don't know about "wrong," but my opinion on the overall
| theme of that first comment is that the requirement to learn
| is not at all a bad thing. I enjoy learning new things even
| when that is in some sense a "requirement."
| lowbloodsugar wrote:
| Didn't downvote either. Almost consider upvoting for
| visibility of the hilarity displayed.
|
| "There are too many frameworks! Why does everyone keep re-
| inventing the wheel? _Why can 't everyone just use the one
| that I like?_"
| cphoover wrote:
| I never asked anyone not to use svelte... I said why should
| I be compelled to learn this new language, other than it
| being the hot new UI framework of the day.
|
| It doesn't have a virtual DOM? It doesn't have synthetic
| events? Ok why not just use web components which provide
| their own encapsulation and vanilla JS. I don't have to
| learn a new language which may or may not be
| around/supported a few years from now... Also I'm
| continuing to grok web standards.
| gherkinnn wrote:
| You don't need to know every framework. And that little bit of
| custom syntax is peanuts compared to how the rest of these
| differ.
|
| Even if Angular and React shared the same templating syntax,
| you'd still be left with 95% of work ahead of you.
| bryans wrote:
| This is very overdramatic and isn't actually based on reality.
| Svelte is far closer to vanilla JS/HTML than any other
| framework, while also using extremely similar patterns from the
| other modern frameworks. Yeah, it has some sugar, but it's not
| just some templating system any more than React is just some
| templating system, and the only "unique syntax" you could be
| referring to is the auto-subscription to stores using $, which
| is super convenient.
|
| You're acting incredibly disinformative, and have no legitimate
| basis for your assertions.
| rglover wrote:
| You'd like https://github.com/cheatcode/joystick.
|
| No special languages or syntax. Plain HTML, CSS, and JavaScript
| with the same reactive UI stuff in all the other frameworks.
| It's also part of a full-stack framework so you can whip up
| lightweight, fast apps.
|
| The best part is your skills are transferrable as I'm not
| introducing any domain-specific abstractions. You can go from
| learning HTML, CSS, and JS to this without any "gotcha" in the
| process.
| unclebucknasty wrote:
| The problem with each of these frameworks is that they make the
| mistake of surfacing the underlying standards like HTML and the
| DOM. This is why they look remarkably similar and can only
| possibly be incrementally better, at best.
|
| HTML and the DOM are still essentially modeled on static
| documents. Building apps that deal directly with these
| standards is an impedance mismatch that, remarkably, people
| keep trying to solve by adhering to those same standards, but
| in a slightly different way.
|
| Why should we know or care about HTML or the DOM?
|
| A robust, event-driven, component-based framework that manages
| the low level Web standards could offer true advancement.
| hijodelsol wrote:
| For me Vue 3 with <script setup> get's pretty close to pure
| JavaScript/TypeScript. 90% of the code will be exactly like JS
| code, the only difference being the use of computed(), ref()
| and reactive() to achieve (something JS simply doesn't provide
| but is necessary for every non-trivial application). Your HTML
| code and CSS code are not mixed with JS and look and feel like
| the real thing as well. Other than the reactivity indication
| and the occasional onMounted(), etc. Vue 3 with <script setup>
| does away with all boilerplate and unidiomatic parts of Vue 2
| and imo is the framework that most closely resembles pure
| HTML/CSS/JS while allowing for far greater productivity.
| kall wrote:
| Are we still taking about vue <template>? I don't see how
| that is any way close to html when it has: custom conditional
| and loop syntax and semantics, arbitrary js expressions and a
| unique concept of scope?
| Drew_ wrote:
| It does have extra non-native features but the overarching
| <template /> <script /> <style />
|
| format for single file components is plain HTML which makes
| it feel closer to vanilla than React.
| kall wrote:
| Yeah I never really understood this benefit. The file
| structure is irrelevant to me after 15 minutes, the
| nitty-gritty semantics of my code are causing me
| headaches and bugs forever.
|
| (I like working with all 3 current frontend frameworks
| btw, not trying to start a flamewar)
| Drew_ wrote:
| I like it because it separates layout, styling, and
| scripting while still collating them in the same file.
| tootie wrote:
| Any new language/framework trying to sell me on it's improved
| ergonomics should not bother showing me syntax and instead show
| me a stack trace. Vue is really concise and expressive but
| seeing a pile of node internals on every typo is infuriating.
| Tarks wrote:
| Agreed, I thought we were past this with the 4th generation of
| these frameworks, this is like knockoutjs all over again.
|
| The moment the penny dropped for me was when I read something
| like this about React:
|
| "We realised that inventing our own Yet Another Binding
| Language that was less expressive than javascript was harder
| and worse than doing the work to put the relatively simple HTML
| constructs into Javascript"
| chrbp wrote:
| No one says you have to learn new languages or frameworks. It's
| really your own choice.
| jitix wrote:
| I used to be full stack before the re-invention of wheel
| phenomenon got way out of hand in the js world. Keeping up with
| what's going on with the ecosystem and employing the best
| practices became a huge chore that took time away from solving
| actual business problems.
|
| Turning away from front end let me concentrate time on learning
| devops, cloud, ml and other things that aren't as volatile in
| terms of design patterns and that lets me design more high
| level solutions to problems and create more overall value.
|
| Maybe people just differ in how wide or deep information they
| could handle but I certainly can't keep up with such a wide
| array of patterns and tools that do the same thing.
| travisl12 wrote:
| My solution is pretty easy to this problem: I don't.
| danny_taco wrote:
| I completely agree with you, and I've yet to see a compelling
| argument against this. I've been doing this since the rise of
| the SPA, all the way from vanilla, jQuery, Backbone, Angular
| 1.0, Ember and React and after reading your comment all I can
| think of is "great, we're going back to handlebars templating
| again".
|
| There is no net-gain in re-inventing the wheel. It just becomes
| yet another thing to master to stay relevant. In a decade of
| doing JS front-end applications things have only gotten more
| complex and more time-consuming.
|
| Thankfully I've found a sweet spot where complexity, velocity
| and quality are in balance using technologies considered no
| longer cool and that's fine with me. I get to focus on the
| actual problem at hand instead of trying to figure out the
| inner workings of this new shiny thing.
| [deleted]
| brundolf wrote:
| I don't love that aspect myself, but I have to point out that
| in Svelte's case it is definitely not "without a very
| compelling reason". The special build-time processing is the
| entire point of Svelte.
|
| Though personally I'd almost prefer it was a whole new language
| than a "kind of JS but with some (necessarily) new syntax"
| RoboticWater wrote:
| For all the use cases I deal with on a regular basis, Svelte
| looks more like vanilla HTML/JS than any equivalent React code.
|
| And the reason these things change is because _that 's what
| needed changing_. One of the topline features of Svelte is that
| is has less boilerplate than React, and it achieves that quite
| handily. Unless you're criticizing particular constructs in
| Svelte that are unjustifiably different, I don't think
| unfamiliarity is that damning a criticism.
|
| Maybe I'm just used to switching up languages on a regular
| basis, but the idea of having to learn different language
| constructs for loops and the like doesn't seem that herculean
| of a task.
| fron wrote:
| > but the idea of having to learn different language
| constructs for loops and the like doesn't seem that herculean
| of a task.
|
| I agree. As long as you understand the basic concepts, it's
| only a matter of learning the syntax, which is really not as
| big of a deal as the person you replied to is making it out
| to be.
| cphoover wrote:
| It's not a herculean task... I agree, until you've learned
| 10+ (angular, vue, svelte, wordpress/php, jade templates,
| laravel, underscore/lodash, handlebars/mustache, hugo,
| etc..) of these "super simple templating languages"! And
| keep them all straight. I have no problem learning a new
| language if there is a compelling reason. But If it's just
| additional shit I have to remember for no clear reason...
| No thanks...
|
| We can have a debate on unidirectional data flow vs 2-way
| binding, how each framework manages state changes, how
| opinionated each framework is... How mature and vibrant
| each developer community is... etc. These are all another
| discussion though. My question is why must we reinvent the
| wheel again and again.
| bryans wrote:
| You need to stop insisting that a wheel has been
| reinvented with Svelte. It shares 95% of the same DNA as
| other frameworks, with multiple improvements over them.
| So with that in mind, what you're actually suggesting is
| that the existing offerings were somehow perfect, and we
| don't ever need to improve on anything again. That is an
| absurd notion, especially given that the other frameworks
| have gone through MASSIVE changes since launch --
| sometimes even complete rewrites, because they
| acknowledged they got it wrong the first time.
| nnoitra wrote:
| What boilerplate does React have? Do you mean Babel?
| cphoover wrote:
| I know...
|
| This comment had no context...
|
| You don't have to even import React from
| 'react';
|
| anymore
| cphoover wrote:
| What how can you say that???
| <ul>{myItems.map({id, title}) => <li
| key={id}>{title}</li> }</ul>
|
| vs... svelte <ul>{#each myItems as item}
| <li>{item.title}</li> {/each}</ul>
|
| One is literally just javascript and html the other is an
| entirely different template language. You might say... JSX is
| not HTML... well it's very very similar... If you know HTML
| you JSX is very intuitive.
| pier25 wrote:
| Objectively, the Svelte example is cleaner and easier to
| read.
| kosolam wrote:
| Subjectively, I'd say. But since I agree that it's
| cleaner and easier to read- I upvote you
| spoils19 wrote:
| By what metric are you measuring it objectively?
| pineconewarrior wrote:
| density.
| epolanski wrote:
| Saying it is objective but not mentioning the reason
| really makes your statement subjective.
| diegof79 wrote:
| The issue is not only the syntax, but the semantics. What
| happens to the scope when you nest #each expressions?
| Does it work with iterables (like for..of), or it behaves
| like for..in? I don't use Svelte, and I don't know those
| differences by reading the code. To me the nice thing
| about JSX is that is straight forward with JS semantics:
| const a = <div prop={expression()} />
|
| is a DSL for: const a = factory('div',
| {prop: expression()})
|
| is only a DSL to create tree structures (React is another
| story, you can use JSX without React).
| subpixel wrote:
| I grant that it isn't Javascript and you have to get
| familiar with it. But at least it's not Hugo templating.
| ksdnjweusdnkl21 wrote:
| Seems like svelte is superior for not needing a key.
| winphone1974 wrote:
| The key is used by the shadow Dom for update performance;
| the is no shadow Dom in svelte
| cphoover wrote:
| fair criticism I wonder how svelte optimizes for
| rerendering of long component lists. React uses keys to
| avoid rerendering the entire list.
| benmccann wrote:
| But React isn't just JSX. It's also the entire runtime
| library, hooks, event handling, forms, state handling, etc.
| The example you shared is a bit too simple to understand
| where Svelte shines because it doesn't introduce any of
| those concerns.
|
| By having it's own templating language, Svelte is able to
| compile the templates to JavaScript in a way that addresses
| many of those concerns in a way that I think it easier to
| deal with as an end user of the framework.
|
| If Svelte were using JSX, I don't know that it'd be
| possible to do everything else that it does so simply
| because you can write anything that's valid JavaScript in
| JSX whereas Svelte has just a couple of basic control
| structures that its compiler can parse and convert to
| runnable code.
| [deleted]
| [deleted]
| noir_lord wrote:
| Not to mention it takes reactivity to new heights while
| adding amazingly little actual syntax.
|
| When property changes, the fetch refires, loading appears
| until the fetch resolves then it displays whatever array
| someFetch resolved to.
|
| I came from Vue and that plus the way Svelte does stores
| (literally nothing special about them) was a breath of
| fresh air. <div> {#await
| someFetch(property)}
| <div>Loading...</div> {:then data}
| {#each data as item, index}
| <div>{item}</div> {/each}
| {/await} </div>
| makeramen wrote:
| > If you know HTML you JSX is very intuitive.
|
| That's a poor assumption that appears to be based on your
| personal preferences and what you're comfortable with. I
| personally find both require some learning, but prefer the
| svelte version.
| DonHopkins wrote:
| And JSX isn't JavaScript and it isn't HTML, and if you
| know JavaScript and HTML you still don't know JSX, so
| you're still using "yet another language" in addition to
| JavaScript and HTML.
| hunterb123 wrote:
| JSX is JS. Nested brackets are simply converted to nested
| function calls & objects, attributes convert to
| properties.
|
| This is evident when comparing conditionals, loops, etc.
| Instead of learning template syntax you simply use JS
| syntax, albeit a declarative subset (no branches).
|
| JSX is simply syntactical sugar for nested JS, you can
| use it without, but it's prettier with.
|
| One could add this syntactical sugar natively to the
| language spec, in fact E4x (ECMAScript for XML) share
| some properties w/ JSX and was once proposed to the spec.
|
| edit: instead of downvoting, please voice how you
| disagree with my assessment
| cphoover wrote:
| I agree 100%... Adding JSX to the language spec would be
| interesting. It might be too heavy to include within the
| language spec as many JS applications do not involve the
| DOM at all, so then you have to essentially bundle DOM
| functions into every application... or common.js would
| omit this subset of the language.
| hunterb123 wrote:
| It's actually a fairly small change, the spec is here:
|
| https://github.com/facebook/jsx
|
| Example parser from Acorn:
|
| https://github.com/acornjs/acorn-jsx/blob/master/index.js
|
| No part of JSX uses the DOM, it doesn't share anything
| with HTML.
|
| The JS engine itself would need the modification.
|
| Also JSX doesn't have to be for the UI, it could be for
| dialogs for an NPC in a game, for configs, etc.
| dwaltrip wrote:
| Come on... If you know JavaScript and HTML you are 95% of
| the way to being fluent in JSX. It's basically just
| JavaScript expressions.
| proxyon wrote:
| JSX is just JS with brackets instead of nested function
| calls. I expected more from this community than this kind
| of commentary.
| alvarlagerlof wrote:
| At least it's pretty much only built up of J's and html
| instead of something entirely different.
| Ambroos wrote:
| JSX is easy to summarize as: HTML where everything in
| curly brackets is a JS expression that gets evaluated.
| There are some additions (prop spreading) and
| restrictions (curly brackets apply to whole attribute
| values and element bodies only), but they're very simple.
| ricardobeat wrote:
| And custom event handling attributes, camel casing,
| special cases like htmlFor and className, non-standard
| attributes being ignored except for custom elements, the
| style attribute, the special case of checked/selected
| properties vs attrs for form elements, key and ref
| properties. Plus all the semantics of component updates,
| memoizing and so on.
|
| This is already far more to learn than the handful of
| simple control structures Svelte introduces.
| adamnemecek wrote:
| The templating language is the easiest thing to learn. The
| hardest is architecture.
| block_dagger wrote:
| This is why I have focused on backend for the last decade.
| Donckele wrote:
| Great news for everyone using Svelte - a good move by Vercel and
| wish Rich gets more resources and freedom to continue the
| refinement of Svelte.
| kaddywampus wrote:
| how
| crummy wrote:
| I have a stupid question:
|
| The cool thing about Svelte is that it compiles your code in a
| way so that when variables change, bindings in HTML change, but
| only that HTML and not an entire DOM re-render. (Right?)
|
| So, if this is the case, how come React couldn't do the same
| thing? They'd lose the ability to just include react in a script
| file, but why can't a smart compiler look at your JSX and throw
| out the virtual DOM component, so your variables are directly
| bound to where they're used in the HTML?
| swyx wrote:
| i did try that -
| https://twitter.com/swyx/status/1294310598419689472 but when
| the core team is not interested in it there's only so much i
| want to push it on my own - rather just move to Svelte where
| the community already gets it
| travisd wrote:
| Looks great! Seems to me that there's just not enough pain
| around this. Ironically, React being "good enough" at
| performance (in most cases) probably means that there's not
| appetite for squeezing out the last few millimeters (again
| for the vast majority of use cases -- clearly there is some
| need otherwise svelte wouldn't exist).
| samc98 wrote:
| The React team had explorations of a compiler for React, I
| believe -
|
| https://github.com/facebook/react/issues/9223
| https://github.com/facebook/react/issues/7323
| https://github.com/facebook/react/issues/7324
|
| I also think this is why facebook had been investing in
| `prepack` - https://github.com/facebook/prepack
| travisd wrote:
| This might be possible in simple cases, but there are two
| reasons I think.
|
| 1. React has an ethos of being "just JavaScript" (despite the
| JSX syntax which is purely sugar around calls to
| React.createElement). This means the core team doesn't seem to
| be interested in adding an extra compiler step. 2. Related to
| the above, because React is just JS, you can do all the normal
| and horrible things with it you can do in JS. Wanna pass React
| elements around in context or even using global variables?
| That's allowed. A compiler could probably handle a lot of
| simple cases but there's a whole lot of things it wouldn't be
| able to deal with.
| fuzzy2 wrote:
| Hm, I think this isn't possible with React. You'd have to
| impose lots of constraints on how a component renders.
| Currently it's basically anything goes. IMHO, the result just
| wouldn't be React anymore.
|
| In fact, Angular works exactly like this. Only the DOM nodes
| that have bindings/directives attached are updated, the rest is
| static during a component's lifetime. Though all this still
| involves tons of runtime framework code.
| cphoover wrote:
| IMHO 2-way data binding isn't all that useful.
|
| Because the difficult thing in UI programming is not changing a
| field in a template when a text field updates...It's how do you
| propagate data throughout your application while at the same
| time limiting where changes to that data can be made. React
| stresses that props are immutable. React is designed the
| concept of unidirectional data-flow... so a subcomponent cannot
| update the state passed down from it's parent, data updates can
| only be propagated down the component tree and not the other
| way around...
|
| This is not the case in svelte:
|
| App.svelte <script> import Nested
| from './Nested.svelte'; let blah = 1234;
| function handleClick() { blah++; }
| </script> <Nested {blah} /> <button
| on:click={handleClick}> Clicked {blah} {blah === 1 ?
| 'time' : 'times'} </button>
|
| Nested.svelte: <script> export let
| blah; blah = 4321; </script>
| <p>This {blah} is another paragraph.</p>
|
| The above will display:
|
| This 4321 is another paragraph.
|
| [Clicked 1234 times]
|
| Because the child is able modify the state of it's parent...
| because of this state updates can be made anywhere in the
| component tree...
| dbbk wrote:
| I actually think Ember/Glimmer happens to have the best
| implementation of this, where their diff can be incredibly
| optimised because they know the semantics of the template and
| can just skip all work on static elements and attributes that
| never change.
| keb_ wrote:
| This is awesome. Next.js is garbage so hopefully SvelteKit gets
| all the love and attention from now on.
| _fat_santa wrote:
| My biggest issue with NextJS is next/image vendor locks you
| into Vercel.
| bradleyg_ wrote:
| You can use netlify-plugin-nextjs -
| https://github.com/netlify/netlify-plugin-
| nextjs/blob/v3/doc... to host on Netlify.
|
| And of course any regular NodeJS server works with next/image
| - https://nextjs.org/docs/deployment#other-hosting-options
| leerob wrote:
| `next/image` works self-hosted (it uses either Squoosh or
| optionally Sharp) as well as with any third-party solution
| you want. Vercel is just one choice!
|
| https://nextjs.org/docs/basic-features/image-
| optimization#lo...
| gavinray wrote:
| Well, this is awesome -- but fuck me: Vue is the only major
| player not under the Vercel umbrella now, haha.
|
| Looks like I might have to phone in half a decade of experience.
|
| Svelte is close enough to Vue with "script setup" mode anyways,
| the major difference is whether your logic/keywords go INSIDE the
| HTML tags or OUTSIDE.
|
| Svelte doesn't support JSX/TSX though =(
| ravenstine wrote:
| If no one has managed to add JSX, I believe it would be
| feasible to implement. The Svelte compiler is pretty straight
| forward to interact with. However, I have little experience
| with the semi-standard build toolchain for Svelte that most
| people are using. You would of course need to import React.
| leerob wrote:
| Lee from Vercel here. The governance of Svelte isn't changing -
| it's still the same independent, open-source project and
| community. We're just supporting Rich and helping the project
| grow!
| gavinray wrote:
| Absolutely, but in my mind this means Rich/Svelte have been
| "blessed", and I've built enough Next.js apps to know that
| you aren't going to find a better Dev UX/superior experience
| to what Vercel is providing.
|
| Benefits of being a framework owned by a business that makes
| a lot of money off of it.
|
| Next.js 12 as any indicator, I'm just going with whatever
| falls under the Vercel umbrella now -- I can tell you that
| Nuxt is not a competitor (as an unbiased voice and someone
| who doesn't particularly love React).
| _benj wrote:
| Glad to see you here Lee!
|
| > We're just supporting Rich and helping the project grow!
|
| I'll admit that I have a negative bias towards this... in
| spite of Basecamp+RoR, Mozilla+Rust, or all the great OSS
| HashiCorp makes, it's still hard for me to believe that
| business do anything out of the goodness of their heart.
|
| Is there a strategic goal for hiring Rich? is it that Svelte
| is used so much in house that it only made sense to support
| it? Is it to get more cred with developer by supporting
| projects they love?
|
| Again, sorry if this question is to skeptic and cynical... I
| love to be wrong on this! :)
| leerob wrote:
| https://news.ycombinator.com/item?id=29192174
| sxiao wrote:
| > The governance of Svelte isn't changing
|
| This is the standard narrative when OSS contributors got
| hired but ok, I'd write the same.
|
| But then just tell us what was the motivation of Vercel's
| shareholders and CEO to acquire Rich for such a high price
| (he is the compensation and ESOP you pay absolutely worth)
| but what's your gain? "Just supporting Rich and helping the
| project grow" or just buying him out of the market?
| Rauchg wrote:
| On a high level: if Svelte succeeds, the Web succeeds and
| Vercel succeeds.
|
| More concretely: we want Rich to help shape Vercel's
| support for frameworks as an open platform. We want to hear
| how, as a framework creator, the platform can best serve
| him. We project this work will have ripple effects like
| making Astro or Remix better on Vercel, or the next
| framework _you_ invent. You 'll hear about this work soon.
|
| We want to hear what edge infrastructure would make Svelte
| the fastest for developers _and_ visitors. We want to also
| help him build a better Svelte by connecting him with
| customers who are betting on it in production. We want to
| learn from his DX expertise so that we can make better
| products.
|
| We are very excited about this and we think betting on Open
| Source for the SDK together with an Open Platform for
| infrastructure is the only way to succeed in our space.
| Keats wrote:
| > Svelte doesn't support JSX/TSX though =(
|
| You have https://www.solidjs.com/ that does
| protonimitate wrote:
| Admittedly I haven't followed Svelte super closely, but isn't
| "no JSX/TSX" kind of a major ideological point? From reading
| the intro docs, it seems like separation of js/css/html is a
| selling point. JSX/TSX would contradict that, no?
|
| Just wondering if my read is correct or if there's some other
| reason it's been left off the table.
| nicoburns wrote:
| Nobody truly separates JS from HTML. You either have to put
| something HTMLish in the JS, or something JSish in the HTML
| (HTML itself supports this of course).
|
| IMO the HTML-in-JS solutions (i.e. JSX) are superior to the
| JS-in-HTML solutions (e.g. Angular/Vue Templates) because
| they put the standardised turing-complete language in the
| driving seat rather than the propriety, hard to extend
| template language.
| swyx wrote:
| it is. HTML is the first language of the web, not JS - this
| is why framework agnostic libraries are so much easier to
| use with Svelte than with React.
| gavinray wrote:
| Solid is really cool, and I love the posts by it's author
| describing the journey to performance that is some years old
| now.
|
| But what is unique about Vue is that it lets you arbitrarily
| mix ".vue" and ".jsx/.tsx" files in the same project.
|
| So if you need to define say 50 really tiny helper
| components, like "Button", "Modal", etc. it's great.
|
| I can write one TSX file and do: //
| UtilComponents.tsx export function Button() {}
| export function Modal() {} export function Icon() {}
|
| And then in my .vue file I can do: <script
| setup lang="ts"> import { Button, Modal, Icon } from
| "./UtilComponents" // ... </script>
|
| This is not a popular approach, almost nobody uses Vue's
| JSX/TSX and I'm not sure if people even know you can mix and
| match arbitrarily like this.
|
| But I've been doing this for a long time and it works great
| for me haha.
| richeyryan wrote:
| This is a really cool idea. This has always been my biggest
| beef with single file components. It never occurred to me
| that you could do this with Vue. Thanks for the tip
| pjungwir wrote:
| I've been using Solidjs the last month for a project, and I
| really like it. Small bundle size, super fast, not much to
| learn, not too much magic, lots of control. Basically instead
| of having a vdom the framework is able to track finer-grained
| reactive sites and update those when the data changes.
| [deleted]
| rglover wrote:
| Check out what I'm working on. I'm staying indie indefinitely:
| https://github.com/cheatcode/joystick.
|
| No JSX or other templating languages, just plain HTML.
| pier25 wrote:
| > Svelte doesn't support JSX/TSX though =(
|
| It actually supports the next best thing: HTML!
|
| Now in all seriousness, JSX does have its benefits like being
| able to write a small function that returns a piece of JSX. But
| in my experience, using Svelte is a huge productivity booster
| than I don't mind losing JSX's benefits.
| systemvoltage wrote:
| I love Vue because I come from a bygone era of HTML +
| sprinkling jQuery as needed. 99% of the websites don't need a
| full blown JS frontend but everyone is doing it, I must be
| wrong.
| GordonS wrote:
| Well, I guess I'm wrong too then, as most web apps I create
| are SSR (with dotnet), with a sprinkling of vanilla
| JavaScript. Previously I used jQuery, but we're _finally_ at
| the point where it 's not necessary.
| dexwiz wrote:
| Do you work with a designer? I'm convinced most of the push
| for JS apps as pages is mostly perpetuated by designers who
| don't know how the DOM works and feel the need to redesign
| the wheel on every project. I work within a company that
| provides a design system and a platform of hundreds of
| generic component, but individual designers still always want
| to push their particular vision.
|
| I think if most designers took existing web elements and
| tried to build a UI, instead of drawing an arbitrary picture
| and asked devs to implement, we would have much less JS
| overall.
| The5thElephant wrote:
| Product designer and HTML/CSS person here, and in my
| experience it is the opposite. Designers and front-end
| focused people wh get a chance to work with Vue love it
| because it actually respects basic HTML/CSS/JS and doesn't
| encourage doing everything in JS, unlike React which
| basically forces your hand. This makes working in Vue (and
| Svelte) so much more accessible to people who are great at
| HTML and CSS but not JS as much (and in my experience many
| React devs are great at JS and terrible at HTML/CSS).
|
| Designers more often know HTML and CSS over JS, so it is
| unlikely they are the ones pushing for JS solutions. It is
| the developers who don't know how to implement designs
| without falling back on JS for everything who are causing
| this paradigm.
|
| That being said I blame a lot of this on design tooling as
| well. Figma and Sketch are custom rendering engines that
| just don't understand HTML and CSS and therefore give no
| opportunities for designers to learn how the web works.
| Fortunately a new generation of design tools are coming
| that are built on HTML/CSS renderers that feel like Figma
| but actually output usable code for devs to interpret into
| their projects.
| miguel-muniz wrote:
| > Fortunately a new generation of design tools are coming
| that are built on HTML/CSS renderers
|
| These days I spend more time in browser devtools than
| Figma, and honestly I'd prefer a more visual way to edit
| code directly. Something like Webflow but without all the
| cruft behind it. Preferably built into devtools, maybe as
| an extension
| miguel-muniz wrote:
| Do the designers you work with have experience with front-
| end development, or have access to your design system in
| their design tools?
|
| It sounds like an issue that can be resolved with some
| communication
| systemvoltage wrote:
| No, we don't have a design team, we're too small for that.
|
| Just that our backend is already built using Django many
| many years ago. If I need to add some interactivity, I use
| jQuery currently. Looked into Vue and it allows us to keep
| everything as is in the backend and use it like jQuery.
|
| I shudder everytime I need to install npm, webpack, gulp,
| etc..all the JS tools feel super flaky, unnecessary and
| does not inspire confidence in the tooling. That's my take
| anyways.
|
| Lot of developers don't have the priviledge of starting a
| new project. It's an existing doctors appointment website
| or some shit people cobbled up in PHP in 2004 that is still
| running and we need to maintain it.
| radus wrote:
| I totally identify with your aversion to build tools, but
| things have changed for the better in the last few years.
|
| My advice would be to check out Vite, and use it with
| Vue. I've introduced Vite/Vue2 to a pre-existing Django
| project and couldn't be happier. I've explored a number
| of different approaches for integrating Vite and Django,
| and this blog had the best approach, IMO:
| https://weautomate.org/articles/using-vite-js-with-
| django/
| gavinray wrote:
| > "I shudder everytime I need to install npm, webpack,
| gulp, etc..all the JS tools feel super flaky, unnecessary
| and does not inspire confidence in the tooling. That's my
| take anyways."
|
| For context, I started doing web dev back in ES5 JS,
| jQuery, Angular.js (1), and server-side templated HTML
| views days.
|
| I write in a lot of other languages as well, and I would
| hear people say this and not get it. I thought to myself:
|
| _" It's not THAT bad. I think the experience is fine."_
|
| Then I wrote an app recently on the JVM. Sweet jesus the
| JS/Node ecosystem is a nightmare + house of cards.
|
| The JVM and CLR (.NET) have their stuff together. I need
| like ~10 dependency libraries to do a large project, and
| often times they are over a decade old.
|
| The tooling is on another level.
|
| I don't have PROBLEMS writing TS apps, and the experience
| is good. But some of them have a dependency tree that
| span thousands of packages, and I've come back 2-3 years
| later to try to run a project and had some downstream dep
| break, and then updating fails, and then...
|
| I know it's somewhat of a meme, but this is unironically
| why I find Deno interesting. (Disclaimer: Haven't shipped
| anything with it)
|
| Especially since with the most recent release, they have
| an option to emit Node-compatible JS bundles from Deno
| code.
| hamilton wrote:
| I find that Svelte is the most "jQuery-friendly" of the
| frameworks. I can easily add a single Svelte component back
| into other wise static pages without requiring anything
| other than a simple build tool to output the JS + css. It's
| really the best of both worlds - sprinkle it in where
| needed, or go whole-hog.
| dceddia wrote:
| Yeah, I really like Svelte for this. I did a whole blog
| post this way, with little embedded animations to show
| various operations on linked lists. Each of the
| animations is a Svelte component, but the surrounding
| page is just a static HTML page created from Markdown
| (using Jekyll as the generator).
|
| It's nice that Svelte components can be independently
| mounted like that.
|
| Right click > View Page Source, and scroll to the bottom
| to see how all the Svelte components are mounted:
| https://daveceddia.com/linked-lists-javascript/
|
| To be fair, the same thing would be possible with React
| or the other frameworks. I do like that it's only 29kb of
| JS for all those animations though (and most of that is
| the SVGs, I think).
| romero-jk wrote:
| You can "sprinkle" react too
| lioeters wrote:
| Yup: https://reactjs.org/docs/add-react-to-a-website.html
| systemvoltage wrote:
| Not as well as Vue.
|
| Vue is just straight forward exactly like jQuery:
| https://www.smashingmagazine.com/2018/02/jquery-vue-
| javascri...
| solarmist wrote:
| So I'm a backend engineering, but have experience with Vue.js and
| like it.
|
| Why would I want to rethink that and try out Svelte?
|
| Reading about svelte the main advantage seems to be everything
| building to raw JS making it faster.
|
| Questions:
|
| Is there typescript support? I would assume, but...
|
| Does this end up with smaller bundles/js files?
|
| Any other major advantages?
|
| From some reading syntax seems pretty similar to Vue as well.
| yroc92 wrote:
| There is typescript support.
| aarpmcgee wrote:
| The TS ergonomics still have a long way to go, imo. Typing
| components is a little bizarre
| -https://github.com/sveltejs/language-tools/issues/442
| tropix126 wrote:
| 1. Yes there is typescript support.
|
| 2. Compared to React yes, because Svelte ships no runtime (or
| at least a very minimal one). There is a curve though, and very
| large apps (in the hundreds of components) will eventually be
| overtaken by something like Preact or vue.
|
| 3. No runtime means no restrictions on what they include in the
| framework. They take full advantage of Svelte being a compiler
| and include things like complex state management in the form of
| stores, a built-in transition/animation system with support for
| springs. Also the included syntax is extremely concise, if
| you're familliar with vue it'll be fairly easy to pick up.
| solarmist wrote:
| > They take full advantage of Svelte being...
|
| They? Libraries?
| tropix126 wrote:
| The Svelte core team. All of the features I mentioned are
| included in the framework without the need of external
| libs.
| sxiao wrote:
| Am I the only one?
|
| Next just bought its biggest upcoming competitor--SvelteKit. Next
| is the best that React has to offer but it still has flaws.
| Svelte and SvelteKit are so awesome you cannot believe it before
| you've built something bigger and so much ahead of the entire
| React ecosystem. We migrated a huge/complex React app in a month
| and the difference is night and day (performance/bundle size/dev
| productivity). React was great but it's time to move on.
|
| I'm disappointed by Rich. Instead of thinking bigger, raising
| money (it would have been so easy, Rich, instead of doing proud
| conference talk after talk why didn't you talk to a VC??)--he
| just cashed out (sky-high compensation and ESOP). Not a rant and
| to give you some background, one major reason we went with
| SvelteKit was not to rely on the Next team. And now, I am again
| with them...
|
| Now we have a monopoly of rare, modern SSR frameworks.
| 6gvONxR4sf7o wrote:
| This is all that's wrong with open source free software. You're
| disappointed by _how_ someone chooses to give you free stuff.
| exhaze wrote:
| Svelte and Vue got started when someone just went and did it.
| If you think it's so important to have many competitors in this
| space, just go and do it :)
| waterglassFull wrote:
| Feel free to make your own alternative, the world's your
| oyster.
| swyx wrote:
| interesting that you think talking to a VC and starting a
| startup (where he would be spending >50% time on business
| things and be forced to come up with a monetization plan) is
| better for svelte than getting fulltime sponsorship to solely
| work on Svelte and working with the top tier talent at Vercel.
| tnolet wrote:
| Exactly. I think the OP does not know what it means to "raise
| money" and go at it. It would turn that person into a full
| time business owner.
| mdoms wrote:
| > I'm disappointed by Rich. Instead of thinking bigger, raising
| money (it would have been so easy, Rich, instead of doing proud
| conference talk after talk why didn't you talk to a VC??)--he
| just cashed out (sky-high compensation and ESOP). I lost all my
| respect. Not a rant to give you some background, one major
| reason we went with SvelteKit was not to rely on the Next team.
| And now, I am again with them.
|
| Who the hell do you think you are? You don't know his
| situation. You don't know anything. How do you know he doesn't
| have a gravely ill family member and needs a steady income more
| than he needs to "think big" about a fucking javascript
| framework? How do you know he's not deeply in debt from a past
| mistake? How do you know he doesn't find the tech obsession
| with "VC" funding repugnant? No one needs sxiao's judgment.
| dang wrote:
| Please don't respond to something bad by breaking the site
| guidelines yourself. It only makes things worse.
|
| https://news.ycombinator.com/newsguidelines.html
|
| Edit: your account has unfortunately been posting a lot of
| unsubstantive comments. Worse, we've had to ask you many
| times not to break the site guidelines. I don't want to ban
| you, so could you please review the rules and fix this?
|
| https://news.ycombinator.com/item?id=27867817 (July 2021)
|
| https://news.ycombinator.com/item?id=27610150 (June 2021)
|
| https://news.ycombinator.com/item?id=26683075 (April 2021)
|
| https://news.ycombinator.com/item?id=25453716 (Dec 2020)
|
| https://news.ycombinator.com/item?id=24445333 (Sept 2020)
|
| https://news.ycombinator.com/item?id=24413377 (Sept 2020)
|
| https://news.ycombinator.com/item?id=23388036 (June 2020)
|
| We're really trying for a different sort of internet forum
| here, and we need everyone to pull in the same direction to
| have a chance of that working in the long run. The default is
| deterioration, followed by scorched earth, followed by heat
| death. We're trying to stave that off here, at least for a
| while longer: https://hn.algolia.com/?dateRange=all&page=0&pr
| efix=false&so....
| rglover wrote:
| I built this to avoid this exact problem:
| https://github.com/cheatcode/joystick.
|
| No desire to be acquired (open to investment but that's it),
| just build a business around accompanying features/services.
|
| Goal is fast, simple, and friendly regardless of your skillset.
| No lock-in as the entire thing is a thin abstraction over
| Node.js/Express.js and components are built using plain HTML,
| CSS, and JS (no special languages or syntax). Also adding in a
| lot of helper stuff so you're not stuck cobbling together
| random packages for common stuff (i18n, form validation, etc).
|
| Feel free to email me if you or your team have questions:
| ryan.glover@cheatcode.co.
| rich_harris wrote:
| I understand this perspective! But as anyone who knows me will
| tell you, I would be the worst person in the world to try and
| build a business around Svelte. As others have said, the
| expectations from investors would make it far less likely that
| Svelte could remain a community-centric project.
|
| It's important to clarify that Vercel (which has earned its
| open source bona fides) hasn't 'bought' Svelte or SvelteKit.
| It's more accurate to say that they're supporting Svelte's
| development by paying for a full time engineer to work on it.
| There's a healthy core team of developers who certainly won't
| relinquish _their_ independence because of _my_ career choices.
|
| It's fair to be sceptical about all this! But I've had multiple
| conversations throughout this process where the importance of
| maintaining independence was expressed by both sides, and I
| truly believe this is the best outcome for Svelte and its
| community.
| sxiao wrote:
| Rich, I know where you come from, and I wholeheartedly
| believe what you say. But this is just the start of a
| relationship between you and Vercel. And you know that
| relationships will change over time and so on. And you
| won't.be.independent. There is just too much money on the
| table. Nobody will give you orders, there are much smarter
| ways.
|
| The point is, Vercel did everything right, no blame to them,
| great CEO, awesome Tim, they are masterminds and their great
| social media army does their best to celebrate this event in
| all social networks atm. But you know yourself very well that
| one player just left the market. We will face less
| competition and possibly stagnation in some areas. This
| doesn't hurt Vercel nor you but us.
|
| Ofc you will be dependent, they pay you, you want Vercel to
| be successful (ESOP). We will see, e.g. that Vercel will be a
| first-class citizen as deployment option. There are many more
| fields where Vercel can/will get a special treatment, so
| subtly that nobody will get it. Business is more
| sophisticated than many might think.
|
| Or think this the way around, there endless possibilities to
| drive somebody down, demotivate and degenerate him to a point
| where he looses all his drive and motivation. Look at
| yourself today, look how much energy and charisma you have
| when holding speeches about Svelte. In 2 years, go back to
| this comment and ask yourself if you are the same energetic
| Rich, if you are happy and if sold out too early 2 year ago.
|
| > I would be the worst person in the world to try and build a
| business around Svelte.
|
| No you just underestimate yourself. What are you doing right
| now? Giving talks, writing, communicating. People, masses
| follow you not just because Svelte is great, no because you
| can communicate well and know how to lead people. This is
| what a CEO is doing 99% of his day. This is building a
| business, communicating, finding and winning the best people.
|
| You found already the best people, just look in your repos
| and look which contributors work for Svelte! And you were the
| leader, had an as good team as Vercel and follow now...
|
| And if I watch you talking there is a strong desire to be
| more (not that a dev is less!). Whatever, I'd have expected
| that you at least went shopping with Vercel's offer to
| CloudFlare. I mean they do real rocket science (Durable
| Objects) and you opt for Next which started to renovate their
| stack (esm, swc) just recently after years.
|
| Oh man, I like you too much to be too angry but yeah, not
| happy.
| sanitycheck wrote:
| Congrats on the job, Rich! I've been using Svelte, Typescript
| & Babel in the past couple of months to build a set of TV
| apps targeting some fairly slow and ancient devices and it's
| been brilliant. Totally impossible to do that with React, I
| do know some people who tried it though.
| mixmastamyk wrote:
| The framework appears to have an MIT license and lots of
| contributors so I wouldn't worry too much.
| afavour wrote:
| > Instead of thinking bigger, raising money (it would have been
| so easy, Rich, instead of doing proud conference talk after
| talk why didn't you talk to a VC??)
|
| In no world would taking VC funding have been easier. They'd
| want cash returns and hockey stick growth, and soon. So instead
| of focusing on making the framework as good as it could be,
| Rich's attention would be diverted.
|
| When SvelteKit becomes a framework impossible to run on
| anything that isn't a Vercel platform, then maybe I'll be
| outraged. Until then, subjecting an incredibly talented
| developer to the day-to-day whims of VCs seems like just about
| the worst outcome for everyone.
|
| I don't normally mean to sound uncharitable but your original
| comment is pretty uncharitable to Rich, so: if you want a
| stable platform that will live for many years to come, the
| absolute last thing you want is for it to take VC investment.
| That you don't see this speaks volumes to your understanding of
| how any of this works.
| sxiao wrote:
| > In no world would taking VC funding have been easier.
|
| Did I say that? Or that Rich should have taken the easier
| path? No, everyone should always take the harder path. But
| this is a deeper discussion.
|
| > I don't normally mean to sound uncharitable but your
| original comment is pretty uncharitable to Rich,
|
| But your tone towards me is better?
|
| > That you don't see this speaks volumes to your
| understanding of how any of this works.
|
| If you think so, fine, but I'm pretty sure that I've raised
| more money and more rounds than you but this shouldn't
| qualify me to be right or wrong. I focus on what you write
| and what I've written and I think I brought good arguments
| that a market turned into a monopoly and this is not great.
| Can we blame Rich, probably not. Can be disappointed and
| still respecting him? Yes.
| dang wrote:
| We're all lucky that you got a polite, substantive reply, but
| please don't cross into personal attack like this in HN
| comments. It generally causes discussion quality to tank
| drastically.
|
| https://news.ycombinator.com/newsguidelines.html
| sxiao wrote:
| @dang, second reply and apologies, now I know what you mean,
| I edited some part away which you probably meant and which is
| still in quotes of others' comments. Sorry, I'll try to
| improve and thanks for the hint!
| sxiao wrote:
| Can't follow you, what do you mean/where did I cross into
| personal attacks? I highly appreciate Rich but the elephant
| in the room had to be addressed, especially on HN.
|
| I wonder that I am the only one that questions his move and
| that you also approach me instead of welcoming a healthy
| debate. Whatever, I guess you just do your job.
|
| Btw, when does HN get proper pagination and a darkmode?
|
| Do I get shadowbanned now for asking too many questions?
| dang wrote:
| This is the part I meant:
|
| > _I 'm disappointed by Rich. Instead of thinking bigger,
| raising money (it would have been so easy, Rich, instead of
| doing proud conference talk after talk why didn't you talk
| to a VC??)--he just cashed out_
|
| That includes a lot of assumptions and is unduly personal.
| I realize you're coming from a place of being a fan, but
| still, there's an ordinary human being on the receiving end
| of such comments.
|
| Of course I'm not banning you, just trying to persuade you
| to post more in the spirit of the site! But please stop
| taking the thread further in this off-topic and personal
| direction - https://news.ycombinator.com/item?id=29192231
| and https://news.ycombinator.com/item?id=29191992 are
| definitely not helping.
| DonHopkins wrote:
| Rich Harris Coined the Term "FauxSS": Fake OSS!
|
| Svelte Summit Spring 2021: Rich Harris @6:07:00 (link with
| timecode):
|
| https://www.youtube.com/watch?v=fnr9XWvjJHw&t=22020s
|
| >You know, I guess all I can say is that we're thinking about
| this stuff too, and, like, we want the development velocity to be
| as fast as possible. But we also don't want Svelte to become like
| some, I don't know, some VC-funded FauxSS -- did I just coin
| that: FauxSS? I like that!
|
| >It feels like there's more and more of that these days. There's
| a lot of people working on open source software, and then, like,
| you discover that there's a business model behind it.
|
| >And I'm always a little bit skeptical about whether or not that
| is in the best interests of the software itself. And I don't want
| Svelte to become a thing that is run in the interests of the
| people building it, I want it to be a thing that is run in the
| interests of the community at large.
|
| So what is the opposite of FauxSS? ProSS?
|
| Hmm: "pross: a person who engages in sexual activity for money."
|
| So I guess that means OSS is as great as sexual activity. ;)
| PaulBGD_ wrote:
| I'm sure he'll see this soon, so congrats Rich! Svelte has been a
| cool project since the beginning, and I'm excited to see Rich
| have more time to work on this. As an early contributor I've seen
| Svelte go through a lot of maturing and it's exciting to see it
| finally getting the recognition it deserves lately.
| gherkinnn wrote:
| Interesting. Vercel already hired both the main Webpack and SWC
| devs.
| throwawayjklalf wrote:
| svelte + deno should be the perfect combination for the next age
| of web development.
| ergo14 wrote:
| I think stencil or Lit are more interesting. I'm not sure I'm
| the fan of small libs like Lit or preact - I think for
| scenarios where you have more than 2-3 elements you will have
| less bytes over the wire very quickly.
| stevenpetryk wrote:
| Vercel's increasing control over the frontend ecosystem worries
| me a lot.
___________________________________________________________________
(page generated 2021-11-11 23:00 UTC)