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 <pdebruic@gmail.com>:

Hi

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

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

Paul

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 available…

...

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, multiple 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…

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

-- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html