It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript.
For example, a framework Foo does not have the concept 'else' at all in HTML template. Another framework Bar has an 'else' like <div bar:else="expr" />, but the scope of else is totally different from another framework Baz or JavaScript itself.
JSX on the other hand, is straightforward -- when you open a curly bracket, it's just JavaScript expressions -- map, condition, lexical closure, everything works out of the box.
This is the most ridiculous thing I hear when people compare frameworks.
I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either.
Also, my dude, there's like half a dozen rules when it comes to vue templates. Jsx has lots of small rules about component names and things like class vs classname as well.
As for putting javascript expressions in your templates... Each to his own I guess, because imo it's a pretty bad anti-pattern to put an extensive amount of procedural code in the template code. Again with vue, using things like computed properties in single file components (SFC) makes it very easy to read and maintain code.
You mean, wildly inconsistent templates: https://news.ycombinator.com/item?id=19199423 and magically bound JS https://news.ycombinator.com/item?id=17471199 (see code and comments at the end)
Take the following for example:
v-on:click="counter += 1"
v-on:click="greet"
v-on:click="say('what')"
And yea, it's more complicated than "everything in the brackets is javascript and you already know javascript so it's all super simple". If this is where the bottleneck is for you then, fine.
All I can say for myself is that I find vue's templating easy enough that it's a non issue.
The fact that it is restrictive because it's a DSL is a plus for me because it avoids some really ugly code that I've seen in some react projects where the programmer puts a tonne of js code into the templates which as I mentioned before I find an anti-pattern.
As for the magic... yea vue is more magicky, which is why I like it. It's a framework, it's supposed to magic away the stupid boilerplate code. In some ways this is going to be relative because there are people out there that think frameworks like react are too magic and require too much tool-specific knowledge when vanilla js can get the job done. And people that make this argument are technically right in the same way you're technically right that vue is more complicated than react.
That's what inconsistency means. It has multiple v-* attributes and each has different rules on what it accepts.
> ugly code that I've seen in some react projects where the programmer puts a tonne of js code into the templates which as I mentioned before I find an anti-pattern.
JSX isn't templates ;)
> It's a framework, it's supposed to magic away the stupid boilerplate code.
I don't mind magicking away the boilerplate code. I do mind when it's once again so inconsistent in how it magics away that code. For example, in my second link multiple nested properties become properties of `this`, and then:
// `this.isFolder` magically hoisted into `this` from
// `object.computed.isFolder`
//
// this.open can be set directly. Magic.
// Even though `this.open` magically hoisted
// into `this` from `object.data` which is a function that
// returns an object whose keys and values are hoisted
// into `this`
//
// this.model.children cannot be set directly. Not magic
1 - things defined in data, computed, methods, and props can be accessed on the component directly as a shortcut. This is in the fairly short documentation and everywhere in the code examples. It's not inconsistent if you don't know the rule. It's like complaining that variable names in some languages can start with _ or other special characters but can't start with '1' or start with '2', or start with '3'...
2- and this.model.children definitely can be set directly, and it will be reactive. Unless you're passing an object literal without binding it or if it's not a data object, although I am not 100% sure on this since all my props are usually made reactive by vue and so they are bound. But I know for sure that code like this should work for sure because I've done it.
3 - I don't think that's the correct use of hoisted.
I feel like maybe you'd like vue a lot more if you gave it a chance and went through the documentation (which is pretty good, short and simple). I don't disagree that it has a little bit of magic, but it probably looks worse than it really is if you don't know the rules. Once you know a handful of rules, things are fairly easy to reason about. IMO, easier than angular, and sort of easier than react because there's less code.
For class part I'm sure it's just whatabouism...
And for expressions it's not praiseworthy to put in the template, but my point is why not reusing JavaScript semantics rather than implementing you own that differs from JavaScript?
It definitely beats working with JS for me.
How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to the react lib where they can do whatever they want? I'm genuinely confused.
I don't care one way or the other - I'm not a web dev. It seems from this comment that you're just scared of compilers, which is strange. No matter what you're relying on third party libs in your code. Why is it somehow safer for that third party code to be used at run time rather than compile time? I would probably argue the opposite. Why the strong aversion to compilers?
Are you saying the original source code hides complexity that is present in the generated code? If so, I guess that's the whole point, but then a runtime framework also hides lots of complexity that your code doesn't have to manage (which, again, is the entire point of using a framework).
> It's much harder to debug code that doesn't resemble what you wrote in the first place.
With a runtime framework, there's lots of code running that isn't your code, which can also make debugging difficult. With Svelte, at least the generated code is fairly straightforward and easy to step through. In many case, I think it's actually easier, not harder to debug.
Svelte compiles, React runs at runtime, that's true.
I've spent the last week (and weekend) doing the UI for a new project in Svelte. The compiler approach is pretty rad as it seems to catch more errors before I test them in browser.
You can download any project from the https://svelte.dev/ tutorial / online REPL and it'll have a rollup file, watching files, compiling them and telling about broken code.
vscode also has a plugin for Svelte components that shows pretty underlines while you work. The compiler approach means I see more warnings faster and save time.
I'll add another one - the code that comes out is the code that goes in. Remember the days of Coffeescript and minimization before sourcemaps?
When most of your work comes from maintaining a codebase being able to effectively debug your code is crucial and hitting an error in production that is only painfully traced back to development will quickly offset any advantage that framework gives you.
I would add that "debugger" is not mostly a tool for finding and fixing bugs. It is tool for code-understanding, giving you a "live view" of your code, for READING your (or someone else's) code in the order it executes.
Absolutely! I couldn't agree more.
From the discussion about forking sub-processes from the shell:
The compiler/assembler/disassembler/debugger should be built into the shell, just like ITS DDT at the MIT-AI Lab in 1969! ;)
https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...
https://dspace.mit.edu/handle/1721.1/6153
https://github.com/PDP-10/its/blob/master/doc/info/ddt.33
https://github.com/PDP-10/its/blob/master/doc/_info_/ddtord....
It is, and works pretty much out of the box nowadays
Others are looking for options that might minimize overall script / JS size (which is a hallmark of Jason Miller, author of both Preact and HTM).
Another might be to make this easier for beginners. For example, the React docs link to an example HTML page that uses the `babel-standalone` build [0] as a way to try out JSX syntax. However, that's a hefty piece of JS, and it's not at all advisable for real use. HTM might be a good alternative to that.
[0] https://reactjs.org/docs/add-react-to-a-website.html#quickly...
If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them.
In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.
Ughh.. that's the point of all modern FE frameworks...
You are putting that description on a pedestal as if that is a unique property of React.
A component is almost a function returns element. Expanding a component is like calling a function and give it the property.
So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`.
A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style in the decorator... They are not something we consider most abstract at all.
The function is the simplest yet composable abstraction over the template, Cheng Lou also has a really excellent talk on the topic: https://www.youtube.com/watch?v=mVVNJKv9esE&t=1470s
https://news.ycombinator.com/item?id=8860722
The Great Quux's Lisp Microprocessor is the big one on the left of the second image, and you can see his name "(C) 1978 GUY L STEELE JR" if you zoom in:
http://ai.eecs.umich.edu/people/conway/VLSI/InstGuide/MIT78c...
Design of a LISP-based microprocessor
A function that returns a component has no more reusability than a component class' identifier. That component itself has a very narrow use case of it being a UI component.
Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?
In effect, JavaScript logic tends to be procedural/imperative, while templates allow declarative semantics, and styles are nearly a 2.5D constraint language. "Separation of concerns" here means only having to think in a particular mode, rather than blending all of those modes of thought into a single eyespan.
Notably, Vue allows for single-file components, while preserving the familiar and intentionally designed separation of declarative (HTML), imperative (JavaScript), and aesthetic (CSS) code.
Bad PHP pages mixes all kinds of shit together. This leads to the thought that to do it 'good' everything needs to be seperated.
It's a wrong thought but I see how people got there.
I don't know why people keep believing that separating templates and js is a good thig. Pete Hunt addressed this in the React into videos he did -
you want 'separation of concerns', not 'separation of technologies'.
React does the former. Vue/any other templating engine does the latter.
You get a very React-like experience with components and functional templates in JS, but it's all standard JS, and there's no framework, just standard web components. The lock-in and risk is very low for enterprises.
The more that I depart from my "bare metal" web tooling the riskier/dumber things get. I always want to see a path back to a basic HTML5 shell, driven by almost-pure JS (w/tiny helper libs), and basic CSS. Just like basic UNIX tooling - basic web tooling just works!
To those thinking about trying lit-html; it IS as simple as the example on the GitHub project page. I was able to build it into a semi-complex application within a couple of hours and it had massive performance payoff w/o compromising how I want to build things. It definitely gets my "KISS" approval stamp.
I am very curious about this kind of decision. I realize you may not be able to share details, but whatever you can share would certainly be interesting.
If your company has issues with React being developed by Facebook, that's an entirely different question.
Anyway, my point is you might want to check if it is okay to use any FE framework at all. It seems like a very strange policy to say "you can use any FE framework except React".
But if you are going to do this use Vue.
1. Changes to the DOM cost a ton more than executing JS code.
2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.
The point of the article, and of the performance problems that people actually have with React is that this might be true for a small number of JS operations, but that
1) Tree diffs are computationally complex operations that add up for real-sized apps 2) The diff is actually unnecessary if you simply take into account the structure of templates, so diffs are pure overhead.
So _do_ feel bad when you have a no-op render() in React at least, because the resulting VDOM diff just chewed up CPU and battery for no reason.
I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.
Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library, all things considered. The only compilation step necessary is JSX to Javascript. JSX maps pretty directly to React's API. This means compilation is pretty simple. So much so that you can do it by hand really easily if you really wanted to. Svelte, on the other hand, is pretty compilation-heavy. There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. But if you are comfortable with that trade-off, that's perfectly fine. It is worth being aware of it, though.