24 ms·

JS files

448 points by diablo1 7y ago

AdmiralAsshat 7y ago
Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me anything unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps. When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God.
- Spivak 7y ago
  The JAM stack the author is talking about is entirely driven by JS. The is “static” in the sense that a .dmg file is static and can be hosted on a CDN and not templated on the server.
  - ehvatum 7y ago
    Jesus, why? You could write the back end in something that isn’t fucking garbage, at that point.
    - sergiotapia 7y ago
      shovel sellers, that's why
    - godman_8 7y ago
      I’m not a JS fan but quit with the toxicity. The proprietary logic is done with languages like Go, Rust, Python, JS, etc and built with a RESTful API in mind so the frontend can consume it. Angular, React, and Vue are built to do this well. It’s all in moderation and should be done responsibly. The downside with this of course is added complexity on all levels. However with this design maturing the complexity has reduced some or effort offloaded elsewhere (microservices, serverless, k8s.)
    - hombre_fatal 7y ago
      This is just empty negativity. That people use Javascript in places they aren't forced to use Javascript should make you wonder what the upsides are for them instead of assuming they cannot form any valid preferences of their own, unlike yourself. For example, Javascript is one of the few languages that actually delivers on "async everything" and has a very simple Promise abstraction (like Promise.all()), and that makes it better for me than building networked services in similar languages (PHP, Python, Ruby). It's also one of the few dynamically-typed languages with a bolt-on static type system that actually gained traction. You might not care about these things somehow, like maybe you only write C and Python because you work with embedded systems. But I think it's time to stop calling it garbage in honest conversation.
      - nostrebored 7y ago
        Maybe the problem here is building networked services (sounds like synchronous communication between components). How often is it that a well architected microservice architecture needs to do more than push data into a decoupling resource and data store and consume data from a stream or a queue? Is Promise.all( ... ) really that relevant that often? I've come to enjoy Node.js more than I thought I ever would, but it's still not something that's ever mindblowing to me, and I don't think that switching to Python would be a huge burden. With sensible tooling and contracts, neither would switching to a statically typed backend.
      - karatestomp 7y ago
        Async-by-default from the perspective of the developer is one of the chief sins of JS, in this writing-JS-since-the-90s developer's opinion. I've seen and written so damn much code to work around async-by-default. Now most of the code I read is comically full of (justified!) awaits, so at least we got the sugar to fix it without so much fuss, but we shouldn't have to in the first place. Let async code surrender control, but don't continue executing the current logic unless the developer asks for that behavior. Await-like behavior by default. That would have been much saner, less bug-prone, more helpful, and easier to learn & reason about. It's the desired behavior at least 90% of the time, in my experience.
- the_cat_kittles 7y ago
  "i could do without the js" is an indictment of design decisions, not js. its performant as hell, and ubiquitous. its a great thing, ...what people chose to do with it is often not great, however.
- geggam 7y ago
  Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster
  - p2t2p 7y ago
    You're free not to use any website...
    - geggam 7y ago
      Arguably if you are publishing content on the net you are giving it away. There are mechanisms to charge for it.
      - hombre_fatal 7y ago
        > There are mechanisms to charge for it. Only above a certain price point. Our financial system nor our consumer culture support micropayments yet. This effectively limits the web properties that can charge users to a small fraction, so unfortunately "just charge money" isn't the widely-available solution I wish it was yet. Hell, it's more viable to charge users for your mobile client than the backing service. It's kind of the closest we have to micropayments in a way.
        geggam 7y ago
        Then you dont have a sustainable business model. Why should I subsidize your failed model ?
        buzzerbetrayed 7y ago
        Yet you somehow think charging content providers for using your computer when they give you free content isn’t a failed business model?
- kristopolous 7y ago
  When flash was dying I said it was a bad thing because ads would no longer be contained in these tidy, controllable virtual machines sitting adjacent to the page content but instead would be redone in JavaScript in a huge soupy mess where the content is held hostage by ads that slide in and out of the screen and cover content, popping in and out of existence, reflowing the page, making the content jump around and disappear as terribly coded flash apps become terribly coded JavaScript modules slogging the whole browser along with it. People thought I was wrong and insane. I wish I was. Realistic assessments are always less popular than hope and principles. Flash was the good times.
  - b0rsuk 7y ago
    Flash ads were trivial to block with plugins :-). And it was safe to block because usually no serious pages used Flash much except for artist portfolios.
Spivak 7y ago
It’s a nice title but webapps have evolved from documents to application bundles. It’s super cool that we built wildly complicated apps out of what was in spirit an FTP client with a PDF reader but it makes since that we have to hack the document retrieval system less now that the client can run code. Maybe one day we’ll stop hacking on the document store’s limited RPC-ish protocol too.
wideasleep1 7y ago
Would have been apt to use 'devolved'. 'Are We Not Men?'
popup21 7y ago
Wouldn't do it any other way. I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. I was regressing to the environment I understood in the early 2000s-2010s. I did all of this because I knew there would be a steep learning curve going into modern ecommerce and it seemed reasonable to put everything into hibernation while I attempted to go all-in. I pretty much missed the entire React, Angular, Vue ramp up in the industry. I've since shut down that ecommerce project and find myself peeking back to the js-verse every now and then. I doubt I'll ever voluntarily use one of those frameworks for web dev. I do, however, like this thing called, Svelte.
- kareemm 7y ago
  > recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. What are you using?
  - popup21 7y ago
    Publii. It's developed by a European (France, I think) team. It syncs to Netlify with a single mouse-click.
    - kareemm 7y ago
      Thanks!
    - lenova 7y ago
      +1 for Publii. It feels like it's early days for them (i.e. they only have a few themes & haven't been picked up by the third-party theme developer crowd yet), but man, does Publii make it easy for any end-user to generate and publish a static website.
- jakelazaroff 7y ago
  > I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20is,react%20js,angular%20js,vue%20js https://trends.google.com/trends/explore?geo=US&q=svelte%20i...
cjohansson 7y ago
It seems the trend points to slower and slower websites with more JS bloat. I also notice a increase in JS-errors causing entire sites to malfunction, recently this happened to large apps like Teams and Float
- camccar 7y ago
  New reddit is painfully slow to login. So much javascript for a simple dialog to load it's absurd.
  - qznc 7y ago
    As long as old and compact reddit are still there, I'm fine with it. Twitter on other hand has no lightweight version, unfortunately.
    - saagarjha 7y ago
      I think I recall someone mentioning there is one that you get if you send an empty User-Agent.
      - csande17 7y ago
        If JavaScript is disabled in your browser and you visit mobile.twitter.com, you get a link to proceed to "legacy Twitter", which is their pre-React mobile site.
    - benbristow 7y ago
      Twitter's redesign is one of the most performant SPA's I've seen in a while. It's really smooth and nicely designed too. A lot better than their previous webapp.
      - readarticle 7y ago
        Do you know any others? Every time I’m redirected to twitter on mobile I’m in awe, it’s genuinely the only SPA I’ve ever experienced work “properly” on my phone comparable to a native app without any polish.
s_y_n_t_a_x 7y ago
No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed. If you are building a web app, use React or similar. If you are building a web site, use plain HTML+CSS w/ supplemental JS. Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML. Maybe don't embed all that stuff in your app and you wouldn't struggle with forms and routing, something that browsers can do very well with no programming.
- x3haloed 7y ago
  Of course the reasonable answer gets downvoted. Stay strong! And remember that you're not a good developer unless you write everything in vim compiled for an OS that you wrote for yourself in C, backed up on a trusty old 2MB platter drive via a series of rsync scripts. I heard the concept of version control was originally conceived and canned by IBM in 1967, because it was found that version control would eventually become mainstream, and therefore bad.
  - s_y_n_t_a_x 7y ago
    Thanks for the kind words and the mention. I'm used to the downvotes on here unfortunately, it's easy to tell which topics will do it, the group think here can be thick...
    - x3haloed 7y ago
      You're welcome. My struggle on HN is to try to ignore the groupthink and keep the sarcasm out of my tone, but sometimes I just can't help myself.
- ng12 7y ago
  Preach. I teach a little "into to web dev" workshop that starts with a slide explaining that static sites, SSRs, and SPAs are all perfectly acceptable. They're different tools for different use cases.
- woutr_be 7y ago
gwern 7y ago
> I find it fascinating that we are back to generating separate HTML/CSS and JS files and then putting them on a static file server — the CDN. It has been a decade long effort and as we come back to where we started, I feel like we are at a whole another level (a spiral?). "The wheel of reincarnation" from client to server and back: http://www.cap-lore.com/Hardware/Wheel.html http://www.cap-lore.com/Hardware/Wheel.html
sircastor 7y ago
"All of this has happened before. All of this will happen again." I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.
x3haloed 7y ago
> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant. > But the web is about presenting content first and foremost! Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it? In the end, the article makes the right point: Use the right technology for what you're trying to build.
- amluto 7y ago
  > But Gmail showed us that web 'apps' are useful. And we really have come full circle. Gmail performance, at least on Firefox, is awful.
  - robbrown451 7y ago
    Whether or not this is true, when Gmail came out, it was WAY better (including faster) than everything that it competed with.
    - wolco 7y ago
      It was never faster then squirrelmail. It had cool features search was fast. But loading up your mailbox never as fast as other solutions.
      - robbrown451 7y ago
csomar 7y ago
We are not going back full circle. We are facing new challenges and realizing how complex web development is. 1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases. 2- There is no simple HTML either. Are you going to memorize how you coded that widget. Maybe use a framework (like bootstrap) to standardize things. 3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types. 4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM. 5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl. 6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn). tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.
- deleted 7y ago
  [deleted]
- Guest0918231 7y ago
  Well, I completely disagree. Compared to developing sites 15-20 years ago, I think it's a walk in the park now. I feel like I can achieve far more with less code, the tools are more powerful, the code is easier to read, and there is much more consistency across browsers. Did you want to make a box with rounded corners? We can do that now... <div style="border-radius: 5px; border: 2px solid black;"></div> It's intuitive and easy to understand. Try that 20 years ago. You're designing that in Photoshop, slicing up images for each corner, placing them into countless HTML table cells, messing around with all the table and cell heights, widths, paddings, margins, and borders, and struggling to get IE to render it correctly. That could have easily been an hour of work, and it would have resulted in a mess of images and inflexible code. Now, it's one line of code and 10 seconds of work. Did you want to fade the color of the border to red when the user hovers over the box? We can do that with two lines of CSS now. Good luck trying to achieve that in the past. What do you mean thousands of lines for a responsive/mobile CSS layout, and no simple HTML? https://www.w3schools.com/html/tryit.asp?filename=tryhtml_responsive_media_query3 https://www.w3schools.com/html/tryit.asp?filename=tryhtml_re... There, it's a site with a header, footer, navigation, three columns, and it's responsive. 36 lines of CSS and 36 lines of HTML. Add 5-10 lines of CSS to reset spacing at the beginning, and that could literally be an entire responsive website.
chrysoprace 7y ago
This is something that I see espoused by "web traditionalists" for lack of a better term. Sure, there are a lot of web developers who are not optimising for performance but I think the difference is that it has simply shifted to the frontend where it's more noticeable. The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's a variety of techniques that make sense in both areas to create a snappy, seamless experience. You need experienced engineers to create performance no matter what your domain is. We've gone down the route of creating SPAs to largely replace experiences that would require desktop applications (it was only 5 years ago that I had to download an executable to do my tax return, now I do it with an SPA). Rather than create an SPA for a blog or a simple marketing site, we've largely replaced traditional "heavy"[0] infrastructure (PHP, Apache, MySQL just to display static content) with static JavaScript-generated sites. Many of these can simply be hosted on a CDN because they have no database and often no need for complex routing. Pretending that SPAs were part of some dark ages is just silly. Horses for courses. If your application requires what I've dubbed "heavy" architecture (above) then by all means! Such infrastructure allows a high traffic service to be highly available, but is not required to serve a single .html file. [0] When I say "heavy" I'm mainly talking about the attack surface and maintenance required. WordPress is great for serving a blog but has been the target of many hackers due to the amount of security vulnerabilities it has had over time.
- torgoguys 7y ago
  SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern. That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.
  - muglug 7y ago
    I think an SPA can be much more user-friendly than a traditional series of server-rendered pages. Email is a great example of this - GMail, at launch, had much better UX than existing server-rendered applications like Hotmail. You can find bad UX everywhere - in SPAs and server-rendered interfaces alike - but there’s nothing implicit to SPAs that reduces usability.
5cott0 7y ago
If SPAs are the dark ages then what do you call the IE6/7 jQuery days?
- jonnycoder 7y ago
  The Wild Wild West!!? I remember doing jquery/ajax calling an API and while it was easy to churn out spaghetti or long js file code, it was still easier to read and pick up a few years later.
  - 5cott0 7y ago
    > it was still easier to read and pick up a few years later. Compared to what?
egypturnash 7y ago
My personal site is still a bunch of files served up by a cache in front of Wordpress. It'll be cool again in a couple years, I guess.
- paulmd 7y ago
  The really cool kids are just using something like Jekyll that does all the templating at publish time and you just have static files you dump onto a server.
zuhayeer 7y ago
We've been building Levels.fyi as a static website for the past 3 years! To create a new page, we simply hit new file on our text editor and start to fill the page. We have a simple build system + templating with Gulp and Nunjucks, but its really all we need. Scaling a static site is incredibly nice & cheap too :P
- movedx 7y ago
  > Scaling a static site is incredibly nice & cheap too :P And secure. The only back end systems to attack are load balancers and web servers -- if you're self hosting those then just make the file systems read-only and now you're talking seriously tough security barriers between you and an attacker.
nkozyra 7y ago
The leap from static HTML to PHP misses a big chunk of dynamic web site growth that started to produce a lot of the bad patterns that lived on. As simple and nice as static HTML is, it's inefficient. The reason we care about this now is mostly: A) A lot of people just hate Javascript. And a lot of that hate is understandable. B) People still worry about the crawlability of their SPAs JS has a lot of problems but it's also fixing some of these by growing really fast (paradoxically, also one of its problems). Bots will get more comprehensively better at rendering client-side only apps.
trynewideas 7y ago
The best part is that this is from an email newsletter and has broken HTML at the end.
ng12 7y ago
> But the web is about presenting content first and foremost This is where the article started going wrong. I don't care about the web -- it's a tool for me to do my job. I use the web because it's a much better alternative to shipping a Swing app. I don't care what the web is "about" and neither do my clients. Also I do think it's funny the JAM stack he's referencing is just the jQuery stack of 5-10 years ago.
RandomGuyDTB 7y ago
Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and the latest Chrome. A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they just work. My website: https://www.instantfloppy.net/ https://www.instantfloppy.net/ (though admittedly I don't spend as much time on it as I should) [0]: https://danluu.com/ https://danluu.com/ [1]: http://michaelnormanwilliams.com/ http://michaelnormanwilliams.com/
- somecallitblues 7y ago
  I’m sorry to say this but your site may only be appealing to you. Even though it will render on Commodore 64.
  - RandomGuyDTB 7y ago
    The intent is for users to style it themselves.. or it was, until browsers stopped having that functionality.
    - krapp 7y ago
      Browsers never stopped having that functionality. It's still entirely possible to load custom user styles into a webpage.
      - RandomGuyDTB 7y ago
        If I recall, Netscape or one of the other early browsers used to have an option to change the default font/color of text and the background in its settings. Nowadays you have to use an extension to do so.
smitty1e 7y ago
All of which makes the idea of some sort of JSON-driven API very, very attractive.
movedx 7y ago
I think we just all have to agree that plugging a complex, dynamic component into a web site should be done with care and attention to the details. If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else. Why is this hard?
somishere 7y ago
> But the web is about presenting content first and foremost Surely this just translates to user first ..? Devs moving from "it's about me" to "it's about you", perhaps with a bit of a shove from google, et al.
scarface74 7y ago
I’m by no stretch of the imagination a modern web developer. I know plain JS well, HTML and enough CSS/Bootstrap to throw together an internal website. Even then most of my experience is with server side rendering. However, for any large project, I would much rather be forced into using a modern framework than not. Any web app that is large enough is going to have some type of bespoke framework that was created by the “architect” who has been there forever. It’s just like dealing with a bespoke ORM, logging, or authentication/authorization framework.
- snypox 7y ago
  Plus shifting processing from backend servers to end user browsers can be a huge plus of you have a decent amount of visitors. Also, just simply pushing my code S3 is so much easier for me than building a Docker image and putting it into a container orchestrator.
deleted 7y ago
[deleted]
sigzero 7y ago
Does that mean a new version of Microsoft Frontpage is imminent?
Jaruzel 7y ago
> And so was born PHP, it feels like a natural extension to HTML itself. My ageing memory may be failing me, but wasn't Perl the first widespread language to be used for CGI ?
- stan_rogers 7y ago
  Well, C was there first in that sense, but yes, you're broadly correct. But that misses the point. PHP was developed and released as a templating language - something anybody with a bit of basic HTML knowledge (and, frankly, all HTML knowledge was basic HTML knowledge back then) could use to build an interactive site by using HTML-like tags to employ code written by somebody else as widgets in an HTML page. Perl meant writing the whole thing, including emitting HTML from the code.
lzsiga 7y ago
Off: Also there is the HTML Hell Page, which is older than many of the current web-developers but still contains the most relevant informations about web-design.
aantix 7y ago
..and Rails, billed as the anti-enterprise framework in its early days, just added sharding support.
deleted 7y ago
[deleted]
melq 7y ago
As stated in the article, these ‘static’ files are being programmatically generated by backend services on remote servers rather than client side, but I don’t see how this could be construed as a paradigm shift back towards static site design. How can you call dynamic, per-request content generation as static design?
- SPBS 7y ago
  You serve the same HTML/JavaScript/CSS bundle to anyone who visits your site, and the JavaScript renders the request specific details on the client (by making more calls to the backend)
jonny383 7y ago
There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on). Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there. For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month. Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end. Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.
- lazyjones 7y ago
  Another problem is that Google and some other search engines have only just started interpreting JS and since they determine the fate of most projects based on their search index, you'd better use a design that Google is able to turn into indexed pages.
  - ThePhysicist 7y ago
    Google was able to parse and execute JS for at least 6 years, I remember having a complex SPA in 2015 that didn’t pose any problem to Google.
lloydatkinson 7y ago
Static site generators work so well for a lot of sites. Why anyone ever thought they needed ASP.NET MVC or PHP or whatever else and a database all for the sake of a simple blog/article site is beyond me.
thrownaway954 7y ago
question... i keep hearing people say that when you use something like react, you need to have some sort of ssr in order to do any sort of seo. is that really necessary since google and other search engine can parse out js nowadays?
paramaggarwal 7y ago
Hello! Article author here - I wrote this after realising that buzz words have entered our industry again in the form of the JAM stack terminology. Hence I took an approach of actually what is going on under the hood.
pjmlp 7y ago
Ironically for those of us on SSR frameworks, it was fun to just watch the pendulum go back and forth, while we just kept delivering.
apatheticonion 7y ago
Honestly, static CMS like wordpress is overkill. A simple client side templating language and a JSON representation of your dynamic content is both sufficient and highly productive
alephu5 7y ago
I am trying to bootstrap a SaaS business by myself and chose to split between SPA+rest for the product itself and static html + CSS + vanilla js for the landing page and documentation. I chose this because I've got limited resources and am not a designer, but with react I can get a nice polished interface quite quickly using things like material UI. I really tried hard to keep the tech as simple as possible while providing the quality I want and this was the best option.
fiofio 7y ago
I don't even mean for this to be a plug but it's really easy to start up a VueJS site. I have done it multiple times. ``` npm i -g vue-cli; vue-cli create my-app; cd my-app; npm run build; aws s3 cp --recursive dist/ s3://my-site/; ```
scoutt 7y ago
I have a repo of static HTML pages with my personal documentation (I develop firmware). When started it some years ago, I almost chose WordPress, since I know it from running a small store. I didn't wanted the hassle of a DB, theming, etc. Why can't I edit webpages with Dreamweaver like 25 years ago? Then I've found Hugo (https://gohugo.io/ https://gohugo.io/), set a template in like 5 minutes and now I edit my docs directly in VSCode and see them change in realtime. Also, the docs can be easily versioned (git in my case). For a dumb like me (in the web-developing sense), static pages are a blessing. I am glad we are "evolving back".
zeveb 7y ago
This is a strange way to define static. To me, a static site is one which doesn't make dynamic requests. Sure, it might load in static images (even static JavaSceipt!), but it would run fine if all resources were burned to a CD and loaded without networking. A static site may be archived. It may be used with any browser at all. It will probably be useful even without a browser.
jkoudys 7y ago
Everyone looks at tooling like Gatsby+netlify to support their dreams of a JAM stack, but vanilla html/JS/CSS can do a lot written by hand too. I recently replaced a whole WordPress blog by saving it from the browser and cleaning it to the point where non-devs have an easier time updating it on GitHub than struggling with the mass of config pages and plugin shortcodes they needed before.
eximius 7y ago
I'm sure that https://svelte.dev/ https://svelte.dev/ is not the end goal of web development, but it is the next step. What I want to see is more support for serving svelte and integration between front end components and backends. (I.e., the backend has a list of root components generated by the front end and a route can return one of those components in a statically typed way)
vinhnglx 7y ago
> Playing football is very simple, but playing simple football is the hardest thing there is This quote is from Johan Cruyff - A football legendary. I feel it also true with programming. Nothing wrong with the technical stacks, in my opinion: Do the right work, at the right time, with the right tool.

448 points by diablo1 7y ago

Good. I could do without the JS, to be honest (I'm a little tired of pages that refuse to show me anything unless I whitelist some stupid third-party jQuery script in uMatrix), but, baby steps. When sites finally ditched their trendy Flash rewrites and went back to HTML, I thought, thank God.

Spivak 7y ago
The JAM stack the author is talking about is entirely driven by JS. The is “static” in the sense that a .dmg file is static and can be hosted on a CDN and not templated on the server.
- ehvatum 7y ago
  Jesus, why? You could write the back end in something that isn’t fucking garbage, at that point.
  - sergiotapia 7y ago
    shovel sellers, that's why
  - godman_8 7y ago
    I’m not a JS fan but quit with the toxicity. The proprietary logic is done with languages like Go, Rust, Python, JS, etc and built with a RESTful API in mind so the frontend can consume it. Angular, React, and Vue are built to do this well. It’s all in moderation and should be done responsibly. The downside with this of course is added complexity on all levels. However with this design maturing the complexity has reduced some or effort offloaded elsewhere (microservices, serverless, k8s.)
  - hombre_fatal 7y ago
    This is just empty negativity. That people use Javascript in places they aren't forced to use Javascript should make you wonder what the upsides are for them instead of assuming they cannot form any valid preferences of their own, unlike yourself. For example, Javascript is one of the few languages that actually delivers on "async everything" and has a very simple Promise abstraction (like Promise.all()), and that makes it better for me than building networked services in similar languages (PHP, Python, Ruby). It's also one of the few dynamically-typed languages with a bolt-on static type system that actually gained traction. You might not care about these things somehow, like maybe you only write C and Python because you work with embedded systems. But I think it's time to stop calling it garbage in honest conversation.
    - nostrebored 7y ago
      Maybe the problem here is building networked services (sounds like synchronous communication between components). How often is it that a well architected microservice architecture needs to do more than push data into a decoupling resource and data store and consume data from a stream or a queue? Is Promise.all( ... ) really that relevant that often? I've come to enjoy Node.js more than I thought I ever would, but it's still not something that's ever mindblowing to me, and I don't think that switching to Python would be a huge burden. With sensible tooling and contracts, neither would switching to a statically typed backend.
    - karatestomp 7y ago
      Async-by-default from the perspective of the developer is one of the chief sins of JS, in this writing-JS-since-the-90s developer's opinion. I've seen and written so damn much code to work around async-by-default. Now most of the code I read is comically full of (justified!) awaits, so at least we got the sugar to fix it without so much fuss, but we shouldn't have to in the first place. Let async code surrender control, but don't continue executing the current logic unless the developer asks for that behavior. Await-like behavior by default. That would have been much saner, less bug-prone, more helpful, and easier to learn & reason about. It's the desired behavior at least 90% of the time, in my experience.
the_cat_kittles 7y ago
"i could do without the js" is an indictment of design decisions, not js. its performant as hell, and ubiquitous. its a great thing, ...what people chose to do with it is often not great, however.
geggam 7y ago
Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster
- p2t2p 7y ago
  You're free not to use any website...
  - geggam 7y ago
    Arguably if you are publishing content on the net you are giving it away. There are mechanisms to charge for it.
    - hombre_fatal 7y ago
      > There are mechanisms to charge for it. Only above a certain price point. Our financial system nor our consumer culture support micropayments yet. This effectively limits the web properties that can charge users to a small fraction, so unfortunately "just charge money" isn't the widely-available solution I wish it was yet. Hell, it's more viable to charge users for your mobile client than the backing service. It's kind of the closest we have to micropayments in a way.
      - geggam 7y ago
        Then you dont have a sustainable business model. Why should I subsidize your failed model ?
        buzzerbetrayed 7y ago
        Yet you somehow think charging content providers for using your computer when they give you free content isn’t a failed business model?
kristopolous 7y ago
When flash was dying I said it was a bad thing because ads would no longer be contained in these tidy, controllable virtual machines sitting adjacent to the page content but instead would be redone in JavaScript in a huge soupy mess where the content is held hostage by ads that slide in and out of the screen and cover content, popping in and out of existence, reflowing the page, making the content jump around and disappear as terribly coded flash apps become terribly coded JavaScript modules slogging the whole browser along with it. People thought I was wrong and insane. I wish I was. Realistic assessments are always less popular than hope and principles. Flash was the good times.
- b0rsuk 7y ago
  Flash ads were trivial to block with plugins :-). And it was safe to block because usually no serious pages used Flash much except for artist portfolios.

Spivak 7y ago

It’s a nice title but webapps have evolved from documents to application bundles. It’s super cool that we built wildly complicated apps out of what was in spirit an FTP client with a PDF reader but it makes since that we have to hack the document retrieval system less now that the client can run code. Maybe one day we’ll stop hacking on the document store’s limited RPC-ish protocol too.

wideasleep1 7y ago

Would have been apt to use 'devolved'. 'Are We Not Men?'

popup21 7y ago

Wouldn't do it any other way. I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. I was regressing to the environment I understood in the early 2000s-2010s. I did all of this because I knew there would be a steep learning curve going into modern ecommerce and it seemed reasonable to put everything into hibernation while I attempted to go all-in. I pretty much missed the entire React, Angular, Vue ramp up in the industry. I've since shut down that ecommerce project and find myself peeking back to the js-verse every now and then. I doubt I'll ever voluntarily use one of those frameworks for web dev. I do, however, like this thing called, Svelte.

kareemm 7y ago
> recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. What are you using?
- popup21 7y ago
  Publii. It's developed by a European (France, I think) team. It syncs to Netlify with a single mouse-click.
  - kareemm 7y ago
    Thanks!
  - lenova 7y ago
    +1 for Publii. It feels like it's early days for them (i.e. they only have a few themes & haven't been picked up by the third-party theme developer crowd yet), but man, does Publii make it easy for any end-user to generate and publish a static website.
jakelazaroff 7y ago
> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20is,react%20js,angular%20js,vue%20js https://trends.google.com/trends/explore?geo=US&q=svelte%20i...

cjohansson 7y ago

It seems the trend points to slower and slower websites with more JS bloat. I also notice a increase in JS-errors causing entire sites to malfunction, recently this happened to large apps like Teams and Float

camccar 7y ago
New reddit is painfully slow to login. So much javascript for a simple dialog to load it's absurd.
- qznc 7y ago
  As long as old and compact reddit are still there, I'm fine with it. Twitter on other hand has no lightweight version, unfortunately.
  - saagarjha 7y ago
    I think I recall someone mentioning there is one that you get if you send an empty User-Agent.
    - csande17 7y ago
      If JavaScript is disabled in your browser and you visit mobile.twitter.com, you get a link to proceed to "legacy Twitter", which is their pre-React mobile site.
  - benbristow 7y ago
    Twitter's redesign is one of the most performant SPA's I've seen in a while. It's really smooth and nicely designed too. A lot better than their previous webapp.
    - readarticle 7y ago
      Do you know any others? Every time I’m redirected to twitter on mobile I’m in awe, it’s genuinely the only SPA I’ve ever experienced work “properly” on my phone comparable to a native app without any polish.

s_y_n_t_a_x 7y ago

No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed. If you are building a web app, use React or similar. If you are building a web site, use plain HTML+CSS w/ supplemental JS. Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML. Maybe don't embed all that stuff in your app and you wouldn't struggle with forms and routing, something that browsers can do very well with no programming.

x3haloed 7y ago
Of course the reasonable answer gets downvoted. Stay strong! And remember that you're not a good developer unless you write everything in vim compiled for an OS that you wrote for yourself in C, backed up on a trusty old 2MB platter drive via a series of rsync scripts. I heard the concept of version control was originally conceived and canned by IBM in 1967, because it was found that version control would eventually become mainstream, and therefore bad.
- s_y_n_t_a_x 7y ago
  Thanks for the kind words and the mention. I'm used to the downvotes on here unfortunately, it's easy to tell which topics will do it, the group think here can be thick...
  - x3haloed 7y ago
    You're welcome. My struggle on HN is to try to ignore the groupthink and keep the sarcasm out of my tone, but sometimes I just can't help myself.
ng12 7y ago
Preach. I teach a little "into to web dev" workshop that starts with a slide explaining that static sites, SSRs, and SPAs are all perfectly acceptable. They're different tools for different use cases.
woutr_be 7y ago

gwern 7y ago

> I find it fascinating that we are back to generating separate HTML/CSS and JS files and then putting them on a static file server — the CDN. It has been a decade long effort and as we come back to where we started, I feel like we are at a whole another level (a spiral?). "The wheel of reincarnation" from client to server and back: http://www.cap-lore.com/Hardware/Wheel.html http://www.cap-lore.com/Hardware/Wheel.html

sircastor 7y ago

"All of this has happened before. All of this will happen again." I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.

x3haloed 7y ago

> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant. > But the web is about presenting content first and foremost! Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it? In the end, the article makes the right point: Use the right technology for what you're trying to build.

amluto 7y ago
> But Gmail showed us that web 'apps' are useful. And we really have come full circle. Gmail performance, at least on Firefox, is awful.
- robbrown451 7y ago
  Whether or not this is true, when Gmail came out, it was WAY better (including faster) than everything that it competed with.
  - wolco 7y ago
    It was never faster then squirrelmail. It had cool features search was fast. But loading up your mailbox never as fast as other solutions.
    - robbrown451 7y ago

csomar 7y ago

We are not going back full circle. We are facing new challenges and realizing how complex web development is. 1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases. 2- There is no simple HTML either. Are you going to memorize how you coded that widget. Maybe use a framework (like bootstrap) to standardize things. 3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types. 4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM. 5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl. 6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn). tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.

deleted 7y ago
[deleted]
Guest0918231 7y ago
Well, I completely disagree. Compared to developing sites 15-20 years ago, I think it's a walk in the park now. I feel like I can achieve far more with less code, the tools are more powerful, the code is easier to read, and there is much more consistency across browsers. Did you want to make a box with rounded corners? We can do that now... <div style="border-radius: 5px; border: 2px solid black;"></div> It's intuitive and easy to understand. Try that 20 years ago. You're designing that in Photoshop, slicing up images for each corner, placing them into countless HTML table cells, messing around with all the table and cell heights, widths, paddings, margins, and borders, and struggling to get IE to render it correctly. That could have easily been an hour of work, and it would have resulted in a mess of images and inflexible code. Now, it's one line of code and 10 seconds of work. Did you want to fade the color of the border to red when the user hovers over the box? We can do that with two lines of CSS now. Good luck trying to achieve that in the past. What do you mean thousands of lines for a responsive/mobile CSS layout, and no simple HTML? https://www.w3schools.com/html/tryit.asp?filename=tryhtml_responsive_media_query3 https://www.w3schools.com/html/tryit.asp?filename=tryhtml_re... There, it's a site with a header, footer, navigation, three columns, and it's responsive. 36 lines of CSS and 36 lines of HTML. Add 5-10 lines of CSS to reset spacing at the beginning, and that could literally be an entire responsive website.

chrysoprace 7y ago

This is something that I see espoused by "web traditionalists" for lack of a better term. Sure, there are a lot of web developers who are not optimising for performance but I think the difference is that it has simply shifted to the frontend where it's more noticeable. The kinds of people who care about performance in the backend are exactly like the kinds of people who care about performance in the frontend. There's a variety of techniques that make sense in both areas to create a snappy, seamless experience. You need experienced engineers to create performance no matter what your domain is. We've gone down the route of creating SPAs to largely replace experiences that would require desktop applications (it was only 5 years ago that I had to download an executable to do my tax return, now I do it with an SPA). Rather than create an SPA for a blog or a simple marketing site, we've largely replaced traditional "heavy"[0] infrastructure (PHP, Apache, MySQL just to display static content) with static JavaScript-generated sites. Many of these can simply be hosted on a CDN because they have no database and often no need for complex routing. Pretending that SPAs were part of some dark ages is just silly. Horses for courses. If your application requires what I've dubbed "heavy" architecture (above) then by all means! Such infrastructure allows a high traffic service to be highly available, but is not required to serve a single .html file. [0] When I say "heavy" I'm mainly talking about the attack surface and maintenance required. WordPress is great for serving a blog but has been the target of many hackers due to the amount of security vulnerabilities it has had over time.

torgoguys 7y ago
SPAs being the darks ages is over-the-top, but being an SPA when other web architectures could better serve the user is a dark pattern. That tax app doesn't need to be an SPA. JavaScript powered interactions make the experience nicer for the user, but that doesn't mean it needs or is improved by being a single page.
- muglug 7y ago
  I think an SPA can be much more user-friendly than a traditional series of server-rendered pages. Email is a great example of this - GMail, at launch, had much better UX than existing server-rendered applications like Hotmail. You can find bad UX everywhere - in SPAs and server-rendered interfaces alike - but there’s nothing implicit to SPAs that reduces usability.

5cott0 7y ago

If SPAs are the dark ages then what do you call the IE6/7 jQuery days?

jonnycoder 7y ago
The Wild Wild West!!? I remember doing jquery/ajax calling an API and while it was easy to churn out spaghetti or long js file code, it was still easier to read and pick up a few years later.
- 5cott0 7y ago
  > it was still easier to read and pick up a few years later. Compared to what?

egypturnash 7y ago

My personal site is still a bunch of files served up by a cache in front of Wordpress. It'll be cool again in a couple years, I guess.

paulmd 7y ago
The really cool kids are just using something like Jekyll that does all the templating at publish time and you just have static files you dump onto a server.

zuhayeer 7y ago

We've been building Levels.fyi as a static website for the past 3 years! To create a new page, we simply hit new file on our text editor and start to fill the page. We have a simple build system + templating with Gulp and Nunjucks, but its really all we need. Scaling a static site is incredibly nice & cheap too :P

movedx 7y ago
> Scaling a static site is incredibly nice & cheap too :P And secure. The only back end systems to attack are load balancers and web servers -- if you're self hosting those then just make the file systems read-only and now you're talking seriously tough security barriers between you and an attacker.

nkozyra 7y ago

The leap from static HTML to PHP misses a big chunk of dynamic web site growth that started to produce a lot of the bad patterns that lived on. As simple and nice as static HTML is, it's inefficient. The reason we care about this now is mostly: A) A lot of people just hate Javascript. And a lot of that hate is understandable. B) People still worry about the crawlability of their SPAs JS has a lot of problems but it's also fixing some of these by growing really fast (paradoxically, also one of its problems). Bots will get more comprehensively better at rendering client-side only apps.

trynewideas 7y ago

The best part is that this is from an email newsletter and has broken HTML at the end.

ng12 7y ago

> But the web is about presenting content first and foremost This is where the article started going wrong. I don't care about the web -- it's a tool for me to do my job. I use the web because it's a much better alternative to shipping a Swing app. I don't care what the web is "about" and neither do my clients. Also I do think it's funny the JAM stack he's referencing is just the jQuery stack of 5-10 years ago.

RandomGuyDTB 7y ago

Hell, I still write the HTML and push it to Github where Github Pages and Cloudflare put it up on the Web for me. I've never seen any reason to use Markup when I can just Mark my text Up in HTML pretty simply. If you write a site correctly (a site, not a webapp) it'll render in anything from the original Netscape to the Wii Browser (tested working with my site), Internet Explorer 8 (working), Links2 (working), and the latest Chrome. A site like YouTube doesn't need to work with old stuff like Netscape or IE but if your site primarily focuses on text there's next to no reason there should be Javascript on your site. Sites like danluu's[0] and Michael Norman Williams'[1] may not look the best but they just work. My website: https://www.instantfloppy.net/ https://www.instantfloppy.net/ (though admittedly I don't spend as much time on it as I should) [0]: https://danluu.com/ https://danluu.com/ [1]: http://michaelnormanwilliams.com/ http://michaelnormanwilliams.com/

somecallitblues 7y ago
I’m sorry to say this but your site may only be appealing to you. Even though it will render on Commodore 64.
- RandomGuyDTB 7y ago
  The intent is for users to style it themselves.. or it was, until browsers stopped having that functionality.
  - krapp 7y ago
    Browsers never stopped having that functionality. It's still entirely possible to load custom user styles into a webpage.
    - RandomGuyDTB 7y ago
      If I recall, Netscape or one of the other early browsers used to have an option to change the default font/color of text and the background in its settings. Nowadays you have to use an extension to do so.

smitty1e 7y ago

All of which makes the idea of some sort of JSON-driven API very, very attractive.

movedx 7y ago

I think we just all have to agree that plugging a complex, dynamic component into a web site should be done with care and attention to the details. If you need to offer some dynamic element to your website, such as a form that does validation, then just add a form that does validation with the most minimal of code, bloat and everything else. Why is this hard?

somishere 7y ago

> But the web is about presenting content first and foremost Surely this just translates to user first ..? Devs moving from "it's about me" to "it's about you", perhaps with a bit of a shove from google, et al.

scarface74 7y ago

I’m by no stretch of the imagination a modern web developer. I know plain JS well, HTML and enough CSS/Bootstrap to throw together an internal website. Even then most of my experience is with server side rendering. However, for any large project, I would much rather be forced into using a modern framework than not. Any web app that is large enough is going to have some type of bespoke framework that was created by the “architect” who has been there forever. It’s just like dealing with a bespoke ORM, logging, or authentication/authorization framework.

snypox 7y ago
Plus shifting processing from backend servers to end user browsers can be a huge plus of you have a decent amount of visitors. Also, just simply pushing my code S3 is so much easier for me than building a Docker image and putting it into a container orchestrator.

deleted 7y ago

[deleted]

sigzero 7y ago

Does that mean a new version of Microsoft Frontpage is imminent?

Jaruzel 7y ago

> And so was born PHP, it feels like a natural extension to HTML itself. My ageing memory may be failing me, but wasn't Perl the first widespread language to be used for CGI ?

stan_rogers 7y ago
Well, C was there first in that sense, but yes, you're broadly correct. But that misses the point. PHP was developed and released as a templating language - something anybody with a bit of basic HTML knowledge (and, frankly, all HTML knowledge was basic HTML knowledge back then) could use to build an interactive site by using HTML-like tags to employ code written by somebody else as widgets in an HTML page. Perl meant writing the whole thing, including emitting HTML from the code.

lzsiga 7y ago

Off: Also there is the HTML Hell Page, which is older than many of the current web-developers but still contains the most relevant informations about web-design.

aantix 7y ago

..and Rails, billed as the anti-enterprise framework in its early days, just added sharding support.

deleted 7y ago

[deleted]

melq 7y ago

As stated in the article, these ‘static’ files are being programmatically generated by backend services on remote servers rather than client side, but I don’t see how this could be construed as a paradigm shift back towards static site design. How can you call dynamic, per-request content generation as static design?

SPBS 7y ago
You serve the same HTML/JavaScript/CSS bundle to anyone who visits your site, and the JavaScript renders the request specific details on the client (by making more calls to the backend)

jonny383 7y ago

There's nothing wrong with static HTML/CSS/JS. There's also nothing wrong with a rich SPA. And again, there's nothing wrong with using some kind of dynamic server-side HTML/CSS/JS presentation (like WordPress). Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on). Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there. For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month. Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end. Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.

lazyjones 7y ago
Another problem is that Google and some other search engines have only just started interpreting JS and since they determine the fate of most projects based on their search index, you'd better use a design that Google is able to turn into indexed pages.
- ThePhysicist 7y ago
  Google was able to parse and execute JS for at least 6 years, I remember having a complex SPA in 2015 that didn’t pose any problem to Google.

lloydatkinson 7y ago

Static site generators work so well for a lot of sites. Why anyone ever thought they needed ASP.NET MVC or PHP or whatever else and a database all for the sake of a simple blog/article site is beyond me.

thrownaway954 7y ago

question... i keep hearing people say that when you use something like react, you need to have some sort of ssr in order to do any sort of seo. is that really necessary since google and other search engine can parse out js nowadays?

paramaggarwal 7y ago

Hello! Article author here - I wrote this after realising that buzz words have entered our industry again in the form of the JAM stack terminology. Hence I took an approach of actually what is going on under the hood.

pjmlp 7y ago

Ironically for those of us on SSR frameworks, it was fun to just watch the pendulum go back and forth, while we just kept delivering.

apatheticonion 7y ago

Honestly, static CMS like wordpress is overkill. A simple client side templating language and a JSON representation of your dynamic content is both sufficient and highly productive

alephu5 7y ago

I am trying to bootstrap a SaaS business by myself and chose to split between SPA+rest for the product itself and static html + CSS + vanilla js for the landing page and documentation. I chose this because I've got limited resources and am not a designer, but with react I can get a nice polished interface quite quickly using things like material UI. I really tried hard to keep the tech as simple as possible while providing the quality I want and this was the best option.

fiofio 7y ago

I don't even mean for this to be a plug but it's really easy to start up a VueJS site. I have done it multiple times. ``` npm i -g vue-cli; vue-cli create my-app; cd my-app; npm run build; aws s3 cp --recursive dist/ s3://my-site/; ```

scoutt 7y ago

I have a repo of static HTML pages with my personal documentation (I develop firmware). When started it some years ago, I almost chose WordPress, since I know it from running a small store. I didn't wanted the hassle of a DB, theming, etc. Why can't I edit webpages with Dreamweaver like 25 years ago? Then I've found Hugo (https://gohugo.io/ https://gohugo.io/), set a template in like 5 minutes and now I edit my docs directly in VSCode and see them change in realtime. Also, the docs can be easily versioned (git in my case). For a dumb like me (in the web-developing sense), static pages are a blessing. I am glad we are "evolving back".

zeveb 7y ago

This is a strange way to define static. To me, a static site is one which doesn't make dynamic requests. Sure, it might load in static images (even static JavaSceipt!), but it would run fine if all resources were burned to a CD and loaded without networking. A static site may be archived. It may be used with any browser at all. It will probably be useful even without a browser.

jkoudys 7y ago

Everyone looks at tooling like Gatsby+netlify to support their dreams of a JAM stack, but vanilla html/JS/CSS can do a lot written by hand too. I recently replaced a whole WordPress blog by saving it from the browser and cleaning it to the point where non-devs have an easier time updating it on GitHub than struggling with the mass of config pages and plugin shortcodes they needed before.

eximius 7y ago

I'm sure that https://svelte.dev/ https://svelte.dev/ is not the end goal of web development, but it is the next step. What I want to see is more support for serving svelte and integration between front end components and backends. (I.e., the backend has a list of root components generated by the front end and a route can return one of those components in a statically typed way)

vinhnglx 7y ago

> Playing football is very simple, but playing simple football is the hardest thing there is This quote is from Johan Cruyff - A football legendary. I feel it also true with programming. Nothing wrong with the technical stacks, in my opinion: Do the right work, at the right time, with the right tool.