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]>:
> I think we're doing OK and that its a "discoverability" problem not a "does
> not exist or work" problem. E.g. here is Johan's talk about integrating
> ReactJS & Seaside https://www.youtube.com/watch?v=1eSGO7QSz5c
> I think part of the problem is that Facebook/Google/Amazon dominate the 'new
> hotness' discussions and no one has problems at their scale so the solutions
> that work for them that they advocate that people adopt (so e.g. their
> hiring pool is better for them) aren't necessarily necessary/appropriate for
> smaller sites with fewer engineers.
> For responsive design if he means sites that look good on big or small
> screens we're OK as its mostly a CSS problem which can be handled out of the
> box by adopting either Torsten's Twitter Bootstrap library
> (http://smalltalkhub.com/#!/~TorstenBergmann/Bootstrap) or Cyril's Google
> Material Design adaptation (https://github.com/DuneSt/MaterialDesignLite)
> if you're using Seaside. Or just setting a few viewport width breakpoints
> in your existing css and changing styles appropriately if you don't want to
> adopt one of those frameworks or are using Teapot or Iliad or whatever.
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
> 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.
> I'd be happy to learn more about the other things he mentions. I know
> there's this page that describes how Seaside has some inherent security
> protections (http://seaside.st/about/security) but maybe he's referring to
> something different? Also testing a Seaside site is pretty straightforward
> with https://github.com/SeasideSt/Parasol
> So anyway, I think its out there. Mostly. Except for buzz.
You're right, the tools could be out there. Except also for the lack
of feedback, and (as community) running always behind the big
> 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.
> Sean P. DeNigris wrote
>> Hernan related running into the following limitations with Pharo web
>> frameworks. I wonder if these are all still missing or if any are now
>>> None of them was easily adapted to the emerging web trends for the last
>>> years like the
>>> appearance of static site generators, adaptive/responsive design,
>>> competing JS
>>> libraries, semantic web, mobility, etc. not to mention they lack
>>> "standard" built-in features
>>> such as caching, template, security frameworks.
>> "adaptive/responsive design" in particular seems like a pretty big
>> limitation given current expectations…
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
|Free forum by Nabble||Edit this page|