Smalltalk › Amber Smalltalk

Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Herby Vojčík

Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

sebastian wrote:
>
> My expectation is to have something really good to develop with and
> really nicely deployed (read competitive for today)

It's impossible to be competitive, as others don't need to take all the
system with themselves, they use JS. Amber needs all the Collections,
Classes etc.

That's what I think.

It bothers me for a month or so, already. Thr world of today's (at least
in web) is a world of lots of small components. I am not telling just
the frontend side, at the server side, there is microservice architecture.

It is impossible, though, to write anything small with Amber - the
legacy of image. You always carry the system with yourself.

(I have a concrete example, in the previous project I needed certain
thing I implemented in Xontent jQuery plugin - but that's the thing - if
I wanted to keep it lean, making jQuery plugin was the easiest way)

So I don't know. If taken literally and more generally, it seems as
Amber is the dead end... only good to write big monolithical
applications. A Java application server of sort. :-(

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.

sebastianconcept

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

thanks for sharing that with us Herby

Even if we yet didn’t figured it out, this will help us think somehow

On May 24, 2014, at 8:07 PM, Herby Vojčík <[hidden email]> wrote:

>
>
> sebastian wrote:
> >
> > My expectation is to have something really good to develop with and
> > really nicely deployed (read competitive for today)
>
> It's impossible to be competitive, as others don't need to take all the system with themselves, they use JS. Amber needs all the Collections, Classes etc.
>
> That's what I think.
>
> It bothers me for a month or so, already. Thr world of today's (at least in web) is a world of lots of small components. I am not telling just the frontend side, at the server side, there is microservice architecture.
>
> It is impossible, though, to write anything small with Amber - the legacy of image. You always carry the system with yourself.
>
> (I have a concrete example, in the previous project I needed certain thing I implemented in Xontent jQuery plugin - but that's the thing - if I wanted to keep it lean, making jQuery plugin was the easiest way)
>
> So I don't know. If taken literally and more generally, it seems as Amber is the dead end... only good to write big monolithical applications. A Java application server of sort. :-(
>
> 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.

--
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.

Siemen Baader

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

Is it that bad? After some initial loading, a rich, single page Amber app that does routing in the frontend is very snappy. I think people are moving away from server side MVC frameworks and AJAX apps that have to make a http request for every navigation anyway for that reason. Also, collections and the cocore image have a sort-of fixed size, and even if they seem bulky now, they will not grow as fast as eg LTE connection speeds have increased the past few years.. So I think it scales well. But I don't have any data, and for my purposes the initial load overhead is ok.

Sebastian, since you are so engaged in this -- why don't you try to read up on state-of-the-art minification, server-side compression and content-type negotiation and graph the data of how much you can increase load speed while still serving the image? That would make a really cool blog post on Amber, I'd love to read it!

best,
Siemen

On 25 May 2014, at 02:06, sebastian <[hidden email]> wrote:

> thanks for sharing that with us Herby
>
> Even if we yet didn’t figured it out, this will help us think somehow
>
>
>
>
> On May 24, 2014, at 8:07 PM, Herby Vojčík <[hidden email]> wrote:
>
>>
>>
>> sebastian wrote:
>>>
>>> My expectation is to have something really good to develop with and
>>> really nicely deployed (read competitive for today)
>>
>> It's impossible to be competitive, as others don't need to take all the system with themselves, they use JS. Amber needs all the Collections, Classes etc.
>>
>> That's what I think.
>>
>> It bothers me for a month or so, already. Thr world of today's (at least in web) is a world of lots of small components. I am not telling just the frontend side, at the server side, there is microservice architecture.
>>
>> It is impossible, though, to write anything small with Amber - the legacy of image. You always carry the system with yourself.
>>
>> (I have a concrete example, in the previous project I needed certain thing I implemented in Xontent jQuery plugin - but that's the thing - if I wanted to keep it lean, making jQuery plugin was the easiest way)
>>
>> So I don't know. If taken literally and more generally, it seems as Amber is the dead end... only good to write big monolithical applications. A Java application server of sort. :-(
>>
>> 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.
>
> --
> 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.

philippeback

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

In reply to this post by sebastianconcept

On Sun, May 25, 2014 at 2:06 AM, sebastian <[hidden email]> wrote:

thanks for sharing that with us Herby

Even if we yet didn’t figured it out, this will help us think somehow

On May 24, 2014, at 8:07 PM, Herby Vojčík <[hidden email]> wrote:

>
>
> sebastian wrote:
> >
> > My expectation is to have something really good to develop with and
> > really nicely deployed (read competitive for today)
>
> It's impossible to be competitive, as others don't need to take all the system with themselves, they use JS. Amber needs all the Collections, Classes etc.

>
> That's what I think.

That's a quite harsh statement about competitive. The best competitive point for me is being able to make a solution for which a client would pay. With Amber we can do that.

>
> It bothers me for a month or so, already. Thr world of today's (at least in web) is a world of lots of small components. I am not telling just the frontend side, at the server side, there is microservice architecture.

>
> It is impossible, though, to write anything small with Amber - the legacy of image. You always carry the system with yourself.

The FileServer is something small. Extending a widget is small. User code can be small. Given the cognitive overload we are all under, that could mean something.

>
> (I have a concrete example, in the previous project I needed certain thing I implemented in Xontent jQuery plugin - but that's the thing - if I wanted to keep it lean, making jQuery plugin was the easiest way)

Sure, as in Seaside, we do write JS directly instead of using the Seaside-Javascript goodies. But once the plumbing is right, one can use coarser grained parts.

I agree that it is hard to pick what to use. Now, as technology moves very fast, who can tell what would be ok in 5 years from now?

But business apps do last and have to be maintained. So, Amber may provide something that we can deal with even if the underlying technology moves.

>
> So I don't know. If taken literally and more generally, it seems as Amber is the dead end... only good to write big monolithical applications. A Java application server of sort. :-(

Big monolithical apps aren't that bad. Gmail, Google Docs, StreetView... all look like pretty monolithical to me.

Hey, you got me depressed about Amber. Now, let's turn the question in another way: how could Amber help in creating microservice based apps? Can't we have a Amblang like there is a Slang in Pharo/Squeak? A subset that could rock in order to make microservices?

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.

--
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 Vojčík

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

[hidden email] wrote:

> On Sun, May 25, 2014 at 2:06 AM, sebastian <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> thanks for sharing that with us Herby
>
> Even if we yet didn’t figured it out, this will help us think somehow
>
>
>
>
> On May 24, 2014, at 8:07 PM, Herby Vojčík <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> >
> >
> > sebastian wrote:
> > >
> > > My expectation is to have something really good to develop
> with and
> > > really nicely deployed (read competitive for today)
> >
> > It's impossible to be competitive, as others don't need to take
> all the system with themselves, they use JS. Amber needs all the
> Collections, Classes etc.
>
> >
> > That's what I think.
>
>
> That's a quite harsh statement about competitive. The best competitive
> point for me is being able to make a solution for which a client would
> pay. With Amber we can do

that.

I thought it means competitive technically. If it was though this generally, than of course it's different.

> > It bothers me for a month or so, already. Thr world of today's
> (at least in web) is a world of lots of small components. I am not
> telling just the frontend side, at the server side, there is
> microservice architecture.
>
> > It is impossible, though, to write anything small with Amber -
> the legacy of image. You always carry the system with yourself.
>
>
> The FileServer is something small. Extending a widget is small. User
> code can be small. Given the cognitive overload we are all under, that
> could mean something.

Yes, user code yes. Just it's hard to play with other parts of JS ecosystem since need to bring the language with you makes it hard.

> > (I have a concrete example, in the previous project I needed
> certain thing I implemented in Xontent jQuery plugin - but that's
> the thing - if I wanted to kee
p it lean, making jQuery plugin was

> the easiest way)
>
>
> Sure, as in Seaside, we do write JS directly instead of using the
> Seaside-Javascript goodies. But once the plumbing is right, one can
> use coarser grained parts.
>
> I agree that it is hard to pick what to use. Now, as technology moves
> very fast, who can tell what would be ok in 5 years from now?
> But business apps do last and have to be maintained. So, Amber may
> provide something that we can deal with even if the underlying
> technology moves.
>
> >
> > So I don't know. If taken literally and more generally, it seems
> as Amber is the dead end... only good to write big monolithical
> applications. A Java application server of sort. :-(
>
>
> Big monolithical apps aren't that bad. Gmail, Google Docs,
> StreetView... all look like pretty monolithical to me.

Yes, and with namespaces and requirejs Amber is now fine with writing modules and libraries and combining them into main app. M
y main developer usability concern was ability to write libraries for Amber separately from app code, starting with changes to legacy loader back in 0.10 days and ending with namespace-path mapping in requirejs. This is what Amber does great now.

What is hard, is writing libraries for non-Amber.

The question is - should we try to achieve that, or just define this is not the thing that would be possible? If Amber is about writing the apps (and libs for them, for not reusable in pure JS), so be it. But I feel this is important exactly so that people could find out about Amber via some intermediate part they find useful and finding out it's written in Amber. Reaching out through modules and libraries is (IMO) order of magnitude higher than reaching via "great tool to make apps" (plus, the latter induce the fears of vendor lock-in).

> Hey, you got me depressed about Amber. Now, let's turn the question in

Well, I'm the most depressed person in the list, so no surprise :-)

>
another way: how could Amber help in creating microservice based apps?
> Can't we have a Amblang like there is a Slang in Pharo/Squeak? A
> subset that could rock in order to make microservices?
>
> 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.

aglynn42

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

In reply to this post by Herby Vojčík

The micro-service architecture is precisely the limitation of NodeJS and libraries built on top of it. Beyond doing something super simple, the technique falls apart (think of the nightmare of doing distributed transactions with micro-services). Most large companies won't allow JS to interact with any database due to the ease of corrupting data, so at best you get a micro-service based façade to monolithic services (not just Java based, but often mainframe based) in the back end.

Creating the JS façade itself is mainly a ploy by companies to get server side developers to learn JS so they can improve the web browser code, not anything intrinsically useful (this I've been told by CTOs at two major financial service companies). A developer (rather than a web designer) who knows JS well is a rarity, one who likes using it even rarer. The result is that the JS in the browser is mostly hacked together by people whose focus isn't programming.

If I were to posit a place for Amber, it's in its ability to make rote maintenance and upgrading of code bases so routine it could be assembly lined. A focus on each small part of doing that type of coding would allow each part to be more automated, increasing the efficiency of what is largely uninteresting work in the first place. Of course that can only happen after Amber (or something like it) replaces the kinds of tools that run on the assumption that all programmers use a tty from 1972, and not an advanced interactive system. Once the code bases themselves are accessible to more advanced tooling, this kind of automation can be done. Amber's ability to use existing JavaScript code bases should therefore be the focus of initial development. Get people to use it to perform and automate rote, boring maintenance and upgrades of JavaScript. Eventually they'll prefer writing the stuff in Amber in the first place The compiler can then be modified to accomplish a similar thing for other legacy code bases. Inventive code should be where developers' time and talent gets used, but we need to industrialize the rote maintenance and upgrades to old code that currently take up much of the available time and energy.

Andrew Glynn

On Saturday, May 24, 2014 6:07:00 PM UTC-5, Herby wrote:

sebastian wrote:
>
> My expectation is to have something really good to develop with and
> really nicely deployed (read competitive for today)

It's impossible to be competitive, as others don't need to take all the
system with themselves, they use JS. Amber needs all the Collections,
Classes etc.

That's what I think.

It bothers me for a month or so, already. Thr world of today's (at least
in web) is a world of lots of small components. I am not telling just
the frontend side, at the server side, there is microservice architecture.

It is impossible, though, to write anything small with Amber - the
legacy of image. You always carry the system with yourself.

(I have a concrete example, in the previous project I needed certain
thing I implemented in Xontent jQuery plugin - but that's the thing - if
I wanted to keep it lean, making jQuery plugin was the easiest way)

So I don't know. If taken literally and more generally, it seems as
Amber is the dead end... only good to write big monolithical
applications. A Java application server of sort. :-(

Herby

blake watson

Re: Amber unable to be lean, define its niche (was: Re: [amber-lang] TodoMVC)

Do I misunderstand but doesn't this:

>>>(I have a concrete example, in the previous project I needed certain thing I implemented in Xontent jQuery plugin - but that's the thing - if I wanted to keep it lean, making jQuery plugin was the easiest way)<<<

Belie the notion that you did anything "lean", since your plugin requires JQuery? (I'm not snarking, that's just what struck me, and I'm unaware of relative size between Amber and JQuery. But having used JQuery I don't know that I'd call it "lean".)

On Mon, May 26, 2014 at 2:10 PM, Andrew Glynn <[hidden email]> wrote:

The micro-service architecture is precisely the limitation of NodeJS and libraries built on top of it. Beyond doing something super simple, the technique falls apart (think of the nightmare of doing distributed transactions with micro-services). Most large companies won't allow JS to interact with any database due to the ease of corrupting data, so at best you get a micro-service based façade to monolithic services (not just Java based, but often mainframe based) in the back end.

Creating the JS façade itself is mainly a ploy by companies to get server side developers to learn JS so they can improve the web browser code, not anything intrinsically useful (this I've been told by CTOs at two major financial service companies). A developer (rather than a web designer) who knows JS well is a rarity, one who likes using it even rarer. The result is that the JS in the browser is mostly hacked together by people whose focus isn't programming.

If I were to posit a place for Amber, it's in its ability to make rote maintenance and upgrading of code bases so routine it could be assembly lined. A focus on each small part of doing that type of coding would allow each part to be more automated, increasing the efficiency of what is largely uninteresting work in the first place. Of course that can only happen after Amber (or something like it) replaces the kinds of tools that run on the assumption that all programmers use a tty from 1972, and not an advanced interactive system. Once the code bases themselves are accessible to more advanced tooling, this kind of automation can be done. Amber's ability to use existing JavaScript code bases should therefore be the focus of initial development. Get people to use it to perform and automate rote, boring maintenance and upgrades of JavaScript. Eventually they'll prefer writing the stuff in Amber in the first place The compiler can then be modified to accomplish a similar thing for other legacy code bases. Inventive code should be where developers' time and talent gets used, but we need to industrialize the rote maintenance and upgrades to old code that currently take up much of the available time and energy.

Andrew Glynn

On Saturday, May 24, 2014 6:07:00 PM UTC-5, Herby wrote:

sebastian wrote:
>
> My expectation is to have something really good to develop with and
> really nicely deployed (read competitive for today)

It's impossible to be competitive, as others don't need to take all the
system with themselves, they use JS. Amber needs all the Collections,
Classes etc.

That's what I think.

It bothers me for a month or so, already. Thr world of today's (at least
in web) is a world of lots of small components. I am not telling just
the frontend side, at the server side, there is microservice architecture.

It is impossible, though, to write anything small with Amber - the
legacy of image. You always carry the system with yourself.

(I have a concrete example, in the previous project I needed certain
thing I implemented in Xontent jQuery plugin - but that's the thing - if
I wanted to keep it lean, making jQuery plugin was the easiest way)

So I don't know. If taken literally and more generally, it seems as
Amber is the dead end... only good to write big monolithical
applications. A Java application server of sort. :-(

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.