Re: [elm-discuss] Re: Comments on the TEA Components package

> > We did spend the first 6 months or so of our project following the advice > to not use nested TEA components. Our experience was that the perceived > complexity of the app grew exponentially to the point where it was > difficult to make progress. We refactored into a nested TEA structure

Re: [elm-discuss] Re: Comments on the TEA Components package

> I have not seen the reverse happening. We did spend the first 6 months or so of our project following the advice to not use nested TEA components. Our experience was that the perceived complexity of the app grew exponentially to the point where it was difficult to make progress. We

[elm-discuss] A Code Teaching Analogy

I once tried teaching several friends to code who'd never written a line before. I thought the best way would be to introduce each keyword in the language, one at a time, and explain what they do and how good programmers use them. One of the keywords was "for", as in the "for loop". I was baffled

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

Very well put Mark. Regarding Nicholas' advice on "The process" > 6. Do things in life that make you happy. If it upsets you that Elm lacks something you think is super important, maybe take a break and come back later. That's what I've done. I'm back in JS land and Getting Things Done. Elm's

Re: [elm-discuss] Re: Comments on the TEA Components package

> > Sorry again for confusing. > It's all good! :) You were super polite and respectful throughout. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to

Re: [elm-discuss] Re: Comments on the TEA Components package

> > The structure camp says (in many more words) "I've seen your alternative > and it isn't a real alternative. It's a pathway that decades of software > industry experience indicates leads to creating big balls of mud." > This idea would hold more water if people hadn't tried what you're

Re: [elm-discuss] Re: Comments on the TEA Components package

I just read the whole conversation on Slack and realized what I said here was somewhat pointless. I apologize for not reading the context. So Marek's library is for organizing entire app, not about using external library. If so, Richard's answer on reddit seems best fitted. About the external

[elm-discuss] Re: Comments on the TEA Components package

> > > I thought I've understood this but I'm more and more confused by what > you're saying: > >> Crucially, between 0.16 and today, *we learned that a Model-View-Update >> triplet is the wrong unit of composition for Elm applications.* > > init update and subscribe are actually function.

[elm-discuss] elm-shadertoy updated for Elm-0.18

Hi, I've updated elm-shadertoy to work with Elm 0.18. This is a really fun project and a great way to learn about writing 3D shaders. If you've ever wanted to play with that side of WebGL please check it out! https://github.com/kfish/elm-shadertoy >From the original announce (30 May 2014!): It

[elm-discuss] Discovery: Model /= Database

I'm probably slow, but in recent months I've discovered that trying to use Elm's Model like a database or cache (as I have previously seen suggested) has turned out to be pretty painful for me. An example database-minded model where a section could display *either* a list of employees *or* a

[elm-discuss] Re: Comments on the TEA Components package

Richard, this is what you said about composing update functions: > I'll reiterate that thinking about application organization as "composing > TEA-shaped units" is neither officially recommended nor what Elm is > designed for... > > How do you propose to split the functionality one has

Re: [elm-discuss] Re: Comments on the TEA Components package

I think we have two general trains of thought regarding development here. One is YAGNI. Let things grow organically. Refactor when it gets messy. The other is Build for Success. Over engineer because you will probably end up shipping the prototype and once you do it will be too late to go back

[elm-discuss] Re: Scaling Elm

Erik, Marek, about the tea-component package: If you're discouraged by the > boilerplate for nested update and view functions, you can clean-up the > boilerplate with a single function each... no need to create an entire > abstraction package. > that sounds like what we do now. First of all

Re: [elm-discuss] Re: Comments on the TEA Components package

Richard, > Can you think of a way to use this overloaded word in a way where the > people in the discussion are not confused by it, even though they think it > means different things? I don't know. I just answered the question why I received your message as "DIY every time". I'm not looking

Re: [elm-discuss] Re: Comments on the TEA Components package

> I'm curious what makes it sound that way, since as you noted, that is not >>> the point I'm making. >>> >> >> I don't know if others feels like me or not. But at least for me, "no >> components" sounds a bit confusing (it is in official guide too). >> > > I view it as destructive so,

Re: [elm-discuss] Re: Comments on the TEA Components package

On Wed, Apr 19, 2017 at 11:19 PM, Yosuke Torii wrote: > I'm curious what makes it sound that way, since as you noted, that is not >> the point I'm making. >> > > I don't know if others feels like me or not. But at least for me, "no > components" sounds a bit confusing (it is

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I don't know if others feels like me or not. But at least for me, "no > components" sounds a bit confusing (it is in official guide too). As you > explained the context behind the term "component" is quite huge. I use the > word "component" just to say "reusable UI", so "no component"

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I'm curious what makes it sound that way, since as you noted, that is not > the point I'm making. > I don't know if others feels like me or not. But at least for me, "no components" sounds a bit confusing (it is in official guide too). As you explained the context behind the term "component"

[elm-discuss] Re: Scaling Elm

Marek, about the tea-component package: If you're discouraged by the boilerplate for nested update and view functions, you can clean-up the boilerplate with a single function each... no need to create an entire abstraction package. On Wednesday, April 19, 2017 at 3:34:31 PM UTC-4, Marek Fajkus

Re: [elm-discuss] Re: Comments on the TEA Components package

> > You are right if everyone make their UI from scratch, but how about others > who wants to *use *existing library? For instance, date picker is a > popular widget. We expect this widget to do lot of complex things behind > the scene. But it requires state management (e.g. selected month).

[elm-discuss] Re: Scaling Elm

> > Marek, > > One difference might be that we don't deal with sign-in in SPA itself. >> We're using Html.programWithFlags and passing user info to elm on >> embedding. > > > Good stuff. Less work when you don't have to worry about auth states. > it's helping us a lot. Anyway this

Re: [elm-discuss] Re: Comments on the TEA Components package

> > I've seen agile teams that could generate lots of small changes but when > faced with needing to do something big found themselves profoundly stuck. > In Elm? the distillation of the don't use nested TEA argument when people have > asked what to do instead has tended to be "use functions"

Re: [elm-discuss] Re: Comments on the TEA Components package

Hey folks, I just want to say, it's really really really hard to reply to these posts which are both really long and really dense. It's better to answer in a terse, short format. This is a conversation - not a blog post. Longer comments and responses are usually better in a blog post, because

Re: [elm-discuss] Re: Comments on the TEA Components package

The monster model design is one aspect that leads to the ball of mud code. Let's look at the source quote for the term big ball of mud: A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code

Re: [elm-discuss] Re: Comments on the TEA Components package

Richard, I'm curious how your product *uses* (not makes) external UI library. You are right if everyone make their UI from scratch, but how about others who wants to *use *existing library? For instance, date picker is a popular widget. We expect this widget to do lot of complex things behind

[elm-discuss] Re: Scaling Elm

Marek, One difference might be that we don't deal with sign-in in SPA itself. > We're using Html.programWithFlags and passing user info to elm on > embedding. Good stuff. Less work when you don't have to worry about auth states. On Wednesday, April 19, 2017 at 1:48:39 PM UTC-4, Marek

[elm-discuss] Re: Scaling Elm

Oliver, We have the Store abstraction that I mentioned for data synchronisation Sure. I'm sure this isn't too different - conceptually - from what we're doing. Although our app manages some complicated processes, the communication with the backend server is as simple as it gets - json gets

Re: [elm-discuss] Re: Task ports: A proposal to make it easier to integrate JS with Elm.

Since the call is for concrete use cases, here is one: Reading from local storage. My program wants to cache various things in local storage or for the purposes of this example it wants to read from various locations in local storage to get the values needed at various points in the model/UX. If

Re: [elm-discuss] Re: Comments on the TEA Components package

> > "just write one monster model" approach > Mark, this is about the third time you've insinuated that my explanation of how to split things up

[elm-discuss] Re: Scaling Elm

I think this would be great to have and would be glad to contribute. Just to be clear, you are proposing we come up with one set of functionality, that then multiple people implement using different approaches? Like TodoMVC, but a larger example that also encompasses server communication and

[elm-discuss] Re: Scaling Elm

> > That appears to have much in common with our app. It seems useful to > compare what people building SPAs are currently doing so here's a rough > gist of the folder/file structure that we're using > https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a > few differences

Re: [elm-discuss] Re: Comments on the TEA Components package

> > so, the Model-View-Update triplet *is NOT* the wrong unit of composition > for Elm applications? :) > > > How do you propose to split the functionality one has in a highly >> complex app with a lot of pages without using those triplets? >> >> I don't haha...I just defended their use a few

[elm-discuss] Re: Scaling Elm

That appears to have much in common with our app. It seems useful to compare what people building SPAs are currently doing so here's a rough gist of the folder/file structure that we're using https://gist.github.com/opsb/d0977bcb30b42302f3f2dc3daf0befec. There's a few differences worth pulling

Re: [elm-discuss] Re: Comments on the TEA Components package

Here is where our app is migrating after starting as an intermixture of view-side code and data-side code. The high level split is a store and a display. The store knows about things like how to talk to our server. As I summarized it, the UX code should know nothing about Phoenix. The display

[elm-discuss] Re: Scaling Elm

I'm a little pressed for time, but I'll try to give a general architecture outline that works really well for us. Our primary elm SPA is a customer facing administrative control panel that communicates with a backend api server and amazon S3. The app manages authentication, authorization,

[elm-discuss] Re: Scaling Elm

Now that I think of I remember that Josh Adams has been working on https://github.com/dailydrip/firestorm which is open source and has an Elm client. It's written as an SPA so it may serve as a good subject for this discussion. On Wednesday, 19 April 2017 17:21:04 UTC+2, Marek Fajkus wrote: >

[elm-discuss] Re: Scaling Elm

I would like to help with this by contributing some version. Anyway it's crucial to point out that this is really not easy thing to do. I like idea with MusicBrainz db but that doesn't include changing data on server. Also it's hard to demonstrate scaling without some noise (unrelated business

Re: [elm-discuss] Re: Comments on the TEA Components package

First of all I have to say I'm really glad we have this discussion. I know it's sometimes frustrated to face different opinions but outcome is definitely worth it. It looks like we're really not on same page and can learn something from other here. Also it seems that groups are good place to

[elm-discuss] Re: Source Maps? /was Elm Dev Tools

I'm working on code coverage tool, although not in the "source maps + Istanbul" way: https://groups.google.com/forum/#!topic/elm-dev/1tHjTG1z6EM It currently lives on Github in Janiczek/elm-compiler .

[elm-discuss] Re: Scaling Elm

That's a pretty good list. I'd add interacting with sound, files and focus, which require side-effect like interaction and haven't really been addressed well yet. On Wednesday, April 19, 2017 at 2:11:05 AM UTC-7, Peter Damoc wrote: > > Hello community, > > Scaling Elm apps seams to be a

Re: [elm-discuss] Re: ANN: TypedSvg

On Tue, Apr 18, 2017 at 7:20 AM, Jakub Hampl wrote: > Think of the element akin to the element in HTML. Yes, fairly > often you will simply pass a string to it, but it needing lower level > styling is pretty common. > > For the API you proposed, what would happen if you

Re: [elm-discuss] Scaling Elm

On Wed, Apr 19, 2017 at 3:11 AM, Peter Damoc wrote: > - complex widget reuse (a module/widget that generates side-effects; e.g. > a weather widget, some stock ticker, an ad provided by a third party) > Selfishly, a rich text editor with custom elements would be awesome. I'm

[elm-discuss] Re: Scaling Elm

I think this would be fantastically useful :) I've kept out of discussions regarding architecture as they've been going in circles for the last 6 months or so. An example SPA seems like a great way to move forwards. Something which every SPA I've ever written has included is a Store of some

[elm-discuss] Scaling Elm

Hello community, Scaling Elm apps seams to be a recurring topic. I was wondering if maybe we could negotiate a minimal set of functionality, something similar to ToDoMVC, that could be implemented using different approaches to explore what could be the best way to structure the code. What

Re: [elm-discuss] Re: Comments on the TEA Components package

so, the Model-View-Update triplet *is NOT* the wrong unit of composition for Elm applications? :) Don't you see how people starting up with Elm could get confused by this kind of messages? On Wed, Apr 19, 2017 at 10:03 AM, Richard Feldman < richard.t.feld...@gmail.com> wrote: > > How do you

Re: [elm-discuss] Re: Comments on the TEA Components package

> How do you propose to split the functionality one has in a highly complex app > with a lot of pages without using those triplets? I don't haha...I just defended their use a few posts ago, complete with the specific example of the reusable signup form. -- You received this message because

Re: [elm-discuss] Re: Comments on the TEA Components package

On Wed, Apr 19, 2017 at 9:19 AM, Richard Feldman < richard.t.feld...@gmail.com> wrote: > My point that there's a simple way to scale Elm applications by > abstracting at the function level has gone uncontested for awhile in this > thread. I think at this point I've said my piece and might as well

Re: [elm-discuss] Re: Comments on the TEA Components package

My point that there's a simple way to scale Elm applications by abstracting at the function level has gone uncontested for awhile in this thread. I think at this point I've said my piece and might as well move on. It's cool for people to have philosophical goals separate from the goal of a nice