I saw an argument online about whether web development beginners should focus on learning a framework (like say React) or focus more (and longer) on browser and web technologies (HTTP, HTML, CSS, JS etc.)
Anyone who's been around for long enough knows that:
- Making an effort to learn at least some of the stuff one abstraction layer below you, pays out big time in the long run.
- Paradigms, frameworks and tools come and go. Concepts, standards and protocols last. Both of these categories have an almost infinite ceiling.
- Solutions that are found by taking things away instead of adding things are better _now_ and especially _later_.
People can find themselves emotionally attached to their favorite paradigm, framework or tool and loose sight of what problem it's supposed to solve. Productivity, expertise and confidence are a function of deep understanding and practice. It's easy to distract ourselves.
This blog post makes a good case of avoiding unnecessary complexity with what they describe as "shortcuts". But really what they do is _lean into_ and extend what's already there.
> really what they do is _lean into_ and extend what's already there.
There are already so many features implemented in unix/the web/python/etc that it's easiest just to go along with what is there. For example, csvbase logs to the systemd journal (when run under systemd - stderr otherwise):
One under recognised thing about systemd is that it provides a mini-ELK stack - so now I have indexed, searchable logs that auto-rotate and whatever (the defaults are quite good). I realise a lot of people strongly dislike systemd but I think this is a very nice feature for running services of this scale.
One more shortcut: the backend for the blog is a csvbase table. The "4" in the url here is a csvbase_row_id :)
That's fair. If you're on job search, prepare for the interview at hand!
I'm not saying people shouldn't learn about paradigms, frameworks and tools. Or that they should overly focus on understanding their internals.
But there's _leverage_ here that some (including younger me) might miss:
If I'm getting asked how to use a specific tool, and I understand the principles behind it, then the surface usage becomes much easier to understand as well. Often you can _infer_ specifics or at least make a good argument of what you expect how something works and how you would go about in general.
In the absolute worst case you make assumptions based on conceptual knowledge and apply "wishful thinking" (SICP).
YMMV but I personally find it very impressive and fun when someone applies problem solving skills and conceptual knowledge with a dash of curiosity.
These qualities combined with a strong grounding in concepts, standards, protocols and so on, will help you understand and adopt the surface level things quicker and with more confidence.
As a (mostly) self-taught programmer, I was somewhat trapped in black box understanding for a while. My technical preferences and decisions where largely based on cultural things instead of technical grounding. From that perspective everything seemed so different and idiosyncratic. But after gaining more fundamental knowledge, trying out different approaches and talking to veterans, I started to see that they're all surface level re-inventions of the same stuff.
There are so many bootcamps and people coming into web dev thinking its an easy way to make money that actually knowing the fundamentals is CRUCIAL in my opinion.
I love this way of thinking about web application development, and we take a similar approach on my team at work.
There are problems though.
> When a form is "editable" … I just have that plus button add a query param and use HTTP GET to get a new version of the form with that field added.
I've done this kind of thing before, but the sticking point for me was how this interacted with the history API. If a user visits a form, adds a new field with a GET request, and then uses the browser's back button, where do they end up? Where would they expect to be?
Instead of taking this approach, in some places we've generated a template on the server which matches the inputs that should exist in the form and then used a DOMParser to parse the template from a string.
Here's an example.
;(function() {
var parser = new DOMParser();
var ol = document.getElementById(#{theId});
function addRow() {
var doc = parser.parseFromString(#{blankDateInput}, 'text/html');
var li = document.createElement('li');
var dateInput = doc.querySelector('.date-input');
li.appendChild(dateInput);
ol.appendChild(li);
dateInput.querySelector('input').focus();
}
document.getElementById(#{addRow}).addEventListener('click', addRow);
})();
---
An alternative approach is to just generate more inputs than the user will actually need, and only show the first one. The "button" to add a new field is actually a label connected to a hidden checkbox, and you use a combination of sibling selectors and the :checked pseudo-selector in CSS to show the next input.
You can use the state of each field's adjacent checkbox to decide whether or not the value in the field should be parsed on the server.
> If a user visits a form, adds a new field with a GET request, and then uses the browser's back button, where do they end up? Where would they expect to be?
They end up at the page that they were before, with the state that was there before, as a back button should do.
Bonus, they can share the url with anyone and exactly the same form will be displayed.
I thought it was clear from my comment that I'm mindful specifically of not creating unexpected navigation behaviour, as is so common with SPA implementations.
Yes, developers should not mess with the history API, and the back button should work as expected. And, a user navigating back and arriving at the same form they were previously viewing minus one input is probably surprising behaviour.
Is it, though? Adding another sibling to an existing form element is pretty much like hitting RETURN in a text document for a new line or paragraph or list element. What would users expect, when they had opened a new line/paragraph/list element and hit CTRL/Command+Z for "Undo"? I guess, most would expect the state just before opening that new element.
(I'd even go as far as to call any alternatives confusing, like reverting the last edit in the previous paragraph, but having the empty new element still hanging around, or progressing multiple state changes back, at once, which should be pretty unexpected. Personally, I'd deem it highly annoying, if an application wouldn't allow me to revert this expansion step, without implicitly changing any previous edits, as well. Mind that adding an element is pretty much a modal barrier in the editing process and not only crucially different from editing text, but also separates editing tasks into "natural" groups. Which is also why we use such grouped actions and elements in form-centric workflows, in the first place.)
As in, "back to the state before the last interaction", which is pretty well defined.
(If there are clearly grouped interaction with transitions, this may be "back to the state, the last grouped interaction was finished and the current one opened.")
If you are interacting with a modern log-in box, where there is a first state to input the user name or account ID and then a transition to a separate state presenting a password input for this account. You hit the back-button. What do you expect? The box switching back to the input of the account ID, or leaving that site altogether to wherever you came from (e.g., Google)? I guess, most would expect the former, because there is change of state and a transition. I think, adding another sibling, thus changing the form on our own account, is such a change of state, as well. (In other words, we may want to revert this step, but we do not necessarily expect CTRL/Command+Z to work in this context, like it does for a "normal" editing task. But we may expect the back-button to work. Not to the least, because we had to press an action button in order to arrive at the present state.)
Moreover, this is pretty much how forms have worked for the first 20 years of the Web. (I.e., the browser stores a snapshot of the state of the page just before any transition or navigation event and restores this on the press of the back-button. Before there were single-page approaches, this was well defined.)
I don’t see those two ideas as equivalent, and so I don’t agree at all.
I can imagine a user seeing a page to input their email address and a subsequent page to input their password as two different pages, and so navigating back from the password input page should take you to the email input page.
I don’t think a user would expect to return to a page which models n-1 of a kind of a input when navigating back from a page which models n of a kind of input because conceptually they are the same thing.
They are not to the least conceptually the same thing: this is the form you customized by interacting with an action button. You expect this to change the state, and you do this either for a purpose, or by accident (in which case you may want to revert this, as you may fear that you've just broken the process.)
> Thousands of lines of Javascript were spilled to do this in the past. Now browsers do it for you.
Alright. Now I want my date picker to have no rounded borders, the days in the weekend to be in a specific color and Wednesday to be in another one. And everything has to look the same according to your browser, of course. How does this guy do it?
He does that because it is his own project and he does not have PM\BO and designer mandating how it should look.
He also does not have any real interactivity with the date picker - it simply picks date and saves value in a field. I am waiting when he goes into implementing filtering of rows in his 'csvbase' or any other slightly more complex interaction between items on the page ;)
Everything is sales and everyone sells. If you can't sell your clients on why they shouldn't spend resources making a custom date picker, get a better salesperson in there.
I've come to view applications which rely on JavaScript to be fundamentally broken, no matter how small the functionality it implements. I don't even have to give specific examples, with developer tools open it's rare not to see red as you traverse the "modern" web, and even when it isn't I can break the world by disabling JavaScript, I don't even need an extension to do it. The same doesn't apply to HTML, or even CSS.
The number of people who disable Javascript is probably less than people who refuse to or can't upgrade from really old browsers, where all the current HTML and CSS is going to break.
I don't get the HN hysteria over Javascript. You have a powerful host (I won't even call it a client, because it can and should be so much more). It would be crazy not to use it. Sure, it can be abused or programmed poorly, code should be tested. But in my wide-ranging use of the Web which involves a ton of Javascript, that has rarely been a problem.
I don't think people generally (not even on hn) has anything against powerful capable tools developed in js. What people do tend to hate though is using js to do something that could have easily been done without it.
Is this really possible? I remember that the html5 datepicker isn't working at all on some browsers (or on mobile). Are there any data on the percentage of users that won't see a datepicker at all if they go the html5 route?
No it's not. It sort of works until you have to deal with thinks like international dates when the thing isn't rendered or breaks (which happens a lot on android from experience). Then some end user inserts an invalid date like 2023-02-31 so you still have to do server-side validation or check it with some client JS anyway. So you might as well just chuck some shitty jQuery control over the top of it.
Basically as always with HTML it's half baked and half supported.
Both are terrible. The whole web is terrible. I wish for Gopher, nicely presented PDFs, thick apps and APIs and for the whole hypertext steaming pile of mess to crawl back to where it came from.
Good, performant, well designed apps and systems still exist. Absolute steaming piles of crap that didn't interoeprate existed "before the web" too.
> I wish for Gopher, nicely presented PDFs, thick apps and APIs
You're free to browse Gopher sites, only read latex documents, and stick to Desktop apps. PDF's are a great example of an absolute steaming pile of nonsense though. They're page layouts (that don't map to my 16:9 widescreen monitor, or to my 20:9 phone), have poor standards for layout and linking, and behind the scenes are just a mess of rules that are practically impossible to interpret, even on PDF's that aren't obfuscated. PDF's are a disaster, and I'd pick a css/js/html document over a PDF any day.
It works...ish. It provides an inconsistent experience across browsers, and if your datepicker needs any other functionality besides picking a single date, such as date ranges, focused dates, rendering two or more months at a time, rendering a weekly view, etc, you're going to have to use JS.
Maybe your work projects should use JavaScript, but I think this advice shouldn’t be limited to side projects. Specifically the part of the post about shortcuts is a good reminder for any developer working on any project.
I hope Mr Peterson succeeds. I would rather have a web full of CSV or SQL than a web full of irregular HTML and now more Javascript than HTML.
I have been writing filters that transform irregular HTML into CSV and SQL. From CSV I can easily transform to SQL. From SQL I can easily transform to HTML or plaintext tables, JSON, or whatever I want. IME, transforming irregular HTML is labor-intensive. Transforming from CSV to other formats is not.
The web could be a data store instead of a disinformation vector, surveillance instrument and advertising medium. Take the money out, leave the utility.
This is not always possible. Even a functionally simple project like twitter or mastodon could not work without javascript. Heck, even a modern ecommerce store could not work with simple html these days. Modern web applications are interactive and "alive" and simply require front-end application as well and not just plain old html. I would say to go the other way round and figure out how to make vuejs/react apps into web assembly binaries to be run like desktop applications in web browser. The user has no need to see the source code or fiddle with network connectivity.
> Even a functionally simple project like twitter or mastodon could not work without javascript
Please explain what unique features those two platforms have which oldschool forums couldn't already do without JS. Not to mention you are posting this on a platform which works quite well without JS, including support for folding subthreads and upvotes.
> even a modern ecommerce store could not work with simple html these days
What is required for an ecommerce store to be "modern" in your view? Because I can't remember a single important part of Amazon which works only due to JS. Sure, that image pan/zoom feature for product photos needs JS, but that feature is also worse than just opening an image file in a new tab and doesn't even work half the time.
Amazon also still reloads the entire search whenever I check a filter checkbox, making it annoying and slow to set multiple filters. Another case where poorly used JS actually made it worse than a simple HTML form.
I agree with the spirit of your comment, but I was curious about one detail — how could upvotes work on HN without JavaScript? Voting on a comment doesn't mutate the history stack, so it must work with JavaScript.
I had a look, and you can see the function which handles this on line 35 of this file:
Twitter/mastodon require interactivity to keep users engaged. That is what differentiates it from old school forums. Keeping content short helps with focus as well since people want condensed information as fast as possible. You need notifications without having to reload the page to see other people reacting to your content. You need to see likes and shares alive so that you can see the platform is alive and people are active on it. Refreshing the page just won't do. You need to see new posts being written so that you see there is active conversation. None of this can work if one needs to keep reloading the page. Functionally sure, it will work, but it won't give the user the impression of being part of active group of people and engaged.
As for e-commerce website, you have live chat, various notifications, integrated payment gateway without the need to be redirected to dedicated gateway website(you CANNOT do it without js due to PCI-DSS). Yeah, it can be done with no JS but who would? And if that would be the case, the sales would most definitely reflect the lack of interactivity and functionality.
> You need notifications without having to reload the page to see other people reacting to your content
You saw my reaction to your comment on this site without any notification. The same goes for the old Reddit UI which is still popular enough that it's online after 5 years. A lot of people want to just have asynchronous conversations without getting distractions lobbed at their face all the time. I visit Twitter maybe a few minutes per month because all the autoplaying gifs and notifications on all sides make me sick. For me a lack of "dynamic" site content is a valuable feature.
> As for e-commerce website, you have live chat, various notifications, integrated payment gateway
The only interaction I ever had with live chat was clicking on it to remove it with uBlock, if I want to chat with a salesperson I can go visit a shop. Notifications? Not really necessary. Also 90% of the Amazon app's notifications were suggestions for products that can't even be shipped to my country! With all the data collection you might think they can filter for that but they don't. And you're right about the payment part but that's a tiny fraction of an online platform.
The problem with JS is not JS itself but the way it's often abused to degrade the user experience.
> A lot of people want to just have asynchronous conversations without getting distractions lobbed at their face all the time... I visit Twitter maybe a few minutes per month because all the autoplaying gifs and notifications on all sides make me sick.
Then you're not the target audience. Nobody goes to Chuck E Cheese and complains about the lights and noise.
> The only interaction I ever had with live chat was clicking on it to remove it with uBlock, if I want to chat with a salesperson I can go visit a shop.
I regularly interact with support on DoorDash, Amazon, and my bank using live chat, instead of having to get on a phone call and get put on hold.
> Notifications? Not really necessary.
I use a pinned tab for my email, which provides in-browser notifications for new emails and calendar events, so I don't have to install a third-party native app from some random developer (whose installation requires admin access to my machine) just to read my web-based email.
Everyday on HN, some dev who doesnt have to do complex front-end complains that front end people over-complicate things and they know better. “Look I dont have to write complicated js, just have to shift complexity to verborse HTML, and black art CSS”. All of these are explicit i mean not composable… no shit Sherlock.
This is also how most of the original fastcomments admin area was built. Just SSR with progressive enhancement. Most of it should still work, at least be readonly, with JS disabled although moderation actions etc won't.
Good luck to do it when you are hired on Front end gig. Where Front end framework introduces breaking changes every version and your tech lead wants you to use it....
The grumpiest and unhappiest developers I know are JavaScript developers (although granted this could just be because there are so many of them).
I have written a lot of JS in the last 4 years but have been writing code for around 16 years and I can say that this current period of React driven development has been the least fun I’ve had writing code.
I’m now scaling down the amount of frontend JavaScript I write and my enjoyment is going back up.
I find it strange that for dynamically typed languages (JS, Python) the argument "but C++ is so much worse" keeps coming back. C++ is a fundamentally orthogonal language.
The comparison to a modern mature language like C# would be much more appropriate.
I like TS, I like modern react, but most shops don't use modern react or TS, and if you're unlucky enough to have to write angular or worse, Extjs, I'd understand a career change.
Man, ExtJS was my jam back…almost a decade ago I really did have fun with it but more in a “how do I make it do what I want” problem solving way. At one point we had a PHP backend that would generate the Ext controls just how we wanted them by stringing a bunch of code into the JS packages because it was easier than writing/maintaining the JS itself. Don’t ask.
I always find these takes so radically different from my own experiences. We do use Typescript and maybe that’s the difference, but these days you’re either using JSDoc or Typescript if you’re working with JavaScript so it feels sort of disingenuous to not simply expect it’s what people mean when they say JavaScript. I’m sorry if it is not.
We use it for most things because it works for most things. It’s one of the best working experiences I’ve ever had in two decades of programming. It did take some team work to setup templating and various CI related “rules” to make sure everyone is working in a similar fashion, but that wasn’t too much of a hurdle to overcome. It turns out most developers are happy to just fork a template project and follow whatever guidelines your organisation has set itself upon, and being as accessible as JavaScript is it also means that you can fine tune the development processes exactly how you need them. For us that’s a rather fascist linter, it’s complete control of how you use APIs and a range of other internally build libraries that handle things that you could probably find on NPM but shouldn’t.
The benefits is that everything works everywhere and that every developer can work together rather easily because everyone is using the same tools and writing code the same way. We use OData as an example, and because every OData client in Typescript is sort of terrible we build our own. Now it’s simply part of our API package and it allows developers to easily consume OData APIs without thinking about the inner workings because that’s done by the platforms team. I know you can do these things in every language, but in my experience it’s not something you do in C# or Java because the standard library is “good enough” and the standard “rules” for how you write those languages are in a similar boat where you probably won’t take too much control. Which is how you end up with very mixed code bases, or at least that’s what happened in every place that I worked. The freedom and the ease of which the JavaScript environment lets you take control is such a joy and a benefit that I really don’t get the hate it faces.
That being said. It’s a obviously a terrible language and I absolutely hope html and browsers will eventually get to a point where we can just write everything in (whatever language you like) + html. But it’s not like it’s a joy to write web frontends in any server side rendering that I know of. I’d much rather work with react than any other front end tech that I’ve ever worked with in the past. But I do simultaneously hope for better days.
Powershell for AD work. Java, C#, PHP for general purpose programming (it’s been 10 years since I used Java though). Python (I actually like that) for a lot of different things. C and C++ for embedded and high performance tasks for solar plant data, with a few projects in Rust before we decided to just keep on trucking. I’ve done a few projects in golang, love it but it has no adoption in my part of the world.
But for the things that I prefer Typescript for its mainly fair to compare it to C#, PHP and Python. Java was a terrible experience, but we’re talking back in the JSP and beans days and I’m pretty sure that’s not a fair comparison.
I don’t mind Python, but as you can imagine it has many of the same issues JavaScript does and you’re likely still going to be writing JavaScript so it’s sort of… well. I also don’t mind C for web, but what I’ve worked with it for has been so radically different from that. And C has the disadvantage of being something you can’t expect a lot of “generalist” web developers to do on the fly. So it could be very hard to hire for.
Anyone who's been around for long enough knows that:
- Making an effort to learn at least some of the stuff one abstraction layer below you, pays out big time in the long run.
- Paradigms, frameworks and tools come and go. Concepts, standards and protocols last. Both of these categories have an almost infinite ceiling.
- Solutions that are found by taking things away instead of adding things are better _now_ and especially _later_.
People can find themselves emotionally attached to their favorite paradigm, framework or tool and loose sight of what problem it's supposed to solve. Productivity, expertise and confidence are a function of deep understanding and practice. It's easy to distract ourselves.
This blog post makes a good case of avoiding unnecessary complexity with what they describe as "shortcuts". But really what they do is _lean into_ and extend what's already there.