This is so above my level I'm uncomfortable reading any further than the first section, of which I've gotten at least something. All the same, it all feels like information I could use... maybe...
This is so above my level I'm uncomfortable reading any further than the first section, of which I've gotten at least something.
All the same, it all feels like information I could use... maybe five years into the future, when I finally know what MVC is, how to render data immutable ("kinda weird" sounds about right), and how to write code that works anything like efficiently.
Steven Wittens does seem to like to show off neat stuff and he's also not writing for a general audience. This article is somewhat philosophical and it assumes a pretty extensive background in...
Steven Wittens does seem to like to show off neat stuff and he's also not writing for a general audience. This article is somewhat philosophical and it assumes a pretty extensive background in software design.
That's the impression I got. It's not as though I feel any dumber: it's just that the concepts explained here are, like I said, above my level of experience. @radiator
That's the impression I got. It's not as though I feel any dumber: it's just that the concepts explained here are, like I said, above my level of experience.
In case it helps: MVC is short for "model view controller" which is a classic design pattern for user interface components. It dates back to SmallTalk and has seen a lot of variations since then....
In case it helps:
MVC is short for "model view controller" which is a classic design pattern for user interface components. It dates back to SmallTalk and has seen a lot of variations since then.
"Immutable data" means that you don't update objects in place, you make a new version instead. Some programming languages support it better than others. For example, in many programming languages, strings are immutable. If you pass a string to a function then the function can't modify the original, unless you do something special to arrange for that.
That's the thing: I understand the very next step from "words" to "their meaning". I knew what MVC was (vaguely) before reading the article or your comment, and I had an idea about what...
That's the thing: I understand the very next step from "words" to "their meaning". I knew what MVC was (vaguely) before reading the article or your comment, and I had an idea about what "immutable" in "immutable data" meant.
It's what these concepts mean in practice – what they look like, what they smell like, how or why would one use them – that has me lost.
I think I used the MVC model by accident when first touching upon Angular. It had the App thing that you had to connect to an AppController... Then there's the newer ones, like React, where you have state and view that you have to render() onto the DOM...
I think I know what that means, in as much as I recognize the concept.
I don't believe I've ever touched immutable data. I wouldn't even touch it now: to me, for what my experience is worth, it appears thoroughly inefficient, especially in an engine as slow as JavaScript. I imagine that, for something like Intergrid, it would be like spitting in the user's face if I try to repaint the whole view after every change. (Which is apparently what Indigrid does. How it remains blazingly fast while doing so is a mystery to me that has a tag of "C++" attached to it.)
The original terminology has been reused a lot even as the way people write user interfaces has changed. The "state" in Angular and React are descendants of "Model." A View does pretty much the...
The original terminology has been reused a lot even as the way people write user interfaces has changed. The "state" in Angular and React are descendants of "Model." A View does pretty much the same thing as before, but originally you had to write the code to paint the UI using 2D graphics calls, and in Angular it's a template, while in React you write a render function.
"Controller" is often used for however events are handled. Originally it was polling the keyboard directly when the widget has focus.
One of the points being made in the article is that originally there was a Model, View, and Controller for each UI widget, and coordination between them was ad-hoc. Now there is a better design with just one state for the whole UI.
There are JavaScript libraries for working with immutable data but yeah, it's going against the grain of the language. You might want to try programming in Elm to get a feel for it. You do lose some efficiency but a lot of it can be gained back again with compiler magic and clever data structures.
Would that not be the sort of metagaming that exposes the weaknesses of the platforms and, instead of fixing them, walks around the elephant in the room?
You do lose some efficiency but a lot of it can be gained back again with compiler magic and clever data structures.
Would that not be the sort of metagaming that exposes the weaknesses of the platforms and, instead of fixing them, walks around the elephant in the room?
Depends on the application. The situation with React is similar. There is overhead compared to manipulating the DOM directly, but sometimes it avoids unnecessary work, so you come out ahead.
Depends on the application. The situation with React is similar. There is overhead compared to manipulating the DOM directly, but sometimes it avoids unnecessary work, so you come out ahead.
This is so above my level I'm uncomfortable reading any further than the first section, of which I've gotten at least something.
All the same, it all feels like information I could use... maybe five years into the future, when I finally know what MVC is, how to render data immutable ("kinda weird" sounds about right), and how to write code that works anything like efficiently.
Steven Wittens does seem to like to show off neat stuff and he's also not writing for a general audience. This article is somewhat philosophical and it assumes a pretty extensive background in software design.
That's the impression I got. It's not as though I feel any dumber: it's just that the concepts explained here are, like I said, above my level of experience.
@radiator
In case it helps:
MVC is short for "model view controller" which is a classic design pattern for user interface components. It dates back to SmallTalk and has seen a lot of variations since then.
"Immutable data" means that you don't update objects in place, you make a new version instead. Some programming languages support it better than others. For example, in many programming languages, strings are immutable. If you pass a string to a function then the function can't modify the original, unless you do something special to arrange for that.
That's the thing: I understand the very next step from "words" to "their meaning". I knew what MVC was (vaguely) before reading the article or your comment, and I had an idea about what "immutable" in "immutable data" meant.
It's what these concepts mean in practice – what they look like, what they smell like, how or why would one use them – that has me lost.
I think I used the MVC model by accident when first touching upon Angular. It had the
Appthing that you had to connect to anAppController... Then there's the newer ones, like React, where you havestateandviewthat you have torender()onto the DOM...I think I know what that means, in as much as I recognize the concept.
I don't believe I've ever touched immutable data. I wouldn't even touch it now: to me, for what my experience is worth, it appears thoroughly inefficient, especially in an engine as slow as JavaScript. I imagine that, for something like Intergrid, it would be like spitting in the user's face if I try to repaint the whole view after every change. (Which is apparently what Indigrid does. How it remains blazingly fast while doing so is a mystery to me that has a tag of "C++" attached to it.)
The original terminology has been reused a lot even as the way people write user interfaces has changed. The "state" in Angular and React are descendants of "Model." A View does pretty much the same thing as before, but originally you had to write the code to paint the UI using 2D graphics calls, and in Angular it's a template, while in React you write a render function.
"Controller" is often used for however events are handled. Originally it was polling the keyboard directly when the widget has focus.
One of the points being made in the article is that originally there was a Model, View, and Controller for each UI widget, and coordination between them was ad-hoc. Now there is a better design with just one state for the whole UI.
There are JavaScript libraries for working with immutable data but yeah, it's going against the grain of the language. You might want to try programming in Elm to get a feel for it. You do lose some efficiency but a lot of it can be gained back again with compiler magic and clever data structures.
Would that not be the sort of metagaming that exposes the weaknesses of the platforms and, instead of fixing them, walks around the elephant in the room?
Depends on the application. The situation with React is similar. There is overhead compared to manipulating the DOM directly, but sometimes it avoids unnecessary work, so you come out ahead.
I'm tempted to go on tangents to discuss DOM manipulation, but it's clearly outside the topic.
Either way, thanks for elaborating on it a little.