8 ms·

I don't have time to formulate a proper response but I just wanted to say this makes me sad. We've now reached the point where HTML and CSS served via a normal

by andybak 10y ago

I don't have time to formulate a proper response but I just wanted to say this makes me sad. We've now reached the point where HTML and CSS served via a normal webserver is regarded as insufficient and anyone who wants to build websites of even the simplest kind is expected to wheel in an incredibly large client-side and development stack. Something has gone wrong. All this to avoid a page reload? Should the terrible effects of a page reload not be solved elsewhere? > without the hacky "pjax" solution. Before you start using the word 'hacky' you might want a moment of self-reflection.

root_axis 10y ago
> anyone who wants to build websites of even the simplest kind is expected to wheel in an incredibly large client-side and development stack. What? Says who? In my humble opinion this sounds to me like a case of "I don't like when people use things that I don't like". Nobody is expecting anyone to do anything for "websites of even the simplest kind". People just use technology they like or think is fun. Nobody is forcing you to like it or use it.
- gambler 10y ago
  Nobody is forcing you to like it or use it. SPAs definitely try to force me to use JavaScript when browsing.
  - root_axis 10y ago
    This is an ironic reply in the context of an article showcasing a technology that literally obviates that exact issue.
    - gambler 10y ago
      It's not ironic at all. Many websites listed on project's showcase page are screwed up if you open them without JavaScript. From mangled layouts to complete failures of rendering. This project pushes complexity where no complexity is needed. It's main appeal is that it uses a JavaScript library designed for faster DOM manipulation to render static pages. Do you not see that something is horribly wrong with this picture?
- andybak 10y ago
  I agree there's an element of "get off my lawn" about me - but it's backed by a genuine fear about what happens to people new to web development. The impression given by looking around the web for discussions and tutorials is that you have to learn full client-side MVC. This is a huge burden to impose. The other danger is that people are building sites using these stacks because they never learnt the simpler way to do things. All the complexity gets pulled in without question. At least us old-timers have the experience to know when there's a positive cost/benefit ratio for all this tech. I'm not sure everyone will in the future.
  - root_axis 10y ago
    I get what you're saying, and I do agree that beginners can easily get bogged down in all the different tools, frameworks and libraries, however at the end of the day I feel like beginners just have to learn how to navigate the ecosystem. If a novice is trying to build a webpack powered react/redux SPA on top of kafka without understanding basic programming fundamentals then only their own failure is going to teach them why that isn't such a great idea. At a minimum I think we need to just expect beginners to do a little research on what it is they need to learn. Overambitious novices are not exclusive to the software world, think of a novice guitar player who insists on spending $3000 on pedals, amps and mixing software before they're able to pluck out "twinkle twinkle little star"; some people just need to learn the hard way. Besides, as you alluded to, having the ability to weigh tradeoffs and make a cost/benefit analysis is a honed skill that takes time and experience to develop and making a few incorrect choices is a critical part of the learning process.
deleted 10y ago
[deleted]
weavie 10y ago
Impatient-mode in Emacs can give you automatic page reload as you type. http://www.50ply.com/blog/2012/08/13/introducing-impatient-mode/ http://www.50ply.com/blog/2012/08/13/introducing-impatient-m...
artursapek 10y ago
> anyone who wants to build websites of even the simplest kind is expected to wheel in an incredibly large client-side and development stack not really, you just seem to be overreacting to someone experimenting with a different way of doing it. I doubt most users would be able to tell the difference when browsing a traditional static site vs. the one in this article. I agree with you that there's a lot of overkill in our industry, but engineers can't be expected to sit on their hands and think up new ideas :)
dentemple 10y ago
Sometimes it's just fun building things in a nice technology.
CoffeeDregs 10y ago
I hugely agree. I've done a lot of web development in a range of circumstances and this current period is frustrating. I just started a new project at a new company; decided to use React; bought and downloaded a React Admin template; spent 2 hours trying to get it to "build"; gave up after I couldn't sort the node_modules conflicts among about 50 modules (totalling nearly 1GB!), each of which had 10+ modules as a dependency. Angular did have its issues, but I dropped a reference to CDN's version into a web page and was off to the races very quickly. I'm literally using Makefiles to build, test and deploy a set of about 7 microservices (including their web admin tooling). It's incredibly straightforward, flexible and clearly documented... Gulp, Grunt, WebPack... What are we doing?
- justinsaccount 10y ago
  > bought and downloaded a React Admin template huh? > Angular did have its issues, but I dropped a reference to CDN's version into a web page and was off to the races very quickly. Then you're not really comparing apples to apples here. There are <script> loadable versions of react on CDNs that you could have used.
  - at-fates-hands 10y ago
    Probably the difference between having Angular being a full MVC framework, while React is simply a View library you combine with other libraries to get what you need. Combining various libraries can be a pain and sorting out all of the dependencies and node modules like he stated can be cumbersome.
- matmo 10y ago
  >Gulp, Grunt, WebPack... What are we doing Once you've accepted that JS is here to stay in browser-land (for now, at least), what alternatives are there for build tools? As a younger dev, when I look at makefiles, I see the same level of complexity and "confusing-ness" that I encountered when I first learned about gulp or webpack configs. I keep reading posts like this on HN where people yearn for simpler days, but weren't the demands of websites and user interfaces simpler back then as well? I've only been doing professional web development specifically for 4 years or so, so I don't have the same experiences of building in older technologies, but I simply can't imagine trying to build a large, immersive SPA without a modern framework. How do you manage global state or services? Just throw everything in the global namespace? How do you minify your js/css/html? How do you treeshake your unused code? How do you create a local proxied server to avoid CORS issues while developing? How do you autoprefix your css automatically? How do you develop with live-reload functionality? I know all of these can be done individually without these tools, but you can do these all individually without gulp/webpack/etc just by using node/npm scripts. These tools just package them into a more convenient format for common use cases, and tie complimenting tools together. It seems to me that everything would need to be custom built, and you would need to recreate complex scripts from scratch for every new project. These tools obviously aren't perfect, but I'm not sure they're as bad as you're making them out to be either. Like I said, I don't have the same long-term experience as you or others might, so forgive me if I'm just being naive here.
subpixel 10y ago
I think these tools (Phenomic, Gatsby) are aimed at front-end developers who are already familiar with React resources and who can leverage that knowledge and the ecosystem of tools to build static sites much the way they build apps. The bells & whistles are mostly added bonuses - not an argument that all static sites should be built this way. At least that would not be an effective argument in my book.
stymaar 10y ago
> We've now reached the point where HTML and CSS served via a normal webserver is regarded as insufficient We've reached this point in 1995, that's why Rasmus Lerdorf created PHP ! Edit: Oh, I just realised that this is even older than the CSS spec itself (1996). So technically, there has been no point in time where HTML and CSS served via a normal webserver[1] were regarded as sufficient :) [1]: what is a «normal webserver» anyway ?
- andybak 10y ago
  You know what I meant. If you're entirely serious then I'll engage but I think you're splitting hairs somewhat. ;-)
jhpriestley 10y ago
Incredibly large? Chrome and httpd are each hundreds of times larger than react. If you like simplicity then you should abhor HTML, not React...
Touche 10y ago
On the contrary, you shouldn't feel sad but rather excited. So many people have a false expectation that they must build everything as a SPA, even with all of the glaring UX problems that the SPA model presents. You should be excited because if you're building a CRUD application that doesn't need to be a SPA, and you choose the traditional server-rendered route... your app is going to be better than the equivalent SPA hog. Your app is going to be better, users will feel that it's better, and they'll give you their money. Oh, and you don't have to re-invent the wheel with things like routing, so you are saving a lot of development time that the SPA competitor wastes on. Another win for you and your customers, more time to work on features.
z3t4 10y ago
its funny how page reloads was fine 20 years ago and now with much faster computers and bandwith we try to avoid them. the advantage thoug is that you do not need a server. even with dynamic state/data the app can be hosted on a CDN or static web server.
threatofrain 10y ago
I would argue that the HTTP request is one of the most expensive things you can do in terms of user interface latency for web apps, and if you're making requests at very the time of need, then the user will experience a big GUI pause. But if you could anticipate even some of these requests, and you request ahead of time and deliver the results via DOM mutation, then you might be decreasing net user interface latency.

by andybak 10y ago

root_axis 10y ago

> anyone who wants to build websites of even the simplest kind is expected to wheel in an incredibly large client-side and development stack. What? Says who? In my humble opinion this sounds to me like a case of "I don't like when people use things that I don't like". Nobody is expecting anyone to do anything for "websites of even the simplest kind". People just use technology they like or think is fun. Nobody is forcing you to like it or use it.

gambler 10y ago
Nobody is forcing you to like it or use it. SPAs definitely try to force me to use JavaScript when browsing.
- root_axis 10y ago
  This is an ironic reply in the context of an article showcasing a technology that literally obviates that exact issue.
  - gambler 10y ago
    It's not ironic at all. Many websites listed on project's showcase page are screwed up if you open them without JavaScript. From mangled layouts to complete failures of rendering. This project pushes complexity where no complexity is needed. It's main appeal is that it uses a JavaScript library designed for faster DOM manipulation to render static pages. Do you not see that something is horribly wrong with this picture?
andybak 10y ago
I agree there's an element of "get off my lawn" about me - but it's backed by a genuine fear about what happens to people new to web development. The impression given by looking around the web for discussions and tutorials is that you have to learn full client-side MVC. This is a huge burden to impose. The other danger is that people are building sites using these stacks because they never learnt the simpler way to do things. All the complexity gets pulled in without question. At least us old-timers have the experience to know when there's a positive cost/benefit ratio for all this tech. I'm not sure everyone will in the future.
- root_axis 10y ago
  I get what you're saying, and I do agree that beginners can easily get bogged down in all the different tools, frameworks and libraries, however at the end of the day I feel like beginners just have to learn how to navigate the ecosystem. If a novice is trying to build a webpack powered react/redux SPA on top of kafka without understanding basic programming fundamentals then only their own failure is going to teach them why that isn't such a great idea. At a minimum I think we need to just expect beginners to do a little research on what it is they need to learn. Overambitious novices are not exclusive to the software world, think of a novice guitar player who insists on spending $3000 on pedals, amps and mixing software before they're able to pluck out "twinkle twinkle little star"; some people just need to learn the hard way. Besides, as you alluded to, having the ability to weigh tradeoffs and make a cost/benefit analysis is a honed skill that takes time and experience to develop and making a few incorrect choices is a critical part of the learning process.

deleted 10y ago

[deleted]

weavie 10y ago

Impatient-mode in Emacs can give you automatic page reload as you type. http://www.50ply.com/blog/2012/08/13/introducing-impatient-mode/ http://www.50ply.com/blog/2012/08/13/introducing-impatient-m...

artursapek 10y ago

> anyone who wants to build websites of even the simplest kind is expected to wheel in an incredibly large client-side and development stack not really, you just seem to be overreacting to someone experimenting with a different way of doing it. I doubt most users would be able to tell the difference when browsing a traditional static site vs. the one in this article. I agree with you that there's a lot of overkill in our industry, but engineers can't be expected to sit on their hands and think up new ideas :)

dentemple 10y ago

Sometimes it's just fun building things in a nice technology.

CoffeeDregs 10y ago

I hugely agree. I've done a lot of web development in a range of circumstances and this current period is frustrating. I just started a new project at a new company; decided to use React; bought and downloaded a React Admin template; spent 2 hours trying to get it to "build"; gave up after I couldn't sort the node_modules conflicts among about 50 modules (totalling nearly 1GB!), each of which had 10+ modules as a dependency. Angular did have its issues, but I dropped a reference to CDN's version into a web page and was off to the races very quickly. I'm literally using Makefiles to build, test and deploy a set of about 7 microservices (including their web admin tooling). It's incredibly straightforward, flexible and clearly documented... Gulp, Grunt, WebPack... What are we doing?

justinsaccount 10y ago
> bought and downloaded a React Admin template huh? > Angular did have its issues, but I dropped a reference to CDN's version into a web page and was off to the races very quickly. Then you're not really comparing apples to apples here. There are <script> loadable versions of react on CDNs that you could have used.
- at-fates-hands 10y ago
  Probably the difference between having Angular being a full MVC framework, while React is simply a View library you combine with other libraries to get what you need. Combining various libraries can be a pain and sorting out all of the dependencies and node modules like he stated can be cumbersome.
matmo 10y ago
>Gulp, Grunt, WebPack... What are we doing Once you've accepted that JS is here to stay in browser-land (for now, at least), what alternatives are there for build tools? As a younger dev, when I look at makefiles, I see the same level of complexity and "confusing-ness" that I encountered when I first learned about gulp or webpack configs. I keep reading posts like this on HN where people yearn for simpler days, but weren't the demands of websites and user interfaces simpler back then as well? I've only been doing professional web development specifically for 4 years or so, so I don't have the same experiences of building in older technologies, but I simply can't imagine trying to build a large, immersive SPA without a modern framework. How do you manage global state or services? Just throw everything in the global namespace? How do you minify your js/css/html? How do you treeshake your unused code? How do you create a local proxied server to avoid CORS issues while developing? How do you autoprefix your css automatically? How do you develop with live-reload functionality? I know all of these can be done individually without these tools, but you can do these all individually without gulp/webpack/etc just by using node/npm scripts. These tools just package them into a more convenient format for common use cases, and tie complimenting tools together. It seems to me that everything would need to be custom built, and you would need to recreate complex scripts from scratch for every new project. These tools obviously aren't perfect, but I'm not sure they're as bad as you're making them out to be either. Like I said, I don't have the same long-term experience as you or others might, so forgive me if I'm just being naive here.

subpixel 10y ago

I think these tools (Phenomic, Gatsby) are aimed at front-end developers who are already familiar with React resources and who can leverage that knowledge and the ecosystem of tools to build static sites much the way they build apps. The bells & whistles are mostly added bonuses - not an argument that all static sites should be built this way. At least that would not be an effective argument in my book.

stymaar 10y ago

> We've now reached the point where HTML and CSS served via a normal webserver is regarded as insufficient We've reached this point in 1995, that's why Rasmus Lerdorf created PHP ! Edit: Oh, I just realised that this is even older than the CSS spec itself (1996). So technically, there has been no point in time where HTML and CSS served via a normal webserver[1] were regarded as sufficient :) [1]: what is a «normal webserver» anyway ?

andybak 10y ago
You know what I meant. If you're entirely serious then I'll engage but I think you're splitting hairs somewhat. ;-)

jhpriestley 10y ago

Incredibly large? Chrome and httpd are each hundreds of times larger than react. If you like simplicity then you should abhor HTML, not React...

Touche 10y ago

On the contrary, you shouldn't feel sad but rather excited. So many people have a false expectation that they must build everything as a SPA, even with all of the glaring UX problems that the SPA model presents. You should be excited because if you're building a CRUD application that doesn't need to be a SPA, and you choose the traditional server-rendered route... your app is going to be better than the equivalent SPA hog. Your app is going to be better, users will feel that it's better, and they'll give you their money. Oh, and you don't have to re-invent the wheel with things like routing, so you are saving a lot of development time that the SPA competitor wastes on. Another win for you and your customers, more time to work on features.

z3t4 10y ago

its funny how page reloads was fine 20 years ago and now with much faster computers and bandwith we try to avoid them. the advantage thoug is that you do not need a server. even with dynamic state/data the app can be hosted on a CDN or static web server.

threatofrain 10y ago

I would argue that the HTTP request is one of the most expensive things you can do in terms of user interface latency for web apps, and if you're making requests at very the time of need, then the user will experience a big GUI pause. But if you could anticipate even some of these requests, and you request ahead of time and deliver the results via DOM mutation, then you might be decreasing net user interface latency.