51–60 of 236 posts
A side note about that website. Thin and Extra-Thin fonts have no place in web design (there are some exceptions in huge title text). They are an unnecessary burden for people with limited eyesight and elderly people[1]. Even for me, on my 1366x768 screen (which is still the single most common resolution for cheap notebooks, dear HiDPI web designers[2]), the bullet text is hardly readable, the copyright line is compl…
Earlier quoted context omitted.
"the reason boilerplate bothers me so much is that it impacts the readability of my code" But if you hide boilerplate you not really improve readability. Not seeing what is really happening just creates the illusion of readability.
Taken to its extreme, that argues for writing everything in assembly language. React's virtual DOM diffing makes components more readable than the previous style of writing code to explicitly manipulate the DOM and totally hides what's really happening. However, we trust that it's going to do the right thing, just as we trust that the JavaScript engine will do the right thing when it JITs and interprets our code.
It's not that people said "Everything is bad, do assembly". It's just that people identified 2WB as problematic and you just shouldn't do that one thing.
This looks nice: a Javascript framework for expressing _concepts_ that compiles down to vanilla JS. It looks like it ships a lot less code to the user. From the project's first [blog post]( https://svelte.technology/blog/frameworks-without-the-framew... ): > The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, React plus ReactDOM without any app code weighs about 45kb zipped. It takes about 10x a…
I didn't study the thing, but the first question that comes to my mind is: if each component is rendered as a self contained piece of vanilla js, isn't the size of an app with lots of components going to increase much faster than with the library approach? A complete library by itself can be pretty big, but it stays the same size no matter how many components you add.
I tried peeking at the EachBlock example and it came out at 7.5kb uncompressed. Copying and pasting the loop a few times makes that grow fairly quickly. Four copies of that example code is enough to make it grow over 22kb. For comparison, the render method in Mithril.js is about 21kb uncompressed. I imagine you would only need another 20 or 30 times more code to reach the size of React (~140kb).
https://www.reddit.com/r/javascript/comments/5fcwhz/svelte_t...
I love the ideas. The only other thing I like is CSS scoping, though. I think that CSS scoping is a problem in React, and current ideas on how to implement that in React are absolutely horrible IMHO. Two-way binding is a step back I think, I don't love the name (lots of people will judge a new technology by its name), and the thought of introducing yet another framework is a nightmare. I'd personally go with Polymer…
What kind of logic are they using here? Isn't any javascript just vanilla JS?
A side note about that website. Thin and Extra-Thin fonts have no place in web design (there are some exceptions in huge title text). They are an unnecessary burden for people with limited eyesight and elderly people[1]. Even for me, on my 1366x768 screen (which is still the single most common resolution for cheap notebooks, dear HiDPI web designers[2]), the bullet text is hardly readable, the copyright line is compl…
Lots of elderly programmers might want to check out Svelte.
This looks nice: a Javascript framework for expressing _concepts_ that compiles down to vanilla JS. It looks like it ships a lot less code to the user. From the project's first [blog post]( https://svelte.technology/blog/frameworks-without-the-framew... ): > The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, React plus ReactDOM without any app code weighs about 45kb zipped. It takes about 10x a…
I didn't study the thing, but the first question that comes to my mind is: if each component is rendered as a self contained piece of vanilla js, isn't the size of an app with lots of components going to increase much faster than with the library approach? A complete library by itself can be pretty big, but it stays the same size no matter how many components you add.
The equivalent JSX output for that clock demo is about 1KB. So yes, I would guess that apps with many components would end up bigger (in total JS bundle size) than equivalent React apps.
Possible counterarguments:
- Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc.
- Once downloaded, the Svelte approach would probably be faster than React (at both rendering and updating) and would use less memory (no virtual DOM, no diffing, just fast granular updates).
- The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the-fold or other pages in the background. This could work well with HTTP/2.
> It's basically as fast as vanilla JS, which makes sense because it is vanilla JS – just vanilla JS that you didn't have to write. What kind of logic are they using here? Isn't any javascript just vanilla JS?
It's a very slight but interesting distinction.
So this is like GWT, minus Java? GWT's treeshaker removes dead code and outputs fat-free plain JS.
I love the ideas. The only other thing I like is CSS scoping, though. I think that CSS scoping is a problem in React, and current ideas on how to implement that in React are absolutely horrible IMHO. Two-way binding is a step back I think, I don't love the name (lots of people will judge a new technology by its name), and the thought of introducing yet another framework is a nightmare. I'd personally go with Polymer…
From looking at the docs, the two-way binding seems entirely optional and I can't find anything that would prevent a developer from using a redux model of state management.
I've got framework fatigue, too, but on the surface this project seems to embody the best of what I love: a tiny API, little magic, and getting out of the way.