Hot answers tagged server-side
52
Speaking from experience: The downside is that you rely on the Rails framework a bit too much. This is a great and wonderful thing if you are only ever writing simple, greenfield CRUD apps that fall squarely into the Rails "sweet spot"; your productivity will skyrocket. However, the moment you have to do something outside that sweet spot - interact with an ...
28
For your first server-side language, I feel like there can be a couple problems with RoR:
You're not just learning a language, you're learning a framework. I would definitely take some time to play around with plain old ruby before jumping into rails.
Since it is a framework, and an 'opinionated' one at that, I feel like it would give you a very limited ...
19
Background
Web development is all about communication. In this case, communication between 2 parties, over the HTTP protocol:
The Server - This party is responsible for serving pages.
The Client - This party requests pages from the Server, and displays them to the user. On most cases, the client is a web browser.
The User - The user uses the Client in ...
13
Business logic almost always has to run on a server you control, for security reasons. If by "server" you mean "web server", then I agree, it doesn't need to have almost any business logic. But you almost always need an application server with the business logic, whether that's inside a database or a web server or is separate and called by the web server. ...
12
If this is your first server-side language, it's as good as any. The thing to do is focus on one, and after you feel you've mastered it, explore others and deduce your own conclusions.
I work with RoR and ASP.NET on a daily basis, but strangely enough, I prefer the ASP.NET world, but that has more to do with personal philosophy than it has to do with the ...
12
I've tried to learn RoR several times and my biggest problem is always trying to get the packages to work correctly and the documentation. The problem with the documentation is that it always seems to be out of date (or very basic). I got the basics from the site but beyond that everything seemed so dated (even the book I bought and ended up returning). ...
12
Back in the 'early days' of the web, people hacked web servers using non-standard APIs in whatever language they had handy. Back then, the NCSA HTTPd was the defacto standard, so you mostly used C, I believe. Certainly, each HTTP server product had it's own C API (Netscape had NSAPI, Microsoft ISAPI, etc).
To alleviate this, in 1993 the CGI standard (Common ...
12
Presumably the perceived benefit are:
you only need to hire developers that know language x rather than x + y (this is probably not really a good idea though if they only know one language)
it is easier to move developers between server and client development (this can be quite a good thing).
i.e. it makes resource management easier for project ...
10
There are two major issues.
The first is easy--you usually don't know what sort of resources are available on the client side. If it requires 1.5GB to process something, can you really push that onto an unknown client browser (IE, Safari, Opera, Firefox, etc.) on an unknown client platform? Will the client appreciate his system dogging when you ...
9
What's wrong with plain old garden variety FTP (File Transfer Protocol), or even TFTP (Trivial File Transfer Protocol)?
Granted, they're older than your father's memory of his first kiss, but they still work.
Now, both FTP and TFTP want the file to be on the server before they serve it to download clients. If what you want is to stream the file from A ...
8
A couple of advantages:
Each process has a separate address space. If you run on a 32-bit OS, that can be an advantage because you can load up the server with lots of RAM and even though each process can only access 4GB each, if you've got multiple processes, then they can use up however much RAM you have available. If you're writing for 64-bit (and I ...
8
A few possible reasons:
The JavaScript library for this already existed, so it required little development time to deploy, as no major changes were required in their code base.
It saves processing time on the server from not having to generate the images.
It saves bandwidth, as the LaTeX code is much more compact than the rendered images.
It avoids ...
8
The big reason why css is seldom generated dynamically (this is also true for javascript) is because they are good candidates for caching. CSS is a very flexible way to style your pages, with the right combination of classes, you can get all of the different parts of all of your different pages styled according to all sorts of cues all Without having to ...
8
Your understanding is correct, if you're from the past. You're pretty much describe as it looked like in 1990s.
Yes, many languages can be executed directly by a web server plugin. Right on for PHP, mod_php for Apache is still the most popular way to host it. However, high-traffic sites use more modern approach, using web server only as a proxy for FastCGI ...
7
I consider myself a "server side" developer.
Despite being on the "back side" of web development, I think it's extremely helpful to know HTML and CSS fundamentals. I work on typical "web content management systems" (WCMS), such as Drupal, Day CQ, and Liferay, and most business requirements and requests revolve around changing the look and the feel.
...
7
Generally speaking, the language doesn't have a concept of multiple servers. It works in isolation on its server. The fact there are multiple instances is not generally considered at the language level.
It is a bit like checkout staff in a super market, they each do their job. They don't need to consider if there are other staff or interact with them.
The ...
7
The line between compiled and interpreted is a hazy one at best these days. Every one of the languages you listed, in both lists, is both compiled and interpreted. That is, they are compiled into byte code and then executed by a runtime engine/vm. JSP and C# may be JIT compiled at runtime, but that only makes the line even hazier. (In PHP's case, you may ...
7
From top of my head:
Use of webservices instead of direct access to DB from client.
REST instead of SOAP. SOAP seems to be too heavy-weight for mobile communication with backend. REST using JSON is much simpler to set up and consume. Especially if you use different technologies on client and server.
Focus on multiple views for webpages. One for desktop and ...
6
I believe your assumption is wrong: in my last project, the application was using server-generated CSS loaded by ajax (because, depending on the location of the map you were looking at, the page was branded with completely different styles).
However, usage cases where retrieving extra CSS by ajax would solve the problem are quite rare, this may be why you ...
6
Technologies
RESTful API using JSON as serialization
— Same API is used by native apps, hybrid apps and mobile web apps. Even in the former case client side templates are often used (see excellent example in "Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates")
Lightweight, asynchronous (event driven) servers — no more ...
6
In layman'w words:
Here I will talk only about web programming.
Client side programming has mostly to do with the user interface, which which the user interacts. In web developing it's the browser, in the user's machine, that runs this code, and is mainly done in javascript, flash, etc. This code must run in a variety of browsers.
It's main tasks are:
...
6
It doesn't really matter, neither stack is really better than the other especially at this level. Your best bet is to install whatever is most used in your university's server infrastructure, especially if this is something that is intended to be available and offered to students after you complete your class.
5
With me, the biggest problem with I learn my first X (in your case, X is a server-side web language/framework), it's that as soon as I see other problems, I immediately want to start applying X, even when it might not be the best option. I've gotten better at this, but it's still a strong tendency.
Ruby on Rails is a good choice to start with - there is a ...
5
As someone who learned Rails recently (as a hobby - never used it for commercial grade development) and had already worked in JEE and ASP.NET, Wayne M's answer rang very true.
Anyway, there is a subtle side to this which noone has mentioned yet, but which bothered me a bit with Rails - the strong reliance on convention over configuration.
Essentially, if ...
5
Actually, there are use cases for dynamic CSS. I've worked with three different kinds:
Less — Less CSS is basically a CSS language extension that adds "dynamic behavior such as variables, mixins, operations and functions." It also allows "nested rules", which is very convenient. I have used Less mainly to make CSS writing less verbose by ...
5
Designing the client side first with mocking can give you a strong advantage in knowing your website's functionality. You can keep redesigning with minimal waste until you reach a good workflow for your product. However, you should keep a rough sketch of server side requirements for each bit of functionality you'll need from the design so that you don't ...
5
The first server-side programs were probably extensions to the webservers themselves, which AFAIK were all written in C.
But in the discussions that led to the CGI standard you can already see that the API between webserver and server-side code was implicitly assumed to be language agnostic (based on stdin/stdout), and people talked of "scripts", which is a ...
5
It depends on how many transactions you expect. In general, it seems that if you only want the sum and count then transferring all the details is inefficient.
However, if the number of transactions is very small then the overhead of multiple requests might be more inefficient.
Personally, I like the second option, but I would add a third REST endpoint ...
4
If you're not using Firefox and firebug already, you should do so. Firebug's debugger is just full of awesomeness (not that Chrome's isn't, they're largely the same), but I tend to go with Firefox because of OS projects such as mozrepl, which allows you to script Firefox rather than using browser-spawning automated test suites such as Selenium.
So, for ...
4
My advice would be to have a clear picture of the project that you want to complete and then just start trying to build it. As you run into problems you will eventually grab all the right tools. This approach is good because you are making decisions based off of succinct problems.
Another thing to do is buy books. Internet tutorials don't cut it in my ...
Only top voted, non community-wiki answers of a minimum length are eligible
