I am not a web dev, but what exactly is an alternative to fat spa if you are building a truly interactive front end? How does server rendering work when you lose connection to the server?
Second-Guessing the Modern Web
131–140 of 467 posts
Re: Second-Guessing the Modern Web
#132Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, a…
I appreciate your comment, but please refrain from referring to general lack of focus as a community as ADHD
Why? Its a pretty apt description if you know anything about adhd or have it.
Re: Second-Guessing the Modern Web
#133Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, a…
> instead of settling down and focusing on getting the most out of a platform How do you know when to settle? Should we have stopped at jQuery? We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution shoul…
>Should we have stopped at jQuery?
For the bulk of websites that are mostly static with a little sprinkle of fancy interactions here and there? Maybe.
There is a time and place for React. Shocking to some, that place is not actually everywhere on the web. The bulk of the web IS actually about finding information. Few sites are soundcloud style webapps.
For context, I like react a lot -- I love its clojurescript re-frame variant. It is what I reach for _when needed_. The rest of the time, give me boring forms, pages, and jQuery and let me get on with my day.
Re: Second-Guessing the Modern Web
#134Earlier quoted context omitted.
For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…
Hey all I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React. Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at com…
to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs.
And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was either doing sloppy string manipulation or really indirect object-graph walking.
I don’t love babel, but we have a hot-reload script that auto-compiles while I’m working and even swaps in components to my webpage without a reload! It’s actually _less_ friction than vanilla javascript. I cannot imagine going back.
I hope eventually some of these technologies get pushed into the browser, but honestly it doesn’t matter much - javascript is fast, we can afford to use it as a compile target
Re: Second-Guessing the Modern Web
#135Earlier quoted context omitted.
Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting l…
Got a link? I'm curious what your end product looks like.
So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!)
The layouts are here:
One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.
Re: Second-Guessing the Modern Web
#136I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept.
Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit platform that is JavaScript.
I've seen the justification for SPAs front end JavaScript frameworks being a desire to separate data and presentation. A back end API serves data that's displayed by the app. We had that fifteen years ago with XSL!
There were these things called "browsers" and they could parse and display HTML and even XML. They supported stylesheets that could arbitrarily style those documents for display. They could even decide to use different styling depending on the display device! If they sound amazing they were.
I mentioned XML parsing. An XML document could be used to represent all kinds of arbitrary data. While a browser might consume XML, a native application or service could also consume it. But arbitrary XML in a browser wasn't super useful since a browser didn't have rules to display every different XML document that could be made.
The people that developed XML also came up with a way to transform data in XML to different formats. Browsers, being able to handle XML already, added support for this transforming. An XML document could include a link to this stylesheet and the browser could transform it into something (XHTML) that it did have rules for displaying, including CSS to further style elements and JavaScript to make everything terrible.
A native app or service consuming an XML doc could and often would ignore the stylesheet so to them it was just data. Even JavaScript asynchronously loading XML data would ignore stylesheets. Usually it was only browsers that cared about linked stylesheets.
But this let a single API serve browsers and native apps and even JavaScript. Presentation and data were separate concerns. Browsers would also cache all the display resources for a document so when a new document was viewed all of those resources would be cached locally.
But then for whatever dumb set of reasons web developers ignored these "browsers" and and their cool abilities. They insisted on ingesting XML to their JavaScript and then manipulating the DOM of an HTML page causing hundreds or thousands of repaints. Then they knew better still and replaced XML with JSON. By making the data serialization format require JavaScript they could obviate the browser even more. Now browsers are relegated JavaScript runtimes and even web servers are just load balancing proxies for JavaScript runtimes running on servers.
Re: Second-Guessing the Modern Web
#137Earlier quoted context omitted.
What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
React still requires you to write HTML and forms.
And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.
Re: Second-Guessing the Modern Web
#138Earlier quoted context omitted.
Hey all I remember when jQuery was the React of its day. Then browsers copied most of its stuff. And now we have moved in to Angular and React. Frankly, web components can do most of the stuff React does - and even the JSX can be done with eval and concatenating some backticks to strings. As long as you are SURE the strings are coming from templates, they can be assigned at runtime similar to how React assigns at com…
to me, though, javascript development has always felt like a chaotic tangle of duct tape, until I started working in React. somehow React feels like _writing software_ - building things in small pieces with well-defined inputs and outputs. And JSX feels like the programming style that I didn’t know I was I’ve been missing since the 1990s - like it’s the logical conclusion for working in HTML, when everything else was…
Want to jump on a call with me - just for fun - for 10 mins? I will show you our framework that we use internally:
https://calendly.com/qbix/meeting
IMHO the framework makes way more sense than React in that it is a lot simpler to reason about, and it also treats HTML CSS and JS sensibly. React is a bit esoteric... but it has the backing of a large company so everyone uses it. It’s a bit like Wordpress is used by everyone despite its codebase being from 2004. Like it’s OK, I get it, you have to buy into the ecosystem. But I think one day it will be replaced by something cleaner.
Re: Second-Guessing the Modern Web
#139I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it.
If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people.
Modern product development is essentially a polishing job on every component that Twitter Bootstrap or Jquery UI ever invented. Over and over, we dress up a modal, with a slider, with a ‘user flow’, with some tooltips, and so on, and allow the process to masquerade around as real design/engineering. There’s so much money in this industry that we can hire entire teams to basically take a Bootstrap component, and theme it. This gets passed on as product development, and from the developer side, it gets passed on as engineering.
If this is the level of masquerading occurring, why would a frontend developer ever go ‘what’s the right solution here?’.
Something similar is happening on the backend and infrastructure. It too will take on a mask behind devops and data science and start pumping out what are probably straight up SQL queries and cron jobs. This will get passed off as design and engineering as well.
We’re too big.
Re: Second-Guessing the Modern Web
#140Earlier quoted context omitted.
I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more. It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally. If all you have to do…
> I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more. Its a lie so long as the number sounds completely invented. I suspect the number comes from somewhere, maybe a vague memory, or a grossly unqualified estimation, but it isn't based on anything. It is something superficial that primarily serves as self reassurance. When you have never had to bill peop…
I have worked as a consultant for 5 years where I billed people for my time, and paid at least $200k to other contractors in that period for help on projects; it's not made up and it is based on my experience tracking my own time and productivity, and that of my subcontractors.
I do think it's more abstract and harder to justify properly when someone is a well paid salaried employee for a FAANG. But that's not me.