3 ms·

I'm not an expert, but I know that server-side JS is completely feasible approach here. However, it may truly not be the best tool for the job. Client-side JS b

I'm not an expert, but I know that server-side JS is completely feasible approach here. However, it may truly not be the best tool for the job. Client-side JS being required is a fundamental problem for all sorts of reasons, such as accessibility and more. One issue is: plain old HTML and CSS are better tools for regular people to deal with to lower the barriers to wider participation in the web. Having to learn JS to make sense of a website is an extra burden. To me, it comes down to: see all the complaints about brokenness when client-side JS fails or is off. Building things with client-side JS as a requirement is unacceptable. Now, ignore client-side. Can you actually make the case that server-side JS is superior to other frameworks and languages? It shouldn't be used just because it's the same language as the client-side enhancements. If it's not the best option server-side, go with the better options instead. But I don't know enough myself to make that judgment, I'm just talking about the way to think about it.

lstamour 12y ago
Complicating matters further is that "best" languages probably don't exist: or rather, the best option is likely a combination of apps and frameworks written in different languages. Plus there are lots of languages that compile to JavaScript now, which means you could support "isomorphic" apps and still use a language your team might be familiar with. This all just complicates things further. I agree this is more about people not caring about all possible use cases because they focus on the performance of just one browser or just one platform to get a working app. It's hard to move from working proof-of-concept app to a fully-developed product that you can build on in future that is entirely multi-device and cross-browser. Then once the technical details are in place, ask yourself if you're building "the right product" and you really do need an entire team. I'm not entirely sure I'd blame over-reliance on client-side programming however. To me that's a symptom not the cause. It'd be like blaming CSS Media Queries for the fact that most mobile sites purposefully hide functionality and are less useable on phones than their desktop counterparts. The problem isn't the technology in as much as it's a lack of understanding in how it can be best applied. There is progress however. It used to be we had lots of websites putting text in images, using tables for layouts, or using JavaScript for interactive drop-downs. It's nice to know that as an industry, over a decade, we moved from 0% CSS to everyone using CSS and perhaps over-using it. I'm sure within the next decades we'll see an emphasis on all good practices, until the point where the web is again unrecognizable: just as today's developers probably wouldn't know where to start with spacer.gifs, it's possible in future we'd question anyone who doesn't serve pre-rendered HTML with modular JS serving for performance reasons. Either that, or SPDY makes it all unnecessary. I'm of two minds ;-)
mikermcneil 12y ago
So disclaimer I'm a little biased towards Node. It brings me tremendous philosophical zeal. You're right about server-side JavaScript-- there are so many more useful features in other languages, and things are more expressive (I like Lisp and Groovy, for instance). But the beauty of server-side js is that it's our esperanto. I'm interested in seeing a new generation of kids and senior citizens participating creatively on the web. But in order to do that, we need to standardize to a single programming languages across use cases, disciplines, and preferences. And JavaScript, whatever you think of it, is the best opportunity we've had.
- gregjor 12y ago
  This is a fairly old argument. The single universal programming language that anyone could pick up and use led to BASIC on the low-end and PL/1 on the high-end. Neither is used much anymore. Neither appealed much to a wide audience of non-programmers, though BASIC came close. And neither were anything near universal even in their heyday. If server-side JS is "our esperanto" that's damning with faint praise. Esperanto is not a universal language, it doesn't fill any actual need, and it hasn't encouraged more people to read or write.
- quadrangle 12y ago
  You mean it's our "lingua franca" — the thing that isn't better in any way, but is just used universally enough that everyone ends up using it. I don't understand the metaphor to Esperanto.

lstamour 12y ago

Complicating matters further is that "best" languages probably don't exist: or rather, the best option is likely a combination of apps and frameworks written in different languages. Plus there are lots of languages that compile to JavaScript now, which means you could support "isomorphic" apps and still use a language your team might be familiar with. This all just complicates things further. I agree this is more about people not caring about all possible use cases because they focus on the performance of just one browser or just one platform to get a working app. It's hard to move from working proof-of-concept app to a fully-developed product that you can build on in future that is entirely multi-device and cross-browser. Then once the technical details are in place, ask yourself if you're building "the right product" and you really do need an entire team. I'm not entirely sure I'd blame over-reliance on client-side programming however. To me that's a symptom not the cause. It'd be like blaming CSS Media Queries for the fact that most mobile sites purposefully hide functionality and are less useable on phones than their desktop counterparts. The problem isn't the technology in as much as it's a lack of understanding in how it can be best applied. There is progress however. It used to be we had lots of websites putting text in images, using tables for layouts, or using JavaScript for interactive drop-downs. It's nice to know that as an industry, over a decade, we moved from 0% CSS to everyone using CSS and perhaps over-using it. I'm sure within the next decades we'll see an emphasis on all good practices, until the point where the web is again unrecognizable: just as today's developers probably wouldn't know where to start with spacer.gifs, it's possible in future we'd question anyone who doesn't serve pre-rendered HTML with modular JS serving for performance reasons. Either that, or SPDY makes it all unnecessary. I'm of two minds ;-)

mikermcneil 12y ago

So disclaimer I'm a little biased towards Node. It brings me tremendous philosophical zeal. You're right about server-side JavaScript-- there are so many more useful features in other languages, and things are more expressive (I like Lisp and Groovy, for instance). But the beauty of server-side js is that it's our esperanto. I'm interested in seeing a new generation of kids and senior citizens participating creatively on the web. But in order to do that, we need to standardize to a single programming languages across use cases, disciplines, and preferences. And JavaScript, whatever you think of it, is the best opportunity we've had.

gregjor 12y ago
This is a fairly old argument. The single universal programming language that anyone could pick up and use led to BASIC on the low-end and PL/1 on the high-end. Neither is used much anymore. Neither appealed much to a wide audience of non-programmers, though BASIC came close. And neither were anything near universal even in their heyday. If server-side JS is "our esperanto" that's damning with faint praise. Esperanto is not a universal language, it doesn't fill any actual need, and it hasn't encouraged more people to read or write.
quadrangle 12y ago
You mean it's our "lingua franca" — the thing that isn't better in any way, but is just used universally enough that everyone ends up using it. I don't understand the metaphor to Esperanto.