Seaside done?
Locked
Seaside done?
 
|
Re: Seaside done?
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
I concur. Seaside is a great framework, and those who build and maintain it deserve our thanks. However, I think the question was not whether it works, but what’s the current development status and whether it’s going anywhere. Without diminishing the effort of those why try to keep it current, I think it’s important to understand both the strength and the weaknesses. Seaside is a fantastic framework to dynamically generate HTML that is in sync with the application state - continuations etc. The semantic that closely resembles HTML is great. That said, I think that like Smalltalk in general, Seaside’s destiny is to be a niche framework with a limited use mostly in tightly controlled internal environments like the one Bob describes. ‘It just works’ for a fairly narrow range of scenarios. It’s fine for an internal web application (with some limitations) but I wouldn’t use it for anything that requires a large-volume, security sensitive web app available publicly over the Internet. Here are my reasons, and to be clear - this is not intended as a criticism of those who dedicate their time and skill to keep it running: Seaside security is fairly poor. It doesn’t offer any protection against CSRF attacks or session hijacking. The built-in basic authentication only supports MD5-hashed password which has not been considered secure since 2004. Using other authentication mechanisms is non-trivial and can lead to deploying catastrophically insecure application (don’t ask me how I know). Seaside use of third-party JS libraries gives you two options: use a Seaside library that wraps the original JS, or use JS directly. The first option emits JS code that is several years behind (current Seaside jQuery is from 2017?), in most cases with known vulnerablities that are fairly easily exploitable. The second option robs the developer of all the nice application state integration capabilities. Both options lead to incredibly ugly JS code on the client side. Now - some people think that’s not a problem. I disagree - in a modern web application you need to be able to develop and debug at least partially in the web browser, and your JS readability will directly affect both your productivity and the quality of your code. Last but not least, handling of volume has been issue. I don’t have experience with a deployed Seaside app on Pharo, but I know that on VW you quickly reach a point where your app performance suffers even with a couple hundred users. With GS, you need a multitude of Gems to handle even relatively modest load. I think this would be probably the worst weakness - today’s web apps are built for tens of thousands of concurrent users, and even with the use of a load balancer, this would be a limiting factor for anyone considering the deployment of a globally reachable web app. Would I consider Seaside for a low-volume, tightly controlled internal web app? Absolutely. I would even use it for a publicly accessible web app in a geographically limited market and no sensitive data. But despite my admiration for the work that has been done, I would advise anyone against using it for anything ’serious’ on the open internet. In that sense, I think Seaide is ‘done’ and not going anywhere. It can be maintained and incrementally improved for sure, but I don’t expect any new features that would make it feasible for a large scale app delivered to the masses. Jerry Kott This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
signature.asc (849 bytes)
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Re: Seaside done?
|
|
Thanks for everyone's feedback. I am not going to get drawn into ‘compare Seaside vs. X’. Zoom is hardly a benchmark we should be using anyway. As for other web frameworks, there are so many different criteria and usage scenarios that any attempt for comparison would immediately raise objections from someone, and this thread could quickly devolve into a ‘what about …’ kind of discussion. WAAdmin class >> register:asApplicationAt:user:password: uses WAAuthConfiguration and WAAuthenticationFilter so there IS a default authentication of components. However, I may have been wrong in stating that the algorithm used is MD5. I remember if from a couple of years ago, and in any way this appears to be GRPlatform specific, so not exactly a Seaside issue. My humble apologies. I know about the authentication issues because I’ve seen them, and I had to fix them. I can’t discuss details because I am bound by confidentiality and intellectual property agreements. So… don’t ask :) When it comes to security concerns, again comparisons with other tools are pointless. What matters is ‘is X vulnerable, and if so, is it exploitable’. That ‘it can be fixed easily’ doesn’t matter. I am aware that Seaside escapes all output so (AFAIK) there is no XSS vulnerability. I’d be only too happy to see more action on Seaside because it IS a great framework, and I look forward to subject it to a bit more formal security tests if I get a change. I don’t want to change the subject of this thread, so I am going to write about the security survey in another thread. Here I’ll just mention that I reported on it quite extensively at ESUG 2018. I mentioned both in my presentation and in the mailing lists the creation of a Smalltalk security google group, interest from the community has been minimal. I stopped paying the $30/month for Survey Monkey after about a year, but I do have the raw data somewhere. As I said - subject for another thread. Keep up the good work - don’t take my reservations the wrong way. Seaside has its place, it’s just that it has been and will remain a niche. Jerry Kott This message has been digitally signed. PGP Fingerprint: A9181736DD2F1B6CC7CF9E51AC8514F48C0979A5
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Seaside done?
|
|
| Free forum by Nabble | Edit this page |