I have only been working with web technology for about half a year now, but I have worked with JSP/Servlets and Tomcat, RoR, JQuery, Prototype, JSON, XHTML, CSS, PHP to name a few and read countless articles on many more. While I was reading this article I thought Seaside looked worth investigating, but the main thing that stuck in my head was "Hmm. ANOTHER framework that I should look into that uses ANOTHER programming language and has different quirks and different advantages and different requirements than the others that have learned. I wonder if I will ever have the time to play with it...."
does anyone else ever feel overwhelmed and have trouble deciding which tech is the best and which to devote time to mastering? I know it depends on the developer and the specific project, but for someone relatively new to web tech in general how should I determine which to pursue?
Personally, I prefer to give new technology some time to mature before using it on anything important (and, as result, becoming competent with it), but I do try to look into new stuff just to see the ideas and approaches behind it.
For example, when Rails was new, I built a small personal project with it (http://notifyr.com/). It was a pain to deploy and I wouldn't use it on a production site (not that it couldn't be done, I just didn't want to deal with it. We're talking pre-Mongrel), but understanding concepts like MVC or CoC changed the way I was coding PHP profoundly, and made it easier to get competent with Rails once it was more mature.
(There is an exception, though: Some people make a living following tech hype. When a new technology starts getting mentioned in places like Wired or the NY Times, there's bound to be an unmet demand for coders who can use it. This can be pretty lucrative, but OTOH working with people who get their tech perception from these sources can be, er, interesting)
As for knowing stuff like CSS, JQuery, Prototype etc, I treat it like foreign language - you need to know enough to get around, perhaps express simple ideas or read the newspaper if you stay for a while. But you rarely need to know it at a Shakespeare level.
I think that waiting on a technology to mature is the right way to go in general. One of the challenges I have faced is that since I am just learning about a lot of web tech there is already an enormous amount of mature proven techs out there and deciding how to filter them can be overwhelming at times.
I think I will continue to really focus on the things that I am comfortable with and read about and slowly investigate the mass of other things available out there. Thanks for the suggestion/info
I've been interested in learning Seaside for some time, but the one time I downloaded and looked at Squeak, I couldn't make heads or tails of it. I know I should probably have made more effort to sit down and plough through documentation in detail, but... well, it's hypocritical for an Emacs user to say so, but the whole thing looked incredibly dated, alien, and unattractive.
For the Smalltalk and Seaside experts here: is there a Smalltalk environment which supports Seaside, (ideally) runs on a Mac and doesn't make me learn a whole new set of UI conventions, keyboard shortcuts, and so on? (I'll accept a Windows or Unix environment I can run in a VM.) It does not have to be free or open-source, but must have a free trial version I can play with.
I actually have a fair bit of experience with Squeak from college, but most of that experience tells me to stay as far away as possible. So I second this question: Anyone use Seaside on a decent Smalltalk environment?
I agree that it's very cool to transform your display code using macros, but it's a non-starter on many projects, because you can't farm out the HTML/CSS work to a designer.
You shouldn't farm out markup! HTML generation has nothing to do with layout design or anything visual. You generate/write clean and semantically correct markup and you leave out sufficient hooks in there for any designer to plug-in the desired CSS and graphics.
But there are many advantages to this way of having the html as smalltalk code.
You can use the same refactoring tools you use on code to refactor your html. You use the same abstraction and composition mechanisms to structure your html.
You use the same control structures for you html than for your code (which are very clear in smalltalk).
You can put some html in a method and reuse it in many places, it's also easy for easier to create your own components or tags in seaside than it is in other web component frameworks I have used.
My biggest complaint with Seaside, admittedly informed by little personal experience, is that it resists scaling horizontally. Continuations are server state. Unless you go to lengths to freeze this state into a DB repeatedly, your web app becomes dependent on the user connecting to the same server over and over again, confounding traditional load-balancing and scaling schemes. Vertical scaling is at the end of its usefulness these days; the future is in horizontal scaling and to my eyes, it's just not what Seaside is good at.
Form verification always happens first on the client (to avoid a server roundtrip), and only if the user doesn't have JS enabled does it hit the server. When presented with that problem, not having continuations on the server isn't nearly as much pain as switching between languages to write the same verification code twice.
This isn't to say that using continuations for such a purpose isn't snazzy, it's just that, among all the crap you have to do to have form validation, that isn't big, in the total scheme of things.
Are there any really major uses of continuations? I remember hearing that Viaweb used a continuation-based thing to do color-picking and take you back to the same page, but nowadays that'd be done with Javascript popping a window up.
(This comment box's continuation expired. That's a pretty unhelpful application of continuations.)
I agree that the continuation example is weak.
It is also generally accepted in the seaside community that continuations are becoming less useful now that ajax like solutions are widespread.
In fact, continuations are more of an add-on in the upcoming Seaside 2.9.
But even without continuations, Seaside is very different and useful for building web applications.
[Edit: the person I was reponding to asked a question. I put my heart into an answer, mostly to clear my head. Then he deleted his question and now I look like a douche.]
"Wrote" my own over the last few days, but was told by fellow CL'ers it's already been done.
What I did was generate the database tables, the html form rendering code (each class as a form), the server side function to validate the form input along with the client-side input validating javascript. That is:
1) A CLSQL Object<-->RDBMS ORM thinggie. The class definition defines a table in the database (transparently), and each class instansiation creates a database record. You use (find-object :class 'user :id objec-id) to get it back; the code takes care of mapping a SQL select result-set to a single USER object or a list of objects.
2) It automatically generates DISPLAY-USER method for each class, which generates a semantically sane HTML form. For has id="user_class" and class="defview". You can customize the "rendering" of each class by customizing the unique element ID, or the whole set of generated views by customizing the CSS class.
3) It automatically generates the viewing page example.com/class-name, and it takes arguments as example.com/class-name/object-id. If not object ID is supplied you get an object creation form where all the editable slots are rendered.
4) It automatically generates example.com/class-name/validate, which is a server side script which you can use to validate the input of /class-name the creation method.
--
I have been on this fucker for the last 3 days and today I reverse engineered a whole site from a database of 34 tables. In ONE day. Took me two days to write the macro to do this, but I did it, and it's not pretty.
So far it jus supported html input types text and password, and textarea. I added a new "widget" called :label, which is input text with readonly="true".
My Ajax-fu is still weak and i am sick of this hack of mine already. Specially since someone told me there established tools that do this. UnCommonWeb and Lisp on Lines.
None. For me it's static site generation where it makes sense (cron jobs scale beautifully), sometimes Sinatra, and otherwise, Rails.
They all work fabulously and I can't imagine why I'd spend time trying to change tools, when I can get better at designing software and business processes.
To me Cappuccino presents an option that I've never had before: build rich web applications without having to deal with HTML and CSS. That's incredibly attractive and reason enough to change tools.
Also, since its a completely client-side framework, it can still work together with server-side frameworks like Sinatra and Rails. That means I haven't lost the time I spent learning Ruby.
You could have also used GWT. The few Cappuccino apps I have seen are more attractive, but that might just be because GWT apps tend to be written by Java people and Cappuccino apps by Mac people. Hate to make a gross generalization like that, but Java apps with UIs rarely look good.
That's a fair point, but let me ask you: if you learned to write webapps Struts running on WebLogic back in 2000, would you still be using it today? By some measures, they also "work fabulously."
"Works" is not the same as "works fabulously." Import statements and public main void() are not, in my opinion, "fabulous" in any way -- except possibly "fabulously bad."
I started with BASIC. I learned PERL and did some CGI stuff with it. Then I learned PHP. I used PHP for a long time, and would rate myself as expert level, especially based on writing good solid OOP code and using good OOP principles. Now, I was happy with what I could do with it... until I wasn't. It worked, but not fabulously.
Then I saw some Rails controller code, my jaw dropped, and I knew I had to learn it. My growth as a PHP dev had been, in retrospect, largely about mitigating the crappiness of PHP. Ruby is a different ballgame altogether.
I haven't had that experience with anything else since. Probably some day it will happen. But til then, the only complaint I've possibly got against Ruby/Rails/Sinatra is that deployment is not the easiest thing... and that's an ancillary problem I rarely have to deal with.
Most of the other things are new for the sake of being new.
I looked into Seaside over 2 years ago. I find it cumbersome, and I asked a question at a Seaside talk, similar to one of the other commentors here, about the templating -- which has to be done that way for the object/state serializations -- and Avi Bryant was a dick to me, to boot.
I'm sure it works great for what he's doing, but it doesn't appeal to me. I don't need or want to write revolutionary data transformation software. I want to write the best damn webapps for "boring, simple" problems that everyone else thinks are solved -- that have yet, in my mind, to ever be given a thoughtful, amazing UI.
So Ruby and Rails are practically custom-made for me -- and, as I said, they work fabulously.
does anyone else ever feel overwhelmed and have trouble deciding which tech is the best and which to devote time to mastering? I know it depends on the developer and the specific project, but for someone relatively new to web tech in general how should I determine which to pursue?