First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented.
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.
It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them.
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.
Anything with a DSL is evil. That's why I never liked Vue and don't understand its huge popularity - you get none of the functional benefits of React, you might get a minor speed increase, and you DO get to write code the old style with custom DSL and no clear components.
Don't forget to mention the poor (and complicated) editor support for "these custom HTML templating languages". JSX is very well supported in most editors.
> It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte)
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.
Even without knowing vue, all of those examples are very straightforward in what they're doing. Just because the click event can take multiple options doesn't mean that it's inconsistent.
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.
> Just because the click event can take multiple options doesn't mean that it's inconsistent.
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.
I love Vue and I vastly prefer it instead of React (have even been using Nuxt lately, now that is some real magic) but that comment makes really good points about Vue!
JSX is clearly a second class citizen in Vue. Last time I tried, using TypesScript with Vue made JSX unavailable. And it was not documented, so the process was try, fail, look around, find the Github issue about this.
You can't expect most code bases use JSX as template. It's not even praiseworthy if the framework provide every possible choices. Just like you can do anything in C++, but in practice it's a terrible language to work with.
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?
> 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...
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?
I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.
> However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime.
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, on the other hand, is pretty compilation-heavy. Personally, I'm less comfortable with that compared to React's runtime library approach.
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 know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?
>Just curious what the use case for not doing compilation is?
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 think this is the the big reason to prefer plain old JavaScript. Compilation is ok in Java etc. where you can still debug your Java-code. But with many of these JavaScript frameworks I don't think that is possible, is it?
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.
>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! ;)
Some folks simply don't want to use a build system, whether it be for experimentation or not wanting to deal with the overhead of tooling.
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.
I think you have answered your own question: it's one less thing to worry about in your stack.
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.
React is more like 'Lambda the Ultimate Web Component'.
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 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:
Also according to Wikipedia[0] Brendan Eich was supposed to create 'Scheme in browser' but in the end it became scheme with Java syntax. I always wonder if it was real 'scheme in browser' the web would advanced faster, at least S-expression is good at expression HTML. Therefore we wouldn't have to wait JSX until 20 years later...
whether getting a component via a function call, vs an named export identifier (component class) - They have essentially the same net benefit over time.
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.
Functional programming folks love React- Pretty much every clojure web framework is built on React. But yes, with some effort you can come up with a definition for "functional" which React will fail to meet.
I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as well. We have a webpack installation that pulls in the Vue files and bundles everything and it is quite clean.
I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.
The "separate files" argument is a red herring. It is really about separate "mindsets" or "modes of thinking".
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.
In vue (or atleast the way the majority of people use vue), each component is separated into a .vue file. That component's template, style and business logic is all encapsulated in that one file. A basic .vue file starts out with <template></template><style></style><script></script>. It keeps everything nice and simple, in my opinion. Each different "mode of thinking" is separated out, but still all together in one file.
Check out web components with LitElement and lit-html.
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.
Went down this rabbit hole yesterday and played with LitElement/lit-html for the first time... great experience for folks who don't want much "ceremony". Was also SUPER impressed with AppRun.
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.
They allow you to use anything you want, as long as it's not React?
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.
Well, the _license_ certainly shouldn't be an issue at this point. It was changed to a standard MIT license a couple years ago, same as all the other major JS frameworks.
If your company has issues with React being developed by Facebook, that's an entirely different question.
There was a license controversy a couple of years back, yes, but that was solved rather quickly - I understand that you as an intern don’t necessarily have any sway over legal, but they’re not up to date.
Vanilla JS with a good understanding of MVC serves quite nicely in most cases. I wrote a few introductory programs to clarify it (https://github.com/madhadron/mvc_for_the_web).
Why don't they allow react? One reason I can think of is they have a server side side rendered architecture and they want people to continue to use that. They don't want new devs to use company time to buff their resume with unmaintainable learning front end code. At least that's why I generally shoot down attempts at using FE js frameworks over here. We have some really awful react 0.11 pages that are years old that will take weeks to redo properly.
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".
Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.
> 1. Changes to the DOM cost a ton more than executing JS code.
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.
> 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.
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.