8 ms·

A new development era

DasIch 14y ago
Interestingly enough we still prefer to use a Twitter client instead of twitter.com, in fact those clients are what made Twitter big or at least so a lot of people claim. Why would that be any different for other things? Why should that change in the foreseeable future?
- girvo 14y ago
  Actually, we might, but everyone else didn't. IIRC something like 90% of traffic on Twitter was directly on the site, not through a client.
  - tl 14y ago
    I would argue that Twitter is bad example. I prefer the Twitter site over the apps. Reeder vs. Google Reader is a different story.
girvo 14y ago
That which was old, is new again. I find the cyclic nature to be interesting, and possibly a response to the increasing nature of computer power. Originally, the mainframe was where the power was. Then the PC was enough to do a lot of the work the mainframe was doing. Then the nature of delivering experiences to those around the world necessitated a shift back to the server for a lot of tasks (try running Google or Facebook locally), with a shift to making the Gui thin... Performance in the browser was woeful. Now, the performance of the browser across our increasing amount of disparate devices is nearly adequate enough for thick guis once more, with the bonus of it working across a multitude of OSes (Windows, Linux, Mac, iOS, Android, Windows Phone, Chrome OS, etc.) It truly is interesting to watch and play in :)
- PommeDeTerre 14y ago
  This is more a case of "old is still old", I think. We've been hearing about how web apps or browser-based apps will replace desktop apps for many years now, yet it never happens. I can still remember all of the Java applet, ActiveX control and DHTML hype of the late 1990s. It died out when it was proven to be nonsense. Desktop apps continued to thrive. Then it built up again a few years later, during the middle of the last decade, when AJAX and jQuery became all the rage. These offerings were marginally better than what we saw in the DHTML era, but still lacking. The only traction they gained was at the very low end. Most serious users still preferred to use real desktop applications. Now it's a few years later, and there's been a lot of HTML5 hype. Yet the browser-based apps are still no closer to replacing desktop apps. Gmail, for instance, has been around for almost a decade, but a great many people much prefer a real mail client. We also haven't seen much traction when it comes to modern online office suites, and other web-based alternatives to more traditional desktop apps. Native desktop or mobile apps are going to be around for a long time. I question whether it is even possible for any browser-based app to compete. In order to do so effectively, it would be necessary to eliminate the browser itself, as it is the browser and its related technologies which provide the poor experience we get from many web apps. It just looks like a complete no-win situation for web apps, aside from perhaps at the very low end.
  - aidos 14y ago
    I think things are still moving in the direction we expected. Java applets and ActiveX were horrible experiences, that's why they didn't survive, not because desktop apps are fundamentally better. And DHTML is just a different name for webpages that use Javascript - that was doing pretty well last time I checked. Google Docs and Gmail replaced traditional desktop apps for me a long time ago. Sure, not everyone has moved, and it will certainly be a long time before the enterprise sector throws out their desktop apps, but in the consumer space many people just use web based mail clients. According to year old Litmus stats [0] 31% of email was webmail (and how much of the outlook traffic is from office workers?). Xero have done an amazing job of pushing into a space dominated by and old desktop app (Sage). People are moving, slowly but surely. I know that desktop apps are not going to vanish soon but it's not fair to say that web apps haven't gained much traction. Any issues you're seeing in the experience at the moment will be smoothed out. There's mind boggling amounts of resource being poured into making web apps faster (V8 etc) and the emerging frameworks for rich interfaces (Angular etc) are going to enable a whole new breed of web app. [0] http://litmus.com/blog/email-client-market-share-stats-infographic-june-2012/email-client-market-share-june-2012 http://litmus.com/blog/email-client-market-share-stats-infog...
onemorepassword 14y ago
Although there is definitely a shift going on, I suspect it won't be half as radical as people like the author tend to evangelize. This model may be a big shift for a simple web app, but for larger applications with lots of business logic it will barely make a difference. The "big web app full of things" will still be there, only with a few things less, and it will still be built with tons of tools, not just a micro framework. The future of web development won't be that different. There will just be more of it, but that's pretty much what has been happening since the 90's. There's enough exiting new stuff happening without going overboard and announcing it as a new era or a major paradigm shift. Maybe I'm getting old, but I find it tiresome.
elicox 14y ago
The people live in a bubble, they don't considerer that there is others kind of software that required more (so much more) business logic, that only an insane man can try to solve with js.
- steverb 14y ago
  The problems that can be solved using js grow large with each passing year though. I wrote a video recording and exporting app for a client this year using web technolgies (html + js + node). I couldn't have imagined that being possible 10 years ago.
  - rjbond3rd 14y ago
    Very cool. So did your app somehow manage to do video capture on the client hardware, or did you access something equivalent to a webcam?
    - steverb 14y ago
      In this case, it captures and streams from the computer it is running on via a video capture card. The application is for archiving audio and video from an external box that it monitors. The nice thing about doing it that way, is that adding the capability to stream real-time from the external box that is being monitored is as easy as opening the ports to external access.
  - elicox 14y ago
    I am not talking about this. What I means it's when you have to deal with more complex interaction, between different systems, old technologies, ... What you say it's true, JS it's going to evolve in the next years until to convert in something totally different, you will see. Some people call that reinvent the wheel. I am not against JS at all, I just dont think every single problem can be resolve with that, sorry.
- blablabla123 14y ago
  Looking at MVC, a common recommendation is to put the business logic into the model. "Fat models, skinny controllers" IMHO the JS frontend should contain almost no business logic. Rather it should be handled either by "the" backend or if it is really that complex, by a separate web service. (Self-speaking that this service can be written in any language that makes sense.) (On the other hand, the success of node.js proves that medium sized applications can be written in pure JS.)
rsl7 14y ago
wait... this guy thinks the future is going to be simpler? when has that ever happened? However, I largely agree on the right side of the big vertical network line in his diagram, and I feel this has been obvious for years now. The left side, not so much. I think the reduction of web services to JSON type data will enable an explosion of client side diversity, and that is a good thing. Also there is nothing classic about "server-side" MVC : it is ridiculous and never made any sense.
- nonamegiven 14y ago
  "wait... this guy thinks the future is going to be simpler? when has that ever happened?" It happens constantly. It's such a strong urge that making things simpler itself has become simpler. I'm touching simpler right now. This linux distro (lubuntu, doesn't matter) took me much less than an hour to download and install, fully functional with no configuration by me. In fact it was fully functional before I installed it, because it was a live distro that connected to the internet with no configuration on my part. 15 years ago that would have required me to download a bunch of separate files, copy them to a stack of floppy disks, and keep a book by Matt Walsh open on my knees while I tried to figure out again how to make my computer talk to my modem and to the wider internet. I'll completely reinstall my OS on a whim, with confidence. I used to approach it with dread and a good night's sleep. I also don't adjust the choke on my car when I start it, and I have no idea how to safely crank the engine from the front of the car; actually, I can't find the place to put the crank handle in, and I can't find the crank. EDIT: s/router/modem/
  - chipsy 14y ago
    That's easier, not simpler. When part of the stack breaks you're even less likely to know how to fix it than 15 years ago. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
    - nonamegiven 14y ago
      The procedure that I use is simple, regardless of the underlying complexity that makes it simple. Eating is simple, even though the body is complex. I'm glad I don't have to explicitly operate my pancreas.
ecopoesis 14y ago
MVC isn't just a good idea for making development easier, it's also the natural resting state for most applications. In the future, well just be distributing the models, views and controllers across multiple machines and networks, just as was done on the past.
ghc 14y ago
> In fact, I think Python is becoming the secret weapon behind every good Javascript application ;) My recent experience says this is not true. Python is so widely used as a backend that it is in no kind of secret weapon - at least not in the way Lisp was a secret weapon for Paul Graham with Viaweb. Every startup I've dealt with recently is building their backend in Python, Ruby or Node. I think the real story here is that compiled languages are on a major downswing in use for startups that build web apps. I haven't run across a startup building their backend with .NET or Java in a couple of years, except for one payment application that built the business logic with C# and MS SQL Server (they still built their web API with RoR). Recently I tried to go back to compiled languages for a new web project. I really wanted to try something fun in Haskell that wasn't just data processing (what I normally use it for). I picked up Snap, Yesod and a few other libraries only to find that it was just too much of a pain. Dynamic languages remove so many little annoyances with web development that it's hard to justify going back to a compiled one when you could just cheaply spin up an extra VM or two to deal with the performance differential between dynamic and compiled languages. Maybe I'll try Go next...
- boothead 14y ago
  Interesting. I was the someone who wrote the snippet about my app becoming a zeromq => Websockets routing layer and I've been thinking that the correctness, speed and fluency doing anything stream related of haskell for this layer would be perfect. When you add in being able to share datatypes between the server and client via Fay it seems ideal!
  - Xurinos 14y ago
    Can you go into more detail about your architecture (a quick diagram of the connections between these components)? I am very interested -- my own dabblings have been leading me in this direction and firm belief, but I would love to learn from someone else's experience with it. Please feel free to email me if you prefer.
- dysoco 14y ago
  Well you have Go, D and Haskell: And Scala, Clojure, Erlang if you count VM languages.
calpaterson 14y ago
It's funny, this architecture he mentions of one-page-app clients on the frontend and microframework servers on the backend with Python is precisely the model I choose for a recent side project. What I learned: - Javascript requires a lot of architecture to be sustainable over even medium size apps (I stole N. Zaka's architecture) - Writing functional tests for Javascript is difficult. (Writing unit tests is easy) - Most web browsers are nearly there with everything you need for one-page-apps. IE8 is the only real problem, and I think my problems are soluble. - Python's single threaded nature requires that you make explicit effort to add offline jobs (I added a priority queue using redis) - Elasticsearch is actually quite complicated once your needs move out of the completely trivial - Most of the documentation for Elasticsearch assumes a working knowledge of Lucene (which I don't have). - Mongodb is really really easy to develop against - Getting a single page app to be sensibly indexed by Google is not easy. Here's the backend source: - https://github.com/calpaterson/recall https://github.com/calpaterson/recall And the frontend source: https://github.com/calpaterson/web-recall https://github.com/calpaterson/web-recall And the current deployed version is here: https://recall.calpaterson.com/about/ https://recall.calpaterson.com/about/ I'd love to answer any questions, I'm not as keen on one-page-apps now as I was when I started.
- wyuenho 14y ago
  Getting a single page app to be sensibly indexed by Google is not easy. I think this is the most important point when people are deciding whether they should move their entire frontend layer to the browser in their new projects, and frankly, a lot of guys pushing (or developing) for single-page webapps don't get that. While it is possible to have a mix of client-side routes/pushState/server-side generated template, it's actually non-trivial. So I really don't see a lot of cut and dry separation of layers anytime soon until Google can start indexing sites that fetches data after the HTML structure has arrived. Big full-stack webapp frameworks are here to stay, tho we might see more webapp frameworks that are great at doing API first to emerge.
- jseims 14y ago
  Do you have a link that elaborates on N. Zaka's architecture?
snambi 14y ago
Still Server will render the main page. Main page is " html + main content that user and search engine wants to see". Because the search engines need to index this page ( meaning the URL ), so the main content must be same, unless it is a private page. Also the browsers are designed to render html from the server. HTML5 brings in a lot of dynamic features, but the main feature is not going away.

Interestingly enough we still prefer to use a Twitter client instead of twitter.com, in fact those clients are what made Twitter big or at least so a lot of people claim. Why would that be any different for other things? Why should that change in the foreseeable future?

girvo 14y ago
Actually, we might, but everyone else didn't. IIRC something like 90% of traffic on Twitter was directly on the site, not through a client.
- tl 14y ago
  I would argue that Twitter is bad example. I prefer the Twitter site over the apps. Reeder vs. Google Reader is a different story.

girvo 14y ago

That which was old, is new again. I find the cyclic nature to be interesting, and possibly a response to the increasing nature of computer power. Originally, the mainframe was where the power was. Then the PC was enough to do a lot of the work the mainframe was doing. Then the nature of delivering experiences to those around the world necessitated a shift back to the server for a lot of tasks (try running Google or Facebook locally), with a shift to making the Gui thin... Performance in the browser was woeful. Now, the performance of the browser across our increasing amount of disparate devices is nearly adequate enough for thick guis once more, with the bonus of it working across a multitude of OSes (Windows, Linux, Mac, iOS, Android, Windows Phone, Chrome OS, etc.) It truly is interesting to watch and play in :)

PommeDeTerre 14y ago
This is more a case of "old is still old", I think. We've been hearing about how web apps or browser-based apps will replace desktop apps for many years now, yet it never happens. I can still remember all of the Java applet, ActiveX control and DHTML hype of the late 1990s. It died out when it was proven to be nonsense. Desktop apps continued to thrive. Then it built up again a few years later, during the middle of the last decade, when AJAX and jQuery became all the rage. These offerings were marginally better than what we saw in the DHTML era, but still lacking. The only traction they gained was at the very low end. Most serious users still preferred to use real desktop applications. Now it's a few years later, and there's been a lot of HTML5 hype. Yet the browser-based apps are still no closer to replacing desktop apps. Gmail, for instance, has been around for almost a decade, but a great many people much prefer a real mail client. We also haven't seen much traction when it comes to modern online office suites, and other web-based alternatives to more traditional desktop apps. Native desktop or mobile apps are going to be around for a long time. I question whether it is even possible for any browser-based app to compete. In order to do so effectively, it would be necessary to eliminate the browser itself, as it is the browser and its related technologies which provide the poor experience we get from many web apps. It just looks like a complete no-win situation for web apps, aside from perhaps at the very low end.
- aidos 14y ago
  I think things are still moving in the direction we expected. Java applets and ActiveX were horrible experiences, that's why they didn't survive, not because desktop apps are fundamentally better. And DHTML is just a different name for webpages that use Javascript - that was doing pretty well last time I checked. Google Docs and Gmail replaced traditional desktop apps for me a long time ago. Sure, not everyone has moved, and it will certainly be a long time before the enterprise sector throws out their desktop apps, but in the consumer space many people just use web based mail clients. According to year old Litmus stats [0] 31% of email was webmail (and how much of the outlook traffic is from office workers?). Xero have done an amazing job of pushing into a space dominated by and old desktop app (Sage). People are moving, slowly but surely. I know that desktop apps are not going to vanish soon but it's not fair to say that web apps haven't gained much traction. Any issues you're seeing in the experience at the moment will be smoothed out. There's mind boggling amounts of resource being poured into making web apps faster (V8 etc) and the emerging frameworks for rich interfaces (Angular etc) are going to enable a whole new breed of web app. [0] http://litmus.com/blog/email-client-market-share-stats-infographic-june-2012/email-client-market-share-june-2012 http://litmus.com/blog/email-client-market-share-stats-infog...

onemorepassword 14y ago

Although there is definitely a shift going on, I suspect it won't be half as radical as people like the author tend to evangelize. This model may be a big shift for a simple web app, but for larger applications with lots of business logic it will barely make a difference. The "big web app full of things" will still be there, only with a few things less, and it will still be built with tons of tools, not just a micro framework. The future of web development won't be that different. There will just be more of it, but that's pretty much what has been happening since the 90's. There's enough exiting new stuff happening without going overboard and announcing it as a new era or a major paradigm shift. Maybe I'm getting old, but I find it tiresome.

elicox 14y ago

The people live in a bubble, they don't considerer that there is others kind of software that required more (so much more) business logic, that only an insane man can try to solve with js.

steverb 14y ago
The problems that can be solved using js grow large with each passing year though. I wrote a video recording and exporting app for a client this year using web technolgies (html + js + node). I couldn't have imagined that being possible 10 years ago.
- rjbond3rd 14y ago
  Very cool. So did your app somehow manage to do video capture on the client hardware, or did you access something equivalent to a webcam?
  - steverb 14y ago
    In this case, it captures and streams from the computer it is running on via a video capture card. The application is for archiving audio and video from an external box that it monitors. The nice thing about doing it that way, is that adding the capability to stream real-time from the external box that is being monitored is as easy as opening the ports to external access.
- elicox 14y ago
  I am not talking about this. What I means it's when you have to deal with more complex interaction, between different systems, old technologies, ... What you say it's true, JS it's going to evolve in the next years until to convert in something totally different, you will see. Some people call that reinvent the wheel. I am not against JS at all, I just dont think every single problem can be resolve with that, sorry.
blablabla123 14y ago
Looking at MVC, a common recommendation is to put the business logic into the model. "Fat models, skinny controllers" IMHO the JS frontend should contain almost no business logic. Rather it should be handled either by "the" backend or if it is really that complex, by a separate web service. (Self-speaking that this service can be written in any language that makes sense.) (On the other hand, the success of node.js proves that medium sized applications can be written in pure JS.)

rsl7 14y ago

wait... this guy thinks the future is going to be simpler? when has that ever happened? However, I largely agree on the right side of the big vertical network line in his diagram, and I feel this has been obvious for years now. The left side, not so much. I think the reduction of web services to JSON type data will enable an explosion of client side diversity, and that is a good thing. Also there is nothing classic about "server-side" MVC : it is ridiculous and never made any sense.

nonamegiven 14y ago
"wait... this guy thinks the future is going to be simpler? when has that ever happened?" It happens constantly. It's such a strong urge that making things simpler itself has become simpler. I'm touching simpler right now. This linux distro (lubuntu, doesn't matter) took me much less than an hour to download and install, fully functional with no configuration by me. In fact it was fully functional before I installed it, because it was a live distro that connected to the internet with no configuration on my part. 15 years ago that would have required me to download a bunch of separate files, copy them to a stack of floppy disks, and keep a book by Matt Walsh open on my knees while I tried to figure out again how to make my computer talk to my modem and to the wider internet. I'll completely reinstall my OS on a whim, with confidence. I used to approach it with dread and a good night's sleep. I also don't adjust the choke on my car when I start it, and I have no idea how to safely crank the engine from the front of the car; actually, I can't find the place to put the crank handle in, and I can't find the crank. EDIT: s/router/modem/
- chipsy 14y ago
  That's easier, not simpler. When part of the stack breaks you're even less likely to know how to fix it than 15 years ago. http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
  - nonamegiven 14y ago
    The procedure that I use is simple, regardless of the underlying complexity that makes it simple. Eating is simple, even though the body is complex. I'm glad I don't have to explicitly operate my pancreas.

ecopoesis 14y ago

MVC isn't just a good idea for making development easier, it's also the natural resting state for most applications. In the future, well just be distributing the models, views and controllers across multiple machines and networks, just as was done on the past.

ghc 14y ago

> In fact, I think Python is becoming the secret weapon behind every good Javascript application ;) My recent experience says this is not true. Python is so widely used as a backend that it is in no kind of secret weapon - at least not in the way Lisp was a secret weapon for Paul Graham with Viaweb. Every startup I've dealt with recently is building their backend in Python, Ruby or Node. I think the real story here is that compiled languages are on a major downswing in use for startups that build web apps. I haven't run across a startup building their backend with .NET or Java in a couple of years, except for one payment application that built the business logic with C# and MS SQL Server (they still built their web API with RoR). Recently I tried to go back to compiled languages for a new web project. I really wanted to try something fun in Haskell that wasn't just data processing (what I normally use it for). I picked up Snap, Yesod and a few other libraries only to find that it was just too much of a pain. Dynamic languages remove so many little annoyances with web development that it's hard to justify going back to a compiled one when you could just cheaply spin up an extra VM or two to deal with the performance differential between dynamic and compiled languages. Maybe I'll try Go next...

boothead 14y ago
Interesting. I was the someone who wrote the snippet about my app becoming a zeromq => Websockets routing layer and I've been thinking that the correctness, speed and fluency doing anything stream related of haskell for this layer would be perfect. When you add in being able to share datatypes between the server and client via Fay it seems ideal!
- Xurinos 14y ago
  Can you go into more detail about your architecture (a quick diagram of the connections between these components)? I am very interested -- my own dabblings have been leading me in this direction and firm belief, but I would love to learn from someone else's experience with it. Please feel free to email me if you prefer.
dysoco 14y ago
Well you have Go, D and Haskell: And Scala, Clojure, Erlang if you count VM languages.

calpaterson 14y ago

It's funny, this architecture he mentions of one-page-app clients on the frontend and microframework servers on the backend with Python is precisely the model I choose for a recent side project. What I learned: - Javascript requires a lot of architecture to be sustainable over even medium size apps (I stole N. Zaka's architecture) - Writing functional tests for Javascript is difficult. (Writing unit tests is easy) - Most web browsers are nearly there with everything you need for one-page-apps. IE8 is the only real problem, and I think my problems are soluble. - Python's single threaded nature requires that you make explicit effort to add offline jobs (I added a priority queue using redis) - Elasticsearch is actually quite complicated once your needs move out of the completely trivial - Most of the documentation for Elasticsearch assumes a working knowledge of Lucene (which I don't have). - Mongodb is really really easy to develop against - Getting a single page app to be sensibly indexed by Google is not easy. Here's the backend source: - https://github.com/calpaterson/recall https://github.com/calpaterson/recall And the frontend source: https://github.com/calpaterson/web-recall https://github.com/calpaterson/web-recall And the current deployed version is here: https://recall.calpaterson.com/about/ https://recall.calpaterson.com/about/ I'd love to answer any questions, I'm not as keen on one-page-apps now as I was when I started.

wyuenho 14y ago
Getting a single page app to be sensibly indexed by Google is not easy. I think this is the most important point when people are deciding whether they should move their entire frontend layer to the browser in their new projects, and frankly, a lot of guys pushing (or developing) for single-page webapps don't get that. While it is possible to have a mix of client-side routes/pushState/server-side generated template, it's actually non-trivial. So I really don't see a lot of cut and dry separation of layers anytime soon until Google can start indexing sites that fetches data after the HTML structure has arrived. Big full-stack webapp frameworks are here to stay, tho we might see more webapp frameworks that are great at doing API first to emerge.
jseims 14y ago
Do you have a link that elaborates on N. Zaka's architecture?

snambi 14y ago

Still Server will render the main page. Main page is " html + main content that user and search engine wants to see". Because the search engines need to index this page ( meaning the URL ), so the main content must be same, unless it is a private page. Also the browsers are designed to render html from the server. HTML5 brings in a lot of dynamic features, but the main feature is not going away.