This "no-JS" movement is cool and I love CSS hacks (in production?) but I also love the component mentality these JS-frameworks provide and not having to host frontend servers (other than for static files). Are there any good "pure" solutions for that?
A JavaScript-Free Front End
121–130 of 215 posts
Re: A JavaScript-Free Front End
#122Earlier quoted context omitted.
The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day. If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line. In the time the author re-wrote his app, I could have…
> Author could have installed next.js and called it a day. Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed. Javascript apps are tremendously complex, why would do this if you don't have to?
Imagine you have a team of rails developers and you're asked to create a simple portal. Rails as a tool may be "overkill" but what does it matter?
If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..
Re: A JavaScript-Free Front End
#123A nice way to progressively enhance something like this is to use Intercooler.js when you do want to update only part of the page. You're still just slinging HTML back to the browser but it lets you update only part of a page without using iframes or something, and since you're just adding data-attributes to links and forms, you don't write any javascript.
Re: A JavaScript-Free Front End
#124A nice way to progressively enhance something like this is to use Intercooler.js when you do want to update only part of the page. You're still just slinging HTML back to the browser but it lets you update only part of a page without using iframes or something, and since you're just adding data-attributes to links and forms, you don't write any javascript.
I would suggest using Vue progressively at that point. Refactoring our endpoints after using intercooler was not fun and using Vue/react without going full SPA let's you move on way easier
Re: A JavaScript-Free Front End
#125Earlier quoted context omitted.
You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users ar…
While I recognize a lot of the HN crowd blocks Javascript, the overall percentage of people doing this is absolutely tiny. What is the case for making Javascript-blocking users a priority?
Security matters, and blocking JS blocks the majority of vulnerabilities on browsers. We should help users who want to protect themselves.
Re: A JavaScript-Free Front End
#126Earlier quoted context omitted.
Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well. As to interpreted…
Why not C++17 in combination with h2o? I don't know why the compilation step is an issue if compilation and linking takes less than a second which is less time than switching back to the browser. I can pass around lambdas with ease and my lines and functions have become much more succinct with the newer versions especially when dealing with web related stuff. In addition, the https://github.com/nlohmann/json lib make…
Who says I need multiple machines? I just said if you're going to design for horizontal scale, then it becomes less of an issue. Also, there's a lot to be said for most of the code available already written. My time is worth far more than paying a couple extra $ a month to run an app on a second server/vps.
I just said that JS isn't so bad, and that language snobbery is worse when it means you're far less productive.
Re: A JavaScript-Free Front End
#127Earlier quoted context omitted.
Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well. As to interpreted…
Why not C++17 in combination with h2o? I don't know why the compilation step is an issue if compilation and linking takes less than a second which is less time than switching back to the browser. I can pass around lambdas with ease and my lines and functions have become much more succinct with the newer versions especially when dealing with web related stuff. In addition, the https://github.com/nlohmann/json lib make…
We get that C++ still works, but we also get that unless you can have an iron grip on the team, third party libraries and CI/CD pipeline, someone will definitely write C in C++, or forget about all those 200+ UB cases, and then all is lost.
Re: A JavaScript-Free Front End
#128It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Pl…
You can trivially add keyboard shortcuts to this solution after it's implemented - with 0 rework. Moreover, the is absolutely no guarantee that an arbitrary JS library for modal popups will have better usability. And I have yet to see one that will not fail if I block JavaScript, creating horrible user experience for everyone who does so. Funny how usability concerns go out of the window when NoScript/uBlock users ar…
It's not just modals. Hidden but toggled via labeled checkboxes — how are they gonna play with screen readers?
How do you properly shift focus to the dropdown menu whose visibility is toggled by clever CSS tricks?
And yes, modals may be needed sometimes especially in payment forms even if that modal is only visible to the screen reader.
Re: A JavaScript-Free Front End
#129I like the slogan "JavaScript-free"! Finally something to rally around. I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these. Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case. edit: added paragraph
The term I've usually seen is "JS sprinkles". Not sure where it comes from — maybe DHH in the context of mostly-server-side Rails apps?
JS sprinkles became the stimulus package [1]
[1] https://m.signalvnoise.com/stimulus-1-0-a-modest-javascript-...
Re: A JavaScript-Free Front End
#130I gotta get better at CSS, I'm somewhat horrified by what I've done in JavaScript that it turns out I didn't need. Does anyone know of a good book on intermediate/advanced CSS to help avoid excess JS usage/complexity?
I found these two ones quite good.
https://www.packtpub.com/web-development/professional-css3
https://www.amazon.com/CSS-Secrets-Solutions-Everyday-Proble...