TodoMVC
Locked
12
12
 
|
Greetings!
-- As part of my new philosophy to write everything in Smalltalk or Clojure, I created a version of TodoMVC in Amber and I'd love to get some feedback[1]. Thanks to Hannes and Rodrigo for getting me up and running with their versions. My fork is at GitHub.[2] I followed the app specification[3] closely and the only thing that I think I'm missing is routing, but I don't see why I really need it other than to comply with the spec. I'm thinking of submitting the app to TodoMVC.com, but I wanted to get some feedback first. Have a great weekend! /ls [1] http://amber-todomvc.s3-website-us-east-1.amazonaws.com [2] https://github.com/tastejs/todomvc/blob/gh-pages/app-spec.md [3] https://github.com/statonjr/Amber-ToDo-List You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
fantastic work Larry, I wanted badly to have this for us, Amber is a Smalltalk and that’s where the MVC first insight and first execution was born!
Here is my feedback: 1. Don’t give them any excuse! I would take seriously the spec mostly to prevent the success of any last minute demon trying to get us out. Routing should not be hard at all. I’m sure you will get help if you ask for it 2. Loading the whole thing doesn’t cause the best impression in load times, what I think could be done is to have a version that has strictly what’s needed (no IDEs) and another one minified. So we could submit the app serving 3 version of the app: the slower but dev-able, the not-minified and the deployment version. I feel that if we do that we’ll have a super high morale helping to get us in Again, congrats and thanks for sharing your impressive work keep it up! On May 23, 2014, at 7:32 PM, Larry Staton Jr. <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Thanks Sebastian.
-- Agreed on both points. I'm working on minimizing the deploy and routing shouldn't be a problem. I think the live coding environment is a huge selling point. I've shown a few friends the environment and they were blown away. I'm hoping to present this at my local JavaScript Meetup soon, too. /ls On Friday, May 23, 2014 8:02:22 PM UTC-4, Sebastian Sastre wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Good work! I am interested to see how routing will be handled. As Sebastian mentioned, load times are really the big problem these days. JS libraries are piling up on one another and pull megz of JS into the browser... I feel a swing back to the server at one point...
Phil On Sat, May 24, 2014 at 2:06 AM, Larry Staton Jr. <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
[hidden email] wrote: > Good work! > > I am interested to see how routing will be handled. > > As Sebastian mentioned, load times are really the big problem these > days. JS libraries are piling up on one another and pull megz of JS > into the browser... I feel a swing back to the server at one point... Do not blame JS libraries. It's Amber which is unbearably big. One of the (!!!) kernel js files has 200K+. What is the (single) 100K jQuery in comparision? Nothing (I r.js'ed the amber/lang together to see the outcome. It was 2M IIRC. With all of the needed .js libraries, of course, but they take less then 20% there). > Phil Herby -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Yeah but the big thing is the dev version One thing angular does to get it done is, instead of depend on jquery, it uses jqLite see the green box here: https://docs.angularjs.org/api/ng/function/angular.element It sounds to me that Amber is using jquery but only very few features of it, so that's a point in which we might be overkilling it Conclusion: wonder if we could have our jqLite instead of jquery On Saturday, May 24, 2014 7:56:26 AM UTC-3, Herby wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Sebastian Sastre wrote: > Yeah but the big thing is the dev version > > We should brainstorm tactics to deal with that so then we can agree on > the best path and point guns > > One thing angular does to get it done is, instead of depend on jquery, > it uses jqLite Once again: jQuery's size is _not_ a problem at all. The problem is that Amber itself is bulky. > see the green box here: > https://docs.angularjs.org/api/ng/function/angular.element > > It sounds to me that Amber is using jquery but only very few features of > it, so that's a point in which we might be overkilling it > > Conclusion: wonder if we could have our jqLite instead of jquery Zepto is another option. But again, you optimize something what is marginal. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by sebastianconcept
Now, an Amber app takes a while to load indeed.
I had a look and yeah, Kernel-Collections.js is the 200K thing. But looking inside it, it is eminently compressible as this is mosty context things that are repeating again and again. It compresses down to 28K with gzip.
JQuery.min compresses to 32.5K Agreed, all of the Amber js files give more than that one. Maybe this is is the price to pay when emulating contexts.
Now who will not be using Kernel-Collections? It is at the core of most Smalltalk things.
Phil On Sat, May 24, 2014 at 4:59 PM, Sebastian Sastre <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Herby Vojčík
On Sat, May 24, 2014 at 5:50 PM, Herby Vojčík <[hidden email]> wrote:
Typical thing: smalltalk.addMethod( smalltalk.method({ selector: "addAll:", protocol: 'adding/removing',
fn: function (aCollection){ var self=this; return smalltalk.withContext(function($ctx1) { _st(aCollection)._do_((function(each){ return smalltalk.withContext(function($ctx2) {
return self._add_(each); }, function($ctx2) {$ctx2.fillBlock({each:each},$ctx1,1)})})); return aCollection; }, function($ctx1) {$ctx1.fill(self,"addAll:",{aCollection:aCollection},globals.Collection)})},
args: ["aCollection"], source: "addAll: aCollection\x0a\x09aCollection do: [ :each |\x0a\x09\x09self add: each ].\x0a\x09^ aCollection", messageSends: ["do:", "add:"],
referencedClasses: [] }), globals.Collection); Source is in there, smalltalk.addMethod(smalltalk.method({selector: protocol:fn:)... always the same. Can be factored out into one reusable call.
Also, smalltalk may be abbreviated (stk or something). But then it is quite ununderstandable when reading back compiled code and trying to find out why something breaks.
Do we want to optimize compactness? speed? understandability? ease of debuggin? Are we redoing the old assembly vs HLL but with JS bein the assembly? What do we really get by going the Amber way?
What do we avoid? To an outsider, the perceived speed is important indeed but software takes a while to get written and machines always get faster. So, next would be: can we produce asm.js with Amber compiler backend?
Out of my league but speed may then be superb!
Phil
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Herby Vojčík
Well you have to see the whole picture.
We have 2 environments, dev and production, and potentially a third, testing. Off course it would be great to have smaller code but I don’t care about loading 2MB local code for the development environment because the dev experience and productivity on Smalltalk is great. I’m pretty confident other developers will feel the same. What I do care is having a way to prevent loading that much in the production app because that could mean you have a business with it or you don’t. I understand that in the end the answer is in the numbers… I mean measuring real apps but if we can have smarter defaults at reasonable effort impacting on the deliverables then we shouldn’t dismiss it so quickly, should we? On May 24, 2014, at 12:50 PM, Herby Vojčík <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
sebastian wrote: > Well you have to see the whole picture. > > We have 2 environments, dev and production, and potentially a third, > testing. > > Off course it would be great to have smaller code but I don’t care > about loading 2MB local code for the development environment because Dev is more. 2MB was production with compiler before minification. > the dev experience and productivity on Smalltalk is great. I’m pretty > confident other developers will feel the same. > > What I /do/ care is having a way to prevent loading that much in the > production app because that could mean you have a business with it or > you don’t. > > I understand that in the end the answer is in the numbers… I mean > measuring real apps but if we can have smarter defaults at reasonable > effort impacting on the deliverables then we shouldn’t dismiss it so > quickly, should we? > > > > > On May 24, 2014, at 12:50 PM, Herby Vojčík <[hidden email] > <mailto:[hidden email]> > wrote: > >>> One thing angular does to get it done is, instead of depend on jquery, >>> it uses jqLite >> >> Once again: jQuery's size is _not_ a problem at all. The problem is >> that Amber itself is bulky. >> >>> see the green box here: >>> https://docs.angularjs.org/api/ng/function/angular.element >>> >>> It sounds to me that Amber is using jquery but only very few features of >>> it, so that's a point in which we might be overkilling it >>> >>> Conclusion: wonder if we could have our jqLite instead of jquery >> > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Am 24.05.2014 um 21:08 schrieb Herby Vojčík <[hidden email]>: Agreed. Did you do any further optimizations? Have a quick view there could be at least a few things removed: - class comments - method sources - protocols These aren’t needed in an optimized deployed target. To circumvent the problem we would need to define an „essential“ core of methods that developers can adhere to if they are really after loading speed and startup latency. Norbert
-- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by philippeback
Am 24.05.2014 um 18:05 schrieb [hidden email]: If you start deploying optimized builds that is one price you have to pay. In those builds you don’t have the dev environment anyway. So you need a context description and that should be easily mappable to your dev sources.
No, it won’t. Asm.js is not an option. It optimizes explicit typed languages that are compiled to javascript. Those optimizations you can have starting from javascript are part of the vm. Norbert
-- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
On May 24, 2014, at 4:28 PM, Norbert Hartl <[hidden email]> wrote:
If you start deploying optimized builds that is one price you have to pay. In those builds you don’t have the dev environment anyway. So you need a context description and that should be easily mappable to your dev sources. +1 companies are used to leave that problem to the developers using unit and integration tests The deployed stuff is really minified and unfriendly for anything but the direct final user's experience of the app I know is tempting for us to think debugging in hot but we should not make that feature a default by compromising load times. We might have a dev or debug version for that so we can say "hey put that user in the debuggable app’s version mode so we know what’s going on” but certainly not making it a default My expectation is to have something really good to develop with and really nicely deployed (read competitive for today) You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Larry Staton Jr.
I've updated the app to include routing with Flatiron Director[1], as per the spec. Here's the link to the updated app: http://bit.ly/amber-todomvc
-- I'm going to submit the app to TodoMVC and see if I can get Amber listed on the front page. /ls [1] https://github.com/flatiron/director On Friday, May 23, 2014 6:32:33 PM UTC-4, Larry Staton Jr. wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Larry
good to see that you added routing to http://amber-todomvc.s3-website-us-east-1.amazonaws.com/. I see that the IDE is no longer included. Is there some documentation available of your changes besides following https://github.com/hhzl/Amber-ToDo-List/network and looking at the code? --Hannes On 5/30/14, Larry Staton Jr. <[hidden email]> wrote: > I've updated the app to include routing with Flatiron Director[1], as per > the spec. Here's the link to the updated app: http://bit.ly/amber-todomvc > > I'm going to submit the app to TodoMVC and see if I can get Amber listed on > > the front page. > > /ls > > [1] https://github.com/flatiron/director > > On Friday, May 23, 2014 6:32:33 PM UTC-4, Larry Staton Jr. wrote: >> >> Greetings! >> >> As part of my new philosophy to write everything in Smalltalk or Clojure, >> >> I created a version of TodoMVC in Amber and I'd love to get some >> feedback[1]. Thanks to Hannes and Rodrigo for getting me up and running >> with their versions. My fork is at GitHub.[2] >> >> I followed the app specification[3] closely and the only thing that I >> think I'm missing is routing, but I don't see why I really need it other >> than to comply with the spec. I'm thinking of submitting the app to >> TodoMVC.com, but I wanted to get some feedback first. >> >> Have a great weekend! >> >> /ls >> >> [1] http://amber-todomvc.s3-website-us-east-1.amazonaws.com >> [2] https://github.com/tastejs/todomvc/blob/gh-pages/app-spec.md >> [3] https://github.com/statonjr/Amber-ToDo-List >> > > -- > You received this message because you are subscribed to the Google Groups > "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Larry Staton Jr.
I looked over the code and I think it should be clranedva bit before applying. For example,
Why is there so much explicit parentheses? Is there a reason for ` = true` and ` = false` in select blocks? Why not using foo contents: bar instead of manually bar appendToJQuery: foo asJQuery empty? There are probably more, but I stopped to write this mail, because I think it is important that the code published on TodoMVC be short and comprehensible. BTW, why is there only amber listed as bower dependency but there are lot of other (amber-unrelated) packages in repo? Leviroutes are probably not needed, and todomvc basics as well as director are not in bower.json, just in bower_components of the repo. Herby "Larry Staton Jr." <[hidden email]>napísal/a: I've updated the app to include routing with Flatiron Director[1], as per the spec. Here's the link to the updated app: http://bit.ly/amber-todomvc
-- I'm going to submit the app to TodoMVC and see if I can get Amber listed on the front page. /ls [1] https://github.com/flatiron/director On Friday, May 23, 2014 6:32:33 PM UTC-4, Larry Staton Jr. wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
Herby - Thanks for the feedback. Some of the code isn’t written in idiomatic Amber Smalltalk because this is my first Amber Smalltalk application and I’m not familiar with the idioms. I borrowed much of the code from other Amber projects that I found online or by searching the mailing list. I agree that the code should be cleaned up. I’ll do my best and, of course, patches welcome. :) With respect to bower dependencies, I need to clean some of that up. I initially tried leviroutes, but then re-read the spec and it specifies director. I’ve pushed that change to master. Note, too, that I have deploy off of the "minimal-deploy" branch in my repo which has a correct bower.json file. Finally, keep in mind that I wrote the TodoMVC application in about 3 days with only rudimentary experience with Amber Smalltalk (i.e., playing with the Counter on the website). I think that this is a strength of Amber Smalltalk: developer productivity. In addition, we can ride on coattails of Node.js by playing up the “same language on the client as on the server”. Keep the feedback coming! /ls On Friday, May 30, 2014 5:55:12 AM UTC-4, Herby wrote: I looked over the code and I think it should be clranedva bit before applying. For example, You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Hannes Hirzel
Hannes -
-- I'm working on documentation. It seems I need to do some code cleanup first. :) /ls On Friday, May 30, 2014 5:37:24 AM UTC-4, Hannes wrote: Larry You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
|
|
In reply to this post by Larry Staton Jr.
Larry Staton Jr. wrote: > Herby - > > Thanks for the feedback. Some of the code isn’t written in idiomatic > Amber Smalltalk because this is my first Amber Smalltalk application > and I’m not familiar with the idioms. I borrowed much of the code from > other Amber projects that I found online or by searching the mailing > list. I agree that the code should be cleaned up. I’ll do my best and, > of course, patches welcome. :) > > With respect to bower dependencies, I need to clean some of that up. I > initially tried leviroutes, but then re-read the spec and it specifies > director. I’ve pushed that change to master. Note, too, that I have IIRC they just recommend that for cases where routing is not built-in. But anyway, it's probably a plus if the one they recommend is used, they are familiar with it and it can make chances higher. > deploy off of the "minimal-deploy" branch in my repo which has a > correct bower.json file. Ah. Sorry, didn't look for bran ches. > Finally, keep in mind that I wrote the TodoMVC application in about 3 > days with only rudimentary experience with Amber Smalltalk (i.e., > playing with the Counter on the website). I think that this is a > strength of Amber Smalltalk: developer productivity. In addition, we > can ride on coattails of Node.js by playing up the “same language on > the client as on the server”. > > Keep the feedback coming! Ok. I'd use #{ '/'->[:..|..]. '/otherroute'->[...]. '/yetanotherroute'->[...] } instead of creating empty HashedCollection add at:put: in series. > > /ls > > > On Friday, May 30, 2014 5:55:12 AM UTC-4, Herby wrote: > > I looked over the code and I think it should be clranedva bit > before applying. For example, > > Why is there so much explicit parentheses? > > Is there a reason for ` = true` and ` = false` in select blocks? > > Why not using foo contents: bar instead of manually bar > appendToJQuery: foo asJQue > > There are probably more, but I stopped to write this mail, because > I think it is important that the code published on TodoMVC be > short and comprehensible. > > BTW, why is there only amber listed as bower dependency but there > are lot of other (amber-unrelated) packages in repo? Leviroutes > are probably not needed, and todomvc basics as well as director > are not in bower.json, just in bower_components of the repo. > > Herby > > "Larry Staton Jr." <[hidden email] <javascript:>>napísal/a: > > I've updated the app to include routing with Flatiron Director[1], > as per the spec. Here's the link to the updated app: > http://bit.ly/amber-todomvc <http://bit.ly/amber-todomvc> > > I'm going to submit the app to TodoMVC and see if I can get Amber > listed on the front page. > > /ls > > [1] https://github.com/flatiron/director > <https://github.com/flatiron/director> > > On Friday, May 23, 2 > > Greetings! > > As part of my new philosophy to write everything in Smalltalk > or Clojure, I created a version of TodoMVC in Amber and I'd > love to get some feedback[1]. Thanks to Hannes and Rodrigo for > getting me up and running with their versions. My fork is at > GitHub.[2] > > I followed the app specification[3] closely and the only thing > that I think I'm missing is routing, but I don't see why I > really need it other than to comply with the spec. I'm > thinking of submitting the app to TodoMVC.com, but I wanted to > get some feedback first. > > Have a great weekend! > > /ls > > [1] http://amber-todomvc.s3-website-us-east-1.amazonaws.com > <http://amber-todomvc.s3-website-us-east-1.amazonaws.com> > [2] > https://github.com/tastejs/todomvc/blob/gh-pages/app-spec.md > <https://g > [3] https://github.com/statonjr/Amber-ToDo-List > <https://github.com/statonjr/Amber-ToDo-List> > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to [hidden email] <javascript:>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email] > <mailto:[hidden email]>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/d/optout. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |