React and Redux are a joke right?(games.greggman.com) |
React and Redux are a joke right?(games.greggman.com) |
i get a feeling author had no prior experience with js ui whatsoever.
> If you imagine a component tree as a waterfall of props, each component’s state is like an additional water source that joins it at an arbitrary point but also flows down.
In this post’s example, I would expect to see a component for an individual Person with the props name and location, then a People component storing the ordered list in props. If the app does a lot of this general “maintain a sorted list with random insertions from over the net”, People would be wrapped by a higher-order component (https://facebook.github.io/react/docs/higher-order-component...) managing that. Otherwise there’d probably be a page-level custom component or just random stateful javascript pulling in the data and passing it down to People for rerendering. (I don’t know Redux to address the second half of his example.)
It’s ironic that the author advocates for immediate mode GUIs, because normal React looks and works like an immediate mode GUI with memoization. A component is a function responsible for part of the page. Its props are the input to the function and it returns a render of part of the page (possibly by rendering more memoized components). The cache is busted when props changes. There’s also a hack to be used sparingly called state so that small bits of UI state can be managed at a low-level instead of in their parent component.
There are several things about React, Redux and React based tech stacks:
1. React requires knowledge of basics of functional programming
React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. Without this knowledge, a lot of things will be a struggle and won't make any sense. You'll mess up pretty bad. React requires the understanding of its principles which require the understanding of FP essentials.
2. React is not a framework and does only one thing well
It does only one thing well, turning your UI into a function of data. Yes, there is a virtual DOM but it's an implementation detail and not the purpose of React. If you think about it everything which is there is needed to make that UI=F(data) possible. However, it's enough for simple apps.
Immutability isn't always needed so it's optional. It's not built into JS, you'll have to use an additional library.
3. Building non-trivial apps requires a lot of knowledge and experience
Building non-trivial apps with React only is a pain. That's expected because the only thing it does is making a UI a function of data. It's not a framework with a complete set of tools and practices for building a whole SPA. That means you have to assemble your own tech stack for your particular task. This requires a lot of experience but lets you have the tools which are a better fit for your app.
Redux is just one of the available choices for solving the problem of complex app's architecture. It isolates state from React components. UI interaction with the outer world is behind actions. Data access is behind selectors. State mutations are centralized in reducers. This is very convenient, you always know where to look for something. Business logic part is very clear because of actions and reducers. Not messing everything up requires knowledge and discipline though.
The funny thing is React+Redux isn't a complete framework. For case, there are several solutions for writing asynchronous actions.
The main idea is React is ok to use by itself for simple things. You don't need to know much except FP essentials. Using more advanced React based tech stacks requires much more knowledge and experience.
If you don't know which of your problems React solves you don't need it.
If you don't know which of your problems immutability solves you don't need it.
If you don't know which of your problems Redux solves you don't need it.
I find the highlighted article on Facebook's "reason" for inventing Flux/Redux very laughable. - This message unread indicator kept saying (1). And how it went away with bug fixes and came back...
Did they ever stop to realize they just had some really bad devs working on the chat app? Any re-write, whether they had to invent flux or not would have fixed that indicator. It's a false story.
I don't like Redux that much. All React based frameworks I like are not even written in JavaScript.
You should check immutable-js.
Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library?
>If you get 3 people react will end up re-rendering 3 times because of the code above.
Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault?
>So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays.
I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a tree and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for.
>Why is the UI library dictating how we store and manipulate our data!!!
It does not do this, it's a virtual DOM/diffing library (!!!).
>Maybe someone needs to start the browser over.
This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least.
Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?
In Angular-land you can just mutate some JS objects and the UI magically updates. I really miss that.
I picked React over Angular2 because the setup was simpler and I wanted to try out this new thing that everyone has been raving about. I have a lot of misgivings about the choice. There are some things I like about React, but I probably will not choose it for my next SPA. There's just too much typing.
To reiterate what other people have said. This it not a problem of React, this is a problem of people blindly jumping on the Redux hype train, without doing the required reading into Redux and its use case.
It makes me sad to see people ranting about how much typing there is in Redux or Typescript or how much boilerplate and so forth. To me this behaviour screams immaturity, because I don't know how else to explain spending energy on wining instead of finding a solution. Especially, that you don't need to look far - take redux-actions for example. Nice and simple, makes all the heavy lifting for you. If that's not cool in your view how about you actually contribute and write something of your own, rather than moan?
Well, that's kind of his point isn't it? It's no more difficult to update a deeply nested regular Javascript object. But it is more difficult to update a deeply nested Redux data store.
> Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?
I'd argue that Redux is not just "not a silver bullet", it's an arrow head shoved into the barrel of a gun. You might kill something with it, doesn't make it any good.
I agree completely with the rest of your points though.
I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework war, purely based on opinions.
My opinion is pretty simple and resonates with a lot of people, apparently[1]:
~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we’re writing code like this: [1]
[1] https://twitter.com/thomasfuchs/status/810885087214637057?la...
My problem with it is that there is so much abstraction that almost no prior knowledge from using other frameworks or libraries is useful. It seems like everything is magic.
Here is a chain of react tech things: React->Flux->Redux->Redux-Persist->PersistGate
The latter is talked about in documentation, i.e., "do it like PersistGate does", but I can't find PersistGate anywhere.
With so many react extensions and libraries all having their own helper functions to do everything it seems like we are no longer programming, but instead, we are tasked with stringing together configuration functions after searching for hours for the currently relevant documentation.
I think react does some pretty amazing things, but the learning curve is too steep because of fragmented documentation (mostly the community created how-tos are the problem here), confusing abstractions, and poor method naming (thinking about redux's `reducer` here).
Anyway, I, and several programmers at my company, share your sentiments; you are not alone. This will probably be my last greenfield react project.
You would use plain old data objects to store everything. Then you would have first class observers, meaning you could have callbacks react to any changes to any object. But you wouldn't use that low-level functionality often. Instead you would e.g. create a listview, and just set it to observe the array. This is like "list adapters" that are in many frameworks, but built into the language.
One thing that I'd love to be able to do is to have the data as plain-old-objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion (and occasionally sends mutating messages to the backend thread). You could implement that with read-write locks, but as far as I know no framework supports it directly.
Maybe this language would have a special block that takes imperative, mutating code, and lifts it to implement the command pattern [2]. You then could "undo" these blocks, coalesce them, and so on. (That doesn't work with arbitrary code, but with most code that operates on business data.)
(Here are some questions I asked on StackExchange, trying to find out if something like that already exists:)
[1]: https://softwareengineering.stackexchange.com/questions/2298... [2]: https://softwareengineering.stackexchange.com/questions/3515...
> In the react world though you can’t mutate your data
Sure you can.
> If you get 3 people react will end up re-rendering 3 times because of the code above. Each call to `setState` triggers a re-render.
Nope, calls to setState are batched.
I don't want to be mean about it, but there's a lot of literature on functional programming and how mutable data complicates things as your states increase. The problem isn't how React forces you to write long code to get around immutability, the problem is the fact that you're trying to force your approach.
And no, this isn't because React is heavily opinionated -- it's because React's underlying philosophy is functional programming.
But this actually makes several good points on accidental complexity imposed by React/Redux.
I know why they impose it, but there must (should) be a better way.
It's not without its complexities, however. Mainly:
1. using JSX, instead of a more transparent templating language, means people with less technical knowledge (i.e. product designers) have a higher barrier to entry when trying to make simple UI changes (I'm looking at you, `className`).
2. it is unclear at times whether a component should have its properties passed in directly from state through `mapStateToProps`, or from a parent component through `props`.
3. there does seem to be an tiring amount of boilerplate when adding a new piece of interaction to a component (an action, an action type, a reducer case, and usually a piece of state all need to be added).
4. to a newcomer, the benefits of immutable.js are apparent, but the benefits of a memoizing layer like reselect.js were less obvious. When you're still trying to wrap your head around How To Write React Things™, it's not apparent that you'd even need memoization ("isn't React supposed to be good at diffing stuff?" you ask yourself after watching large pieces of your app redraw itself over and over).
I'm curious to hear how people deal with these particular issues. React was one of the more useful tools I learned about this year, and I'd love to see the process for newcomers to React become less frustrating.
Edit: formatting
However, there is a better way ... lein new figwheel my-app, clojurescript+reframe gives you all the benefits of redux with an order of magnitude less boilerplate (also hot reloading and immutability by default without no extra setup or ceremony)
Because imperative code and persistent, immutable data do not play nicely together.
With new API like Proxy [1], we should not be able to just modify data as needed, and any observers can be notified by handlers in the object get/set. This will lead to data being fully mutable.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Everything after the "but" and all.
The whole point of Redux is to separate actions and state manipulation. An argument that, "well I want to manipulate variables feely," is not an argument. Just don't use Redux. End of story.
The pattern doesn't come from React. There are many patterns in React that are just Monads by a different name. Redux isn't much different.
They'll either be too limited so that you cannot express the full featureset of html within their bindings without hacks or too convoluted to use and impossible to debug.
I'm sticking with Vue, it's not perfect but it was at least designed to play with js's strengths instead of abstracting them to shoehorn functional principles.
(Not that I want to try this, but I'm interested in how that would work).
Of course, as others have said, React and Redux is not a panacea - depending on what you want to achieve and on your personal preferences there might be better tools.
> projects down the road and saves you time later on.
It's popular argument but I don't think it's completely correct.
On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability.
Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none).
I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.
For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data.
So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component).
I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation.
So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help.
I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.
It was "best practice" back in the days for years and mostly just because it was best practice, but also because at that time it made juust that much more sense where web applications were more primitive and closer to a semantic HTML "document" with some interactivity sprinkled on top (remember when AJAX was bleeding edge jaw dropping? "LOOK THE PAGE DOES NOT EVEN REFRESH!").
It's just some theoretical ideal that never pays any dividends in the real world and is not appropriate for a sophisticated modern web application.
The separated HTML, JS and CSS of your sophisticated datetime picker element or auto-suggest fancy textbox are of no use or importance separately. They all need each other, they are all inter-dependent and if you force that separation on some ideological idealistic principle you create the spaghetti that any commercial web developer out in the front lines is well aware of.
You spend a good 60% of your time on "where is the HTML for this JS" ... "where is the JS for this HTML" ... "where is the CSS for this HTML".
I'm sure a lone programmer is going to come down here and reply about their snowflake project that "was done right".
I don't care. Frame the code and hang it on your wall.
Out there in the real world in teams of 10+ people with varying degrees of skill and care who join and leave over multiple years you can't have a snowflake project that is perfect in every regard. So if the eco-system doesn't give you strong suspension belts things will go south.
If you could easily and practically switch and mix and match custom HTML/JS/CSS for any given web application then that would be something.
We would need much tighter and stricter interfaces and so on for something like that to work.
We all know that's nowhere near the case. Any non-trivial commercial web application will inevitably have HTML/JS/CSS that are all heavily dependent on each other and as a result the separation of them doesn't provide much benefit, and creates a whole series of problems on top too.
That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar.
Such separation of HTML/JS/CSS was misconceived. It makes sense for web documents and simple forms, but not for web apps with rich widgets etc (which is what we're trying to do). Tons of problems stemmed from cargo cult adherence to that.
Everybody else, including those that add JS instructions (or ad-hoc "templating language" instructions inside HTML tags) are getting it wrong.
Even now with React, I still don't see much code re-use outside of libraries. When you want your code to be re-used... you exercise the discipline that a library author would. You add typings, you add documentation, you add tests, you create a Github page where people can provide info. Taking someone else's code is a commitment, so you at least want the reassurance of library-quality code.
Otherwise when you write a component, whether in the old school html/css/js split, or in React, you're unlikely to write the component in a way that optimizes for generality, and optimizing for generality, as opposed to the narrow business case in front of you, is often a lot harder.
I think React components perfectly follow the single responsibility principle. You have a single file that is responsible for one thing: mapping data to UI. Yeah, it has some crazy syntax but it's just sugar.
I tend to use separate stylesheets, but that file lives right next to the component file.
Instead of getting HTML fragments on your JS, you get JS fragments on your HTML? Whenever you need to programatically generate markup with conditionals and iteration over existing data structures, you end up having to mix a programming language with your markup. (The other option is of course to create an entire programming syntax on top of your markup language.)
BTW, I haven't actually used vue, so this post is by no means me saying that it doesn't have its merits or it's not a good framework.
Yesterday I spent probably 5-6 hours just trying to figure out how to navigate easily with react-navigation. There are probably over 100 questions on their issue list asking the same thing: How do you easily navigate between nested navigators? They all have the same setup: A StackNavigator that contains a TabNavigator that contains one or more StackNavigators. Nobody knows how to do it without redux and users that do use redux have other complaints. The react-navigation examples all show a `path:` property, but they don't just have a global service that you can use to navigate to all those paths. Instead (I think) you have to wrap all of your navigators and pass around the `navigation` property. When I tried following their example of passing down the navigation property, I just get errors.
I blame the people who tried to force their stupid functional programming ideology onto the whole framework.
(The trick that worked for me: Don't nest navigators directly within each other, instead wrap each one in a component class, get a ref to the wrapped navigator and then use that ref to handle navigation requests from a global navigation service that other components and services can use.)
So, my opinion of react-native has softened a bit this evening as I've gotten over my biggest hurdle yet. After trying Xamarin out and also comparing it with my previous Ionic/Cordova/PhoneGap experience...I'm glad to be back with react-native.
Also, Expo XDE has been a pleasure to work with - discovery of that tool is the reason I decided to re-investigate RN about 2 weeks ago. The first time I tried RN was like 6 months ago and I had spent a few days the first week just trying to get the environment working properly. This time everything just worked (and on multiple operating systems!)
Dojo-stores, observable-collections essentially, were like that. A Dojo-view was a monitor for this. A very simple, elegant model-view design.
I agree that we should embrace mutability. The JS-code most people write now has horrible performance characteristics since we do not take advantage of the benefits of mutating objects to manage state. Instead, in JS-world, we recreate and duplicate state all the time, spamming the heap. One library doing this is not too bad, but all libraries doing this is the main cause of slow web apps.
IMHO Rust manages to do this really well - the system of ownership and borrowing brings all the safety of immutability to mutable data. Check out the "Why Rust" video: http://intorust.com/
It's not really viable to use in place of JS yet (only via Emscripten, which results in a huge bundle) but the future looks bright for Rust.
I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less productive or effective by the end of the course - they're doing well if they have the barest skeleton of a CRUD app up, whereas the Rails apps were all fleshed out and far more engaging.
There's something rotten with the state of development these days - we're dealing with far more complexity and being less productive for what's usually the same result.
90% of websites have no need for Javascript. Of those that do 90% won't be needing any "take over the world" frameworks, just little sprinkles of Javascript or jQuery.
Not to mention most required uses of Javascript are interaction related. At least let me read the landing page without having me enable javascript instead of greeting me with a blank page.
The reality is that 99% of web applications are "open, check, close" experiences which benefit very little, if at all, from a front-end framework of any kind.
The remaining applications that people actually keep open for long periods of time where the DOM needs to update over long periods of time are the only places where this approach really provides a huge benefit. Things like a chat system or actual web based software that people would be expected to keep working on throughout their day. For those types of application, React is a good fit.
The biggest issue is people jumping on this "we need a front-end framework" train when...you really don't for most things.
I still advocate for "progressive enhancement" as a development philosophy but the javascript kids seem to have taken over the show and regard back-end code as there for nothing more than building an API.
For the vast majority of javascript use-cases Turbolinks/PJAX gives you most of the benefit of a client-side framework (which usually boils down to faster response times by avoiding full page loads with the advantage that you get to keep most of your logic in nice server-side languages with non-pathological ecosystems.
Also see http://intercoolerjs.org/ - which follows a similar philosophy.
If you are trying to put up a few web pages quickly, then the learning curve is steep and it's probably overkill.
However, for complex single page apps with complex data that involve a team, then the payoff is huge. Especially with TypeScript (or other). The reliability, testability and extensibility of our complex applications is amazing compared to our previous attempts over the years.
Clearly it is not ease of use nor cogency of the code one needs to write, nor even how well the developer can express their intent.
I sometimes suspect that all this churn and complexity in the latest frameworks is some kind of unintentional group-think that optimizes for job-security by making work much more difficult than it really needs to be.
Another aspect is enterprise grade websites, where jQuery just does not scale as well or will make your code end up in an unmaintainable state. "Get beginners going fast" is a nice feature, but sometimes its more favorable to have "scales for teams with >10 developers".
If you are making a simple website, blog or whatever, please do not use SPA but stick with the server-side frameworks we had for years.
It's clear from the post that the author didn't learn how setState works, he's not aware of either batching or the callback form, which neatly address most issues related to setState.
I didn't pay much attention to the second half of the article, because I avoid heavy use of Redux anyway. Ultimately the author shouldn't have even been looking into Redux before understanding how React works, so presumably he's been misinformed somewhere along the way.
I've been working with React for years now, over several large projects. I still feel like I'm not used to it, and I still hate it. That's not normal.
We need to either figure out how to do this shit with mutable data structures, or we need a new language that's immutable by default.
ImmutableJS blows chunks. Yeah it "saves" code until you start doing the data transformation dance trying to figure out when and where to convert between plain JS objects and Immutable ones. Then you end up with some real ugly shit that'll trip up every new hire you walk through it (we use a higher order component that converts a component's Immutable props to regular objects, which incidentally is another import that like 800 unrelated files depend on...)
God help you if you don't use well commented code or Hungarian notation to differentiate between Immutable objects and regular ones. We all know how long good commenting practices last without thorough code reviews, and we all know how long those last in fast-moving environments, which is where React is most useful.
I guess a typed language would solve that. No, Flow and Typescript don't count.
Plus due to the google closure compiler code can be minified with an aggression unknown to the typical js minifiers.
Add to that tree-shaking (removing unused code) and the long term size of your app is looking good.
I find clojurescript and specifically figwheel reduces language annoyanes and tooling problems. No more do i have to jump through hoops to get a project setup, or pick the latest and greatest build tool (grunt->gulp->webpack->jspm)
A lot of those things are in a way a fundamental side effect of lenient languages and dynamism.
Having said I think it's definitely nowhere near as bad.
I use Typescript and modern JS and types and the modules/import system does a lot to prevent those things.
Because in general I don't have any globals lurking around so for example the styling of a component is imported at the top in the same file so it's always nearby. So the symbols and variables that you see on the screen are more obvious in terms of where they come from.
Redux also while not perfect if you have a reasonable amount of discipline it doesn't get as bad as the old-school stuff.
They're teaching classes about web development and trying to react to the perceived market demands.
You're talking here about "if you're building X or Y, use ABC", but the class doesn't make that call, and they're trying to be attractive enough to students to choose them.
If I was a student, and was looking to "learn web development", and I search around for what I should learn to make myself attractive to employers... I'm very likely going to find unbounded recommendations for Angular, React and Node, almost without exception. Probably not even 'likely' - it really is what I see touted weekly in many groups that I'm a part of (user groups, online forums, etc).
The current situation for new folks trying to get in feels like a big echo chamber with bad recommendations reinforcing poor choices leading to more confused (and less productive) jr devs coming in to the field.
> with non-pathological ecosystems.
That's just like, your opinion, man.
fanfare, fireworks, etc
CLOJURESCRIPT!!
sorry I just get really excited when I can mention it ... I'll go now
We haven't been using immutability.js because of the back and forth overhead between regular JS and immutable objects. Instead we use mutation checking of the Redux store during development you can make sure nobody is stomping on it by accident.
That's one problem. The other is discipline. It's just way too easy to opt out of the type system. It shouldn't be a problem, but in the world of deadlines where every single front-end dev is intimately familiar with writing plain old Javascript, it is. All it takes is one manager that's a bit pushy, or one urgent production bug, and your codebase is on it's way to turning into a pile of shit.
I do love type systems, but IMO they have to be part of the language, it just doesn't work as an optional addon.
arr[3] = 'New content';
arr = arr.map((element, index) => {
if (index === 3) return 'New content';
return element;
});
When I think of immutable primitives, I think of Python's tuples, which will raise a big fat error when you try to mutate them, or even better, Swift's structs, which gives you a new copy with every mutation.
arr = arr.map((e,i) => i === 3 ? 'new content' : e)
Between the spread operator (...), immutable array methods (slice, reduce, map, filter, and even sort if preceded by .slice()), immutability in native JS ain't half bad.
This can avoid boilerplate traditionally associated with immutable updates in JavaScript, because you just write
const copy = transform(original, stage => {
stage.someArray[index] = 42;
});
(set arr 3 "New content")
(set-in
deeply-nested
[arbitraty path to the element]
"New content")
arr = [
...arr.slice(0, 2),
'New Content',
...arr.slice(3)
]In the version you have 2 spread operators, an array construct and 3 hardcoded ints.
I might not use the correct academic terms, and I might not be yet fully accustomed to es2015, but this way of writing stuff always make me pause and double check the code.
const arr2 = Object.values({...arr, 3: 'New Content'});
You can add JIT too :) More JS, more time needed to reach decent runtime speed post JIT. React's first render is very slow.
If you're talking about a webpage then yes that would be awful.
There are several things to consider with download time:
- is this a website? why on earth do you need react or anything for a website?
- is this a single page web application? then to develop with a medium sized team and an increasing feature set its nice to pick a language and library/framework that enable that.
- do you really care about mobile users performance and bandwidth? then you need a native app
This is all unrelated to the article, which is merely an uninformed rant about someone who doesn't understand the point of immutability and its use within functional programming as opposed to shoe-horning it into imperative code.
It seems there's some minimum (think Greenspun) JavaScript necessary to have a working SPA that handles DOM manipulation, network communication, state management, module management, events, et cetera, somewhere between 50k and 100k. I would love to be proven wrong about this. Maybe as native ES6 (or WebAssembly) becomes the norm this will be less the case.
Choosing libraries shouldn't require careful examination of their output file size, especially if you only want half the functionality.
console.log("Hello world!")
I realize this is a silly example for such a powerful tool but I just wanted to quickly get a feel for what the compiler is capable of before I committed a whole lot of time to learning the language. All I got out of the exercise was that the compiler creates a much larger minimum package size than I'd hoped. I'd appreciate any suggestions on a better way of proving its value for the cautiously curious. The language itself seems great, as does the community.
Perhaps it's just a different paradigm from npm/webpack, e.g. utilizing a rich built-in library rather than, yeah, carefully grocery-shopping for only the components you need? I'm not saying one is necessarily better than the other but it does intuitively seem that choosy shopping will tend to yield a smaller package size, at least for small-to-medium applications.
I suggest watching this: