As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I finished watching Douglas Crockford's excellent series on Javascript, and in the final episode (so far), loopage he lays out why Node.js is a near perfect solution for server side code.
He talks about keeping state, not in the database, but in closures running in Node.js, he also states that templating systems (like JSP, PHP, and ASP) are a poor abstraction for more complicated Web Applications and that node.js provides a solution to this.
And I am ready to buy in, but I can't find any examples of Web Applications using this pattern, or any books or tutorials about how to go about doing this. I am not talking about a simple application, but something that would use the patterns that Crockford spoke of in his talk. Anyone know where I can find some tutorials/examples of Web Applications written in Node.js (and yes I know about Geddy and ExpressJs, but they don't seem to follow the radically different patterns that Crockford was speaking of, and were more like getting a Railsy experience on Node.js).
[Note from 3 years in the future: It seems like Express, Geddy, Sails, Kraken et all are re-implementations of the Rails/Symfony/Spring frameworks from Ruby/PHP/Java. Whereas things like Hoodie and Meteor are attempts at a whole new paradigm. KOA looks interesting, but is a ways away from being usable, but looks like it is building on the strengths of javascript with the history of MVC applications of the past. 3 years on and it is still exciting times for Nodejs, even if it is no longer the new hotness. At least there are a lot of real world examples of Node in use now...
I would suggest you check out the various tutorials that are coming out lately. My current fav is:
http://nodetuts.com/
Hope this helps.
The Node Knockout competition wrapped up recently, and many of the submissions are available on github. The competition site doesn't appear to be working right now, but I'm sure you could Google up a few entries to check out.
DailyJS has a good tutorial (long series of 24 posts) that walks you through all the aspects of building a notepad app (including all the possible extras).
Heres an overview of the tutorial: http://dailyjs.com/2010/11/01/node-tutorial/
And heres a link to all the posts: http://dailyjs.com/tags.html#nodepad
Update
Dav Glass from Yahoo has given a talk at YuiConf2010 in November which is now available in Video from.
He shows to great extend how one can use YUI3 to render out widgets on the server side an make them work with GET requests when JS is disabled, or just make them work normally when it's active.
He also shows examples of how to use server side DOM to apply style sheets before rendering and other cool stuff.
The demos can be found on his GitHub Account.
The part that's missing IMO to make this really awesome, is some kind of underlying storage of the widget state. So that one can visit the page without JavaScript and everything works as expected, then they turn JS on and now the widget have the same state as before but work without page reloading, then throw in some saving to the server + WebSockets to sync between multiple open browser.... and the next generation of unobtrusive and gracefully degrading ARIA's is born.
Original Answer
Well go ahead and built it yourself then.
Seriously, 90% of all WebApps out there work fine with a REST approach, of course you could do magical things like superior user tracking, tracking of downloads in real time, checking which parts of videos are being watched etc.
One problem is scalability, as soon as you have more then 1 Node process, many (but not all) of the benefits of having the data stored between requests go away, so you have to make sure that clients always hit the same process. And even then, bigger things will yet again need a database layer.
Node.js isn't the solution to everything, I'm sure people will build really great stuff in the future, but that needs some time, right now many are just porting stuff over to Node to get things going.
What (IMHO) makes Node.js so great, is the fact that it streamlines the Development process, you have to write less code, it works perfectly with JSON, you loose all that context switching.
I mainly did gaming experiments so far, but I can for sure say that there will be many cool multi player (or even MMO) things in the future, that use both HTML5 and Node.js.
Node.js is still gaining traction, it's not even near to the RoR Hype some years ago (just take a look at the Node.js tag here on SO, hardly 4-5 questions a day).
Rome (or RoR) wasn't built over night, and neither will Node.js be.
Node.js has all the potential it needs, but people are still trying things out, so I'd suggest you to join them :)
The closest thing is likely Dav Glass's experimental work using node.js, express and YUI3. Basically, he explains how YUI3 is used to render markup on the server side, then sent to the client where binding to event and data occurs. The beauty is YUI3 is used as-is on both the client and the server. Makes a lot of sense. The one big issue is there is not yet a production ready server-side DOM library.
screencast
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am programming since quite some years now.
Until now I was mainly focused on writing "normal" applications which run inside a console or with a GUI, sometimes also applications which interact with hardware components such as sensors / actors / ...
During this time I got to know a lot of cool programming principles and tools such as object orientation, modularization, unit-testing, test-driven-development, desing-patterns, code-analysis, ..
Also I have some first experience with hosting a wordpress blog, running static web-sites on a nginx webserver, and writing some small php-forms. But I feel like there is still too much magic in all these web-development topics. And I would like to fill this gap and learn a bit more about all these connected scripting / programming languages and technologies. (Because I hate, when I don't understand how things are working :D :D )
I started with some online "Web-development bootcamp" course at udemy to get a rough overview. This took quite some days now and I think HTML, CSS and Javascript for DOM manipulation / animations are clear to me now. Also I heard a lot about NodeJS and all it's derivate languages and databases like Mongo-DB. But still I feel like there is a lot of things unclear to me.
To get to a better understanding I wanted to development some small web-application. Nothing very special, just some website where you have to login to, are able to generate some data and this data is then persisted into a database and once you login again you are able to see the data again.
I first started with developing some classes in Javascript to represent the data in the browser while you are logged in. But I very soon realized that the Javascript which can run inside the browser is very limited and already for unit-testing and modularization into separate files that include each other I actually needed to do some crazy work-arounds or use other server-side languages like nodejs / php / ... .
After some time coding I decided to take one step back, trying to understand the basic design patterns of web-applications and not running for a long time into the wrong direction.
My questions are:
Is there some typical way to go / best practice while developing web-applications?
What are the typical key players? I know there is the difference between front-end, back-end and databases.
But are there some do's and don't's that good WebDev's follow?
For example:
which code is usually written in back-end / server-side languages?
What is usually done in the front-end? (Only desing and animations?)
Do I have to move all business logic into the back-end, also for security reasons or is this maybe also a bad idea because of peformance reasons?
What programming languages are more or less dead and not to be used in the future?
What things are typically reused from frameworks, for example authentication and session handling?
Also I felt like some things I know from other programming languages are not so easy in languages like javascript / nodejs. I am willing to spend time and effort into learning all these things but I would also like to keep the quality standards that I know from C++ /
Python. On the other side I also wondered if these patterns that I have in my head are maybe just boundaries that are completely useless in modern web-development? (e.g. typing, object orientation, modularization / splitting the code to be very reusable )
What do you think am I on the wrong track here, or do I maybe simply use the wrong languages?
I hope the long text is not knocking everyone down / keeping everyone from answering me :o
I would really appreciate your help and guidance to understand everything a bit better and to not repeat the things already a lot of others have done wrong ;)
BR, mezorian
First off, most of the questions are very opionated (at least the answers are) and your question will probably be closed for that reason. So I will post my answer before completing it and expand on it after.
First off a good roadmap to become a web developer. I like it mainly because it shows the crazyness the web development world has come to (don't be shocked!): https://levelup.gitconnected.com/the-2020-web-developer-roadmap-76503ddfb327
Trying to answer some of your question (answers are my opinion):
Is there some typical way to go / best practice while developing web-applications?
I'm tempted to say there are as many ways to do web development as there are web-developers in the world, but that might be a bit exaggerated. If you want some guidelines, I'd pick one of the major web frameworks and learn the way they do web development. With web frameworks I mean all kinds of frameworks starting with JS-frameworks all the way to static site generators, etc. They all have their ecosystem and their own rules.
What are the typical key players? I know there is the difference between front-end, back-end and databases.
(personal opinion) I work with Go in the backend. I love it because it brings back some simplicity in the crazy world of choices being a web developer. Since you know C, Go will probably be easy for you. It has static typing, structs, etc, but no need to manually manage your memory. It is also much faster than most other backend languages used in web development (Python, NodeJS, PHP, Ruby, etc).
In the front-end I have used native JS, jQuery, React, Vue, etc. I'm still waiting for something that makes things easy again. Flutter seems to be something that has a good approach, but is not really a web front framework (yet). (Don't do public websites with Flutter! They are not indexable.) We'll see where it goes.
Databases I will not go into here as that is another huge topic. Let's just say that I'm more a fan of using multiple databases for their specific strengths rather than a big one that is supposed to be good at anything.
which code is usually written in back-end / server-side languages?
Even this depends largely on your choices (framework and preference). One thing for sure has to be in the backend and that is security related stuff. Anything you put in frontend code is visible to an experienced user.
Apart from that there are some ecosystems where you don't write any backend code but talk to a (cloud) service that is basically like a database with a web endpoint on top with secured login. (for example https://firebase.google.com/.) Here the security related stuff is baked into the service.
If you do both, keeping business logic in the backend is probably a good idea. If the frontend calculates something (for quick response), the backend should double check that (e.g. calculating the total in a cart). But this is too general. There can always be use cases where some business logic needs to be implemented in the front-end.
Do I have to move all business logic into the back-end, also for security reasons or is this maybe also a bad idea because of performance reasons?
Performance can be a problem, but mostly because the roundtrip time to the server and back. If you do that for every tiny information, the UI will become sluggish. You might want to think about doing e.g. a calculation client-side.
JS-Frameworks like React, Vue don't request html from the backend, but data and build the html based on that data client-side. I'd use them if I have a very data driven website / webapp, especially if it is user-dependent. Transferring only the data and building the html for every site from it in the browser based on user settings and data, saves a lot of roundtrips.
If you are worried about server performance: For the server to hit its limit, you'd need heavy usage of your website for that to become an issue (at least with Go). If you get there you can still use horizontal scaling (multiple instances of you server) to solve that. Unless you are working for a large company with millions of users daily, I'd not worry about scaling for now.
What programming languages are more or less dead and not to be used in the future?
Warning: Very opionated!
I'd say PHP is dead. Many headhunters I've spoken with agree with me. Companies are desperately looking for PHP developers, because many developers are moving on from PHP to something "cooler". You'll definitely find a job with PHP, but might not be so happy with your job. For me it is also a sign of how modern a company really is (if PHP is not it's main backend language (any more)).
Python currently has a big boom. Mostly because of AI development. I'm not sure if that boom is also in the web development, but I'd say not. I used Python before Go (5+ years ago) and before that PHP (8+ years ago). I rarely get Python web developer job offers (at least compared to PHP and Go).
Go is the language of the cloud. It is perfect for concurrent programming which is an essential part in web development (every http call should be handled concurrently). It is fast and light weight and doesn't need anything installed on the server to run (compiles to a single binary without dependencies).
NodeJS: Haven't used. I'm not a fan of Javascript (but it was (and kind of still is) the only option in the browser), so I never liked the idea of using it also in the backend.
TypeScript: might be an alternative to JavaScript (thinking of frontend here) if you like a more structured language.
It sounded like you want to build a user baser web app with data being managed by each user. This is what I would (probably) do in that case:
Backend in Go
Go serves static files (start html, css, js, images, etc.)
Go server has an api endpoint that serves data (e.g. REST style)
Vue (or React) in the frontend
Vue requests data from the api to build the user-specific content
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have been trying to create a mongodb server which will receive post requests and insert or read from a mongodb server and reply back. I have started with node.js. However while I was reading stuff, I have been realizing, people actually hate node.js. Many people are crossing to GO. So I am all confused now.
I have chosen node.js because of the natural json compatibility of javascript. However after all the things I have read, node.js sounds like a waste of time.
Could someone help me clarify my confusion ?
Thank you.
Edit : People refer to the problem of callback hell, and lowering performance of node.js once the business logic starts to be more complex than simple loops.
People refer to the problem of callback hell
This has never been an issue for me. You can use whatever structure you want in your code. Any promise library may be helpful if you find that you really need 1,000 nested callbacks, but this is rare in most circumstances.
lowering performance of node.js once the business logic starts to be more complex than simple loops
Rarely is this a problem. Most applications are IO-bound. If yours isn't, you have a couple options. One is not to use Node.js. Another is to compile a native extension for the specific part that's dragging you down (since you'll be writing native code to solve this problem anyway) and call it from the rest of your Node.js application. That way you get most of the performance of your native code but still get the flexibility of working in JavaScript.
Since you linked to that Reddit post, I'll address some of the comments there.
Javascript is very fast. Yes this is true, V8 is very fast... however, only if you are benchmarking a simple benchmark. As soon as you start adding in complex application logic all that performance goes out the door because the virtual machine has a very difficult time correctly inferring the type and thus not being able to optimize. But if your application consists of a tight loop, it will be fast.. so its got that going for it :D
It's all relative. No doubt that weakly typed and interpreted anything is slower. It's a trade-off that you have to decide makes sense for what you're doing. Personally, it's far cheaper for me to fire up another box to handle the load than it is to rewrite all of the helpful modules and frameworks I use in Go. Maybe that's not the case for you, so you get to decide.
In my 3 years of full time node.js development, I have honestly only had ONE occasion where I used the same 4 lines of code both in the server and in the client.
This is generally true. I don't understand why shared client/server code is some sort of selling point for Node.js, as it isn't for most applications. I had one case where several classes I wrote for an RPC layer ran on both the server and the client. One thing I will say though is that there are a ton of NPM packages that run in both so if you get used to using a nice package on one, it will often times work on the other.
Ohh and did I mention Node.js isn't really all JavaScript? A good portion of the pakcages on NPM are also written in Coffeescript. Hope you don't mind learning another language to deal with a package you depend on. So much for using the same language for both server and client!
You don't have to learn Coffeescript to use an NPM package written in Coffeescript. Coffeescript compiles to JavaScript, and are used in your code the same way any other package is. Also, those same Coffeescript packages do run just fine in the browser since it all builds to JavaScript.
With Go you get type safety. This CANNOT be overstated.. except to maybe ruby-ists(jk jk! don't shoot me).
It's up to you to decide if this matters for your use case.
The one benefit you have with Node.js over Go is the massive number of packages available on NPM. But most of them are useless abandoned junk. So, even that is questionable.
Don't use abandoned junk, just like you wouldn't with any packages on any platform. It's very easy to see what's abandoned junk. NPM calls out what's been updated and when, whether or not its dependencies are up to date, and how many people are using that package. There are definitely a massive number of useful packages available for Node.js, just like they are for most popular platforms.
Testing: Lets just say that in Node.js/Javascript you would have to write tests that check the type of a variable. tsk tsk tsk... This is the only way to properly test JS and make sure nothing crazy is going on.
That's not really accurate, and I'm really curious what's going on in this person's application where this is necessary.
I wanted to know if anyone has been using AirBnB Rendr and is it stable and ok to use in commercial projects or is it still changing a lot?
I'm developing a website which can run both client and server based, this mean I need to be able to render pages and widgets server and client based.
The server is running Node.js, dust.js and has custom server based code to render the pages and widgets on the server side. I need to pick how to handle it on the client side.
Naturally I want to try and not repeat code, but obviously the client is different I can:
Keep my current page based server rendering and develop custom
client side code.
Use backbone.js on client side and keep my server based code the
same.
Use AirBnB rendr that is based on Node.js and backbone to use the
same code on client and o server. AirBnB Rendr Library
I like the 3rd idea very much, but I'm looking for some input from you guys.
Has anyone used it? any experience with it in terms of stability and/or how often their api changes etc?
I've just started playing around with Rendr. If I ignore the learning curve and oboarding friction, I like it a lot and I plan to write my next large production app using Rendr.
Unfortunately, as bababa listed above, the documentation needs a lot of work. There is an explanation of how Rendr works in its README and the example app's README but beyond that you'll need to source dive in order to figure out how the gears are turning. Currently, there is no forum for questions (other than stack overflow :D) and I've had a hard time figuring out its idioms on my own.
Despite all the struggles, I finally see the light and I'm starting to understand why Rendr is so powerful.
tl;dr - If you're willing to source dive and figure out your own workflow, I would suggest using Rendr. Otherwise, I would recommend going old school by writing a traditional client app with a more mature library. (is it too early to say that? =X)
Well given AirBnb is a successful commercial enterprise, there's some validation that the library works well enough for them. This question is probably best answered by watching their github commit log for breaking changes. Given backbone is 1.0 and essentially stable at this point, rendr will probably quickly stabilize, but honestly your fear of instability is probably unjustified. I think rendr looks compelling and although my current project is using a very similar home-grown solution, I would consider using rendr in a future project or even porting our code to rendr. "Stability" per say is much less important to the web development community compared to other situations like packaged or embedded software.
I used (tried to use) and Rendr on a project and gave up. There are just to many limitations (currently) and the lack of documentation doesn't help. I ended up need to rewrite the source code to accomplish some things I would consider trivial with other frameworks, such as passing multiple collections to a view. It just wasn't possible (at the time I used it) and that was a deal breaker. Not being able to pass a collection of categories and results to a page was to much of a limitation.
I have no doubt it will eventually be ready for production use, but right now I would say unless you are an engineer at AirBnb and know how to hack the source then no, it's not ready.
If you really want to know if it will work for your needs, take a look at the issue list on github. That will give you a good idea where the projects at.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I work on studying the development of a medium web application intended for hotlines. So I've real time, concurent access, big datamodel and CTI constraints.
Originaly I'm a php and Java EE developper, but like many of us, I've read a lot of news about node.js and I tested it with small apps. The possibilities of node.js are awesome, but I felt that it's very difficult to only use this technology in a medium/big web app. Indeed frameworks like express are minimalistic compared to productive framework like symfony, play or ROR, etc. Moreover, the node.js ecosystem progresses very fast and might be difficult to maintain.
I'm not experienced enough in nodejs, so I want to know; is choosing only node.js to develop a medium/big business web app with some real time problematics crazy or not? Don't you think that coupling a productive framework with nodejs only for specific features (real time) is a better way ?
Thanks,
Regards
Eric
I'm working on a large real-time business web app that requires some real-time interaction and what we are doing is using django for just about everything, and handling the real-time stuff using the now.js library. Originally we planned on using node.js for everything, but to alleviate some time constraints, we decided it would be quicker to use django.
One thing we have noticed since we've started is that there are a lot of changes, and that some of these changes break what we've done. For the most part, keeping up with the changes hasn't really made it difficult to maintain, however it has made it difficult to follow tutorials and such.
I'm going to answer this quickly, before the question is closed for only being answerable via opinions, not facts.
So, I'm going to answer with my opinion ;)
I think node.js's focus currently is on building small things that respond very quickly. I sense a lot of pushback in the node community against "too complicated abstractions". (It's possible I'm misreading the community, but I don't think so).
To me, building a business app (example: some of my past Rails projects have been 10ish man years) I want an ORM abstraction layer, etc. I think you'd want this building even an app with more than a few man-months of effort in it.
Unless something changes (the node community runs into problems when their code bases grow too large, for example) I suspect the "place" for node.js in medium to big applications is for small hyper responsive things (websockets, retrieving data from external sources and doing small things with it), etc.... not for building an entire big business workflow app.
It's 2016. Recently I decided to go with Sails / Node instead of CakePHP. Today I decided to go back to CakePHP. Lucky enough, I just coded one small module ( kinda of indexing inside a db some filesystem content ). The amount of callbacks and promises It's just annoying to me. The simple task of getting a file's metadata, searching it on Postgres, creating the record only if it doesn't exists, take me more than 20 lines of code and I almost have to drink a bottle of Dramamine lol
This time I am highly determinated to maintain an extreme layer's separation. So my front-end is fully static html/js/css, coded in Angular. Postgres DB also don't require any changes. And CakePHP 3 is almost factory's ready to easily serve json/xml.
Also there's a possibility of me being somehow stupid... lol
I want to rewrite a complete community website in nodejs,express and
nowjs with mongodb. Its currently in php using the codeigniter
framework. It includes functionality such as your own profile page,
photoalbum, guestbook, internal messages, contacts and more. And im
going to add an im to it and some other things like a forum and so on.
Its a pretty big project.
I have to make a decision about which techniques to use in the
webapplication. So i did a little research and found, node, Expess and
nowjs.
Should i stick to finish the application in php( codeigniter ), mysql
and ajax, or can i do this in express, mongodb and nowjs?
Can anyone recommend this for use on a live production site? And if
so, are there any security issues one should know about? General
guidelines?
Help would be really appreciated so i can make up my mind and finish
the project
Regards
George
The problem with Nodejs being young is not that it's a half baked product or something but infact it's growing very fast and new developments are being done at breath taking place. So you need to keep up with them while developing.
Otherwise there are huge projects out there developed totally with node and express. Take a look at expressjs.com/applications to see what kind of commericial projects are built using it.
As far as security, sessions etc. are concerned. Unlike ASP/PHP , you don't get most of the features out of the box. You'll need to either write them yourselves or using open source frameworks. Both ways you and only you have to ensure that your application has all bases covered. With flexibility, comes complexity.
It should be noted that Nodejs is optimum for real time I/O. If you think this is something which is required at your end then I highly recommend to go for it.
What you describe does sound like a big project.
If you have the time to spare, I would suggest picking a small portion of it that deals with managing secure sessions (e.g. the profile page). Implement that in Express to get a sense of how it compares to the existing PHP. If you like it, keep going.
Particularly when security is at stake, always try to use existing components when they are available. Node's minimalism makes it tempting to 'roll your own,' but it's very easy to make a security mistake with anything less than expert knowledge.