Re: [Pharo-dev] Web Frameworks and "Modern" Features

Hi Paul,

I moved the discussion to pharo-users because this has nothing to do
with Pharo developement and people could get upset.

2018-06-09 13:10 GMT-03:00 Paul DeBruicker <[hidden email]>:
So there is no framework refinement, but behavior partitioning into
newer tools that require more human training and adoption time.
If we don't have the resources of Facebook/Twitter/Google then why we
are integrating their solutions?

The real value of a framework is evolving to enable new refined
instantiations. This is not a problem of being covered by fashioned
tools, the problem is we are "buying" solutions from other ecosystems
where they don't care at all about Pharo, Seaside, Iliad, etc. We stop
building systems to integrate modules. Standard solutions like
Bootstrap don't came for free, it has a cost, for example if you have
to customize a component, you automatically loose the value of the
Smalltalk environment. But this cost is usually hidden behind
promotion and noise, the tools survive more than developer investment,
and usually after a few years the developer has to invest more time
and energy learning and using a newer external library... losing again
the chance to gain experience cycles with tools built for its own
niche.

>
> For static-site generators you'd probably want to use Teapot
> (http://smalltalkhub.com/#!/~zeroflag/Teapot) and just write the generated
> HTML to a file.  For Seaside you could make one using WABuilder but would
> need to add paths to all of the anchors on your site, which could be done
> with a RB transformation rule if you had a ton of links.
>

I get it, most standard things could be done already. My point is at
some point Seaside wasn't easily adaptable to not instantiate web
controllers, to define routes programmatically, etc.

>
> For the multiple competing JS library concern I'm not sure what that means
> exactly but also how it could be any different in this community vs e.g.
> Ruby/Rails.  Just gotta manage the namespaces in the DOM right I think?  If
> its been a problem for me I've forgotten or haven't noticed.
>

I mean the time when transition from Prototype/Scriptaculous was
promoted in favour first of MooTools (easier syntax, lightweight and
more modular than Prototype) and later of jQuery. Not counting other
client-side alternatives like Dojo or YUI. It means who's gonna invest
time = money, in a small community, building a good adaptor for the
next JS libraries? We should really stop assuming someone else will
just do it for us.

You're right, the tools could be out there. Except also for the lack
of feedback, and (as community) running always behind the big
players...

> There's definitely a very usable/useful set of things that can be done with
> what we have today.
>
> But no question the Rails or JS communities have more because there are more
> engineers/companies/resources in and behind them.
>
>
> Hope this helps.
>

Thank you, good points.

Hernán