4 ms·

I still fail to see why we should not use Javascript for everything. > "That is the great thing about web technology. It isn’t clean or well designed by a long

by jasim 12y ago

I still fail to see why we should not use Javascript for everything. > "That is the great thing about web technology. It isn’t clean or well designed by a long shot — but it is extensible and it can learn from many products built with it." That _was_ the great thing about web technology: 'worse is better', but it is no longer an aspirational goal. As a developer I need a well-designed web to build on, and these modern frameworks are doing exactly that. > If we do everything client-side we do not only need to deliver innovative, new interfaces. We also need to replicate the already existing functionality the web gives us. A web site that takes too long makes the browser show a message that the site is not available and the user can re-try. When the site loads, I see a spinner. Every time we replace this with a client-side call, we need to do a lot of UX work to give the user exactly the same functionality. There is no "Loading" spinner anymore on a well-built JS-heavy application. Good frameworks (React, Ember with FastBoot) use Javascript on the server to send a fully rendered HTML to the client. That works. And they rehydrate this HTML with JSON data and client-side logic so that any further JS interaction is smooth and can be done using the conveniences of the framework. But if were to follow the gist of what the article is trying to tell us, we should instead be rendering HTML using typical server-side technologies, and use progressive enhancement to add dynamism in the client. This is not a good solution: we have to duplicate rendering logic on both the client and server using two completely different stacks. It is a lot of cognitive load, needs duplication of effort, and is a maintenance nightmare. A better solution is to simply render everything using Javascript, and remember that Javascript is no longer a client-side technology. Use the same Javascript to render contents both on the server and the client and rehydrate the rendered HTML transparently on the client. I also disagree with the author's implied assertion that people who use conveniences like SASS do it more because of incompetence in wielding CSS. The kinds of abstractions CSS promotes are selectors, specificity, and cascade. They are not the kind of abstractions one needs to build a maintainable and reusable body of code. We programmers know what they are: variables, modules, objects, control structures, expressions.. SASS provides some of those missing pieces: variables, mixins, conditionals and expressions. In fact SASS pushes CSS closer to a programming language than CSS is, and that is a good thing. The article closes on this note: > A lot of our work on the web goes pear-shaped in maintenance. This is not a technology issue, but a training one. And this is where I am worried about the nearer future when maintainers need to know all the abstractions used in our products that promise to make maintenance much easier. It is tough enough to find people to hire to build and maintain the things we have now. The more abstraction we put in, the harder this will get. I'm as close to an abstraction-hater as the next person. But there are good abstractions and bad ones. Mutating DOM directly using spaghetti Javascript? That is just no abstraction. Once we understand the rendered view as a function of state, then it makes sense to have abstractions based on that idea (like one-way or two-way data binding). The need for training is not a point of contention. But assume we have competent developers working in good faith, and they still find it hard to write well-maintainable code for the web, then it has to be something else that is broken. Having used these newfangled frameworks for a while now, I do think that is very much the case. Anyone should be able to put together reasonably written web-apps without being masters at the craft, but it has so far been hard, not because of people, but because of tools.

quadrangle 12y ago
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 ;-)

by jasim 12y ago

quadrangle 12y ago

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 ;-)